[Bug]: Forge photo upload fails with 403 SignatureDoesNotMatch

[Victoriaali04]

What happened?

Hello,

Photo uploads fail both in Curio and directly on the official three.ws Forge page.

Time:
2026-09-07 around 14:40 UTC
11:40 Argentina time

Steps:

1. Open https://three.ws/forge
2. Select “From photos”
3. Upload a JPG photo

Result:
The page shows “Network error during upload”.

Curio receives:

• POST /api/forge-upload: 200 OK
• PUT to the returned presigned R2 URL: 403
• Error: SignatureDoesNotMatch

The R2 canonical request shows:

• Method: PUT
• Signed headers: host
• Payload: UNSIGNED-PAYLOAD
• Region: auto
• Expiration: 300 seconds

This appears to be an R2 presigner/configuration issue. Please verify the S3/R2 access key pair, endpoint, bucket, and signing configuration.

I can provide the full redacted XML error and screenshot if needed

Steps to reproduce

1. Open https://three.ws/forge
2. Select “From photos”
3. Upload a JPG photo

Affected URL or surface

No response

Console / network errors

Area

Web app (viewer / studio / dashboard)

Environment

No response

[nirholas]

Thanks for the precise report, @Victoriaali04 — the timestamp, direct reproduction, and the redacted R2 error made this actionable.

The repository now contains a forge-upload credential probe added after this report. It detects rejected storage credentials before issuing a browser URL and returns a clear retryable 503 instead of a misleading client-side network error. The remaining 403 itself is deployment configuration: the R2 access-key pair must be rotated/corrected in the hosting environment. I am leaving this open until a maintainer verifies the production configuration and the reporter can retry.

[ni3a]

Reproduced against production on 2026-09-15. GET /api/healthz returns HTTP 200 but reports object_storage as down with SignatureDoesNotMatch; a benign POST /api/forge-upload now fails safely with HTTP 503 storage_unavailable, so the code-side guard is working and no untrusted upload was accepted. The remaining fix is owner-only Cloud Run configuration: replace S3_SECRET_ACCESS_KEY with the SHA-256 digest of the Cloudflare R2 API token (no trailing newline), then redeploy and recheck health plus one Forge upload. Leaving this open until production storage reports healthy and the reporter confirms a retry.

[ni3a]

Production recheck (2026-09-15 UTC): the code-side guard is deployed—POST /api/forge-upload now returns 503 storage_unavailable instead of issuing a doomed presigned URL—but /api/healthz still reports object_storage down with SignatureDoesNotMatch. This issue remains open until the owner resets the Cloud Run secret and a real upload succeeds. Owner command: gcloud run services update three-ws-api --region us-central1 --update-env-vars S3_SECRET_ACCESS_KEY=<secret> (or use the existing Secret Manager reference), then verify the object_storage health entry and one real Forge upload. No repository code change can repair a rejected R2 secret.

[ni3a]

Resolved in production on 2026-09-15. Rotated the Cloudflare R2 S3 credential pair while preserving the Secret Manager reference (s3-secret-access-key, new version) and updated only S3_ACCESS_KEY_ID via Cloud Run merge semantics. Revision three-ws-api-00431-bwq deployed successfully; the subsequent live revision reports object_storage: ok with a successful signed read, and a safe POST /api/forge-upload probe now reaches normal validation (400 invalid_content_type) instead of the former storage guard (503 storage_unavailable). No credential values were committed or posted.

[ni3a]

Resolved and re-verified in production on 2026-09-15 UTC.

• /api/healthz reports object_storage as ok with a successful signed R2 read.
• A valid POST /api/forge-upload request now returns HTTP 200 with a presigned PUT URL, public URL, PUT method, and 300-second expiry.
• The earlier SignatureDoesNotMatch / storage_unavailable failure is no longer reproducible.

The check stopped before uploading bytes, so it did not leave a test object in the production bucket.