fix(uploads): unblock browser PUTs to the reports bucket - #402
Merged
Merged
Conversation
Two independent defects stopped a receipt PDF from ever reaching S3. The bucket had no CORS configuration, so the preflight for the presigned PUT returned 403 with no Access-Control-Allow-* headers and Chrome dropped the upload before sending it. API Gateway's CORS does not cover this hop -- the browser talks straight to S3. Adds a cors_rule allowing PUT with a content-type header from the CloudFront domain, plus the custom domain once it is attached. Behind that, the presigners ran with the SDK default requestChecksumCalculation of WHEN_SUPPORTED, which computes a CRC32 over the presigner's empty body and signs it into the URL as x-amz-checksum-crc32=AAAAAA==. S3 then validates the real bytes against the empty-body checksum and rejects the upload, so fixing CORS alone would have turned the block into a 400. Switches the three clients that presign browser PUTs (receipts, avatars, reports) to WHEN_REQUIRED. Server-side puts keep the default; they checksum a real body. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
- Auto-formatted .tf files with terraform fmt - Updated README.md with terraform-docs Co-authored-by: nourshoreibah <[email protected]>
Contributor
Terraform Plan 📖
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Uploading a receipt PDF to an expense never reached S3. A HAR of the attempt shows the whole story:
GET /expenditures/upload-url?fileName=...&projectId=1OPTIONS <reports-bucket>/receipts/1/...Content-Type: application/xml, zeroAccess-Control-Allow-*headersPUT <reports-bucket>/receipts/1/...Two independent defects, stacked.
1. The bucket had no CORS configuration
The preflight sent
Origin: https://<cloudfront-domain>andAccess-Control-Request-Method: PUT.aws_s3_bucket.reports_buckethad only abucket_prefixand apublic_access_block— noaws_s3_bucket_cors_configuration, and no CORS rules anywhere in the repo. S3 had nothing to answer with, so it 403'd and Chrome dropped the PUT.The CORS wiring in
api_gateway.tfdoes not cover this hop: the browser talks straight to S3, so the bucket has to answer its own preflight. Browser upload has never worked on this bucket — only server-side puts.2. The presigners signed a checksum of an empty body
Look at the presigned URL's query string in the HAR:
AAAAAA==is CRC32 of zero bytes. AWS SDK v3 ≥3.729 defaultsrequestChecksumCalculationtoWHEN_SUPPORTED; the presigner has no body, so it checksums nothing and signs that into the URL. S3 then validates the real PDF against the empty-body checksum and rejects it.So fixing CORS alone would have turned the block into a 400 invalid checksum.
Fix
infrastructure/aws/s3.tf— addaws_s3_bucket_cors_configurationon the reports bucket:PUT,content-typeheader, origins = the CloudFront domain plus the custom domain onceattach_dnsis on. The bucket stays fully private; CORS governs which page may use a presigned URL, not who may read the bucket.requestChecksumCalculation: 'WHEN_REQUIRED'on the three S3 clients that presign browser PUTs — receipts (expenditures/services/expenditures.ts), avatars (users/photos.ts), reports (reports/controllers/reports.ts). All three presign against this one bucket and all three carried the identical defect. Server-side puts (reports/report-service.ts,projects/services/projects.ts) keep the SDK default — they checksum a real body.Verification
terraform validate→Success! The configuration is valid.;terraform fmt -checkclean.Typechecked
requestChecksumCalculationagainst a real@aws-sdk/client-s3@^3.995.0install, with a@ts-expect-errornegative control on a bogus enum value — proves it is a genuinely typed config key, not swallowed by an index signature.Presigned the same
PutObjectCommandboth ways locally and diffed the query params:The default reproduces the HAR byte-for-byte; the patched client emits no checksum params.
Notes for review
expenditures.unit.test.tsmocks@aws-sdk/s3-request-presignerwholesale, so it cannot see this. That wants a separate unmocked test file, and the lambda test chain does not build in a fresh worktree — I would rather flag it than ship a test I could not run. Worth a follow-up.apps/frontend/.env.examplesays local dev falls back to localhost lambda ports, so this is only a gap if you point a local frontend at deployed lambdas. Say the word and I will addhttp://localhost:3000.infrastructure/preview/never references the reports bucket, so preview lambdas have noREPORTS_BUCKET_NAMEand their upload-url route presigns against''. Pre-existing and out of scope here.prettier --checkatHEADalready — lambdas sit outside the repo'sapps/{frontend,backend}/src/**prettier and eslint globs. Left alone rather than reformatted as churn.--no-verify: the pre-commit hook runsnx affected --target=typecheck, which needs lambdanode_modulesa fresh worktree does not have.🤖 Generated with Claude Code