fix(copy): resolve CopyObject sources on path-mapped and OIDC deployments

[alukach]

What I'm changing

Server-side CopyObject is unusable on a proxy that maps client paths onto internal bucket names — Source Cooperative maps /{account}/{product}/{key} to the bucket account:product. Reproduced against production (data.source.coop) with a plain boto3 copy_object:

NoSuchBucket: bucket not found: alukach

Two independent bugs, both hit before the request ever reaches the backend. Every SDK client trips the first, so the feature is 100% broken on such a deployment:

1. The copy-source header is never namespace-mapped. CopyObject names its source in x-amz-copy-source, not the URL, so PathMapping::rewrite_request never sees it. The gateway parses the raw client-facing value and resolves alukach — an account, not a bucket — giving 404 NoSuchBucket. The client signs that header, so a proxy cannot fix this by rewriting the request in flight.

2. same_backing_store compares credentials that only one side ever has. A credential-injecting middleware (AwsBackendAuth) swaps auth_type=oidc for minted STS keys, but it only runs against the destination config in the dispatch context. The copy source is resolved afterwards, inside the handler, and still carries the unresolved form — so the two configs could never match. Hand-signing past bug 1 confirms it: source and destination in the same product were rejected as a cross-store copy.

501 NotImplemented: cross-store copy (source and destination on different backends) is not supported

How I did it

• crates/core/src/route_handler.rs — RequestInfo::copy_source + with_copy_source(), carrying the copy-source rewritten into the gateway's bucket namespace. Mirrors the existing signing_path idiom: the signed header stays exactly as the client sent it for SigV4 verification, while source resolution uses the mapped value. router.rs propagates the field.
• crates/core/src/api/request.rs — parse_s3_request takes copy_source_override and prefers it over the header when the request is a copy. A PUT without the header stays a PutObject regardless of the override.
• crates/path-mapping/src/lib.rs — PathMapping::rewrite_copy_source folds leading segments into the bucket name (/a/b/key → /a:b/key), preserving the key's percent-encoding and any ?versionId=. Returns None for values too short to map, so the caller falls through to the raw header and the gateway reports the real error rather than a synthesized one.
• crates/core/src/proxy.rs — same_backing_store → same_s3_endpoint, comparing S3-ness, endpoint, and region only. Credentials are dropped from the comparison deliberately, not incidentally: the copy is signed with the destination's credentials, and the source config contributes only its bucket name and prefix (build_copy_source_header), so the source's own credentials are never used for anything. Whether the destination's credentials may read the source is an IAM question, and S3 answers it with AccessDenied, which passes through. Caller authorization is unchanged — the source is still separately authorized as a read (GetObject) against the caller's identity.
• docs/ — reference/operations.md gains the path-mapping requirement (with a call-site snippet) and corrects "same store, same credentials" to "same endpoint"; architecture/crate-layout.md notes the new path-mapping responsibility.
• Cargo.lock — incidental catch-up to the 0.7.0 version bump, unrelated to this change.

Test plan

Nine tests added, following the repo's failing-test-first convention. Verified the four that pin the bugs fail against the pre-fix logic (credential comparison restored, override ignored) and pass after:

• copy_source_override_replaces_the_signed_header / ..._without_the_header_is_ignored

• rewrite_copy_source_folds_leading_segments_into_the_bucket / ..._preserves_encoding_and_version / ..._declines_unmappable_values

• unmapped_copy_source_fails_on_a_path_mapping_registry — pins the production symptom (404, backend never contacted)

• mapped_copy_source_override_resolves_the_source — same request succeeds with the override, backend receives /backend-bucket/README.md

• middleware_resolved_destination_still_matches_unresolved_source — the asymmetric-credential case

• copy_succeeds_when_only_the_destination_has_minted_credentials — end-to-end, was 501

• cargo test (full workspace, all green)

• cargo clippy --fix --allow-dirty --allow-staged (clean)

• cargo fmt

• cargo check -p multistore-cf-workers --target wasm32-unknown-unknown

Not yet verified end-to-end against live data.source.coop — that needs a corresponding change in the consumer to call with_copy_source, which is not in this PR.

🤖 Generated with Claude Code

[claude]

Claude finished @alukach's task in 2m 11s —— View job

---

Claude finished reviewing

Todo list

• Gather context (PR body, comments, changed files)
• Fetch diff against origin/main
• Read changed files in full
• Review for correctness/security/best-practice bugs
• Apply ponytail-review pass for over-engineering
• Post final review

---

✅ No blocking issues — safe to merge.

I traced both bugs end to end against the actual call graph, not just the PR description:

• Copy-source rewriting (crates/path-mapping/src/lib.rs:286 rewrite_copy_source, crates/core/src/api/request.rs:47 override plumbing): PathMapping::parse never percent-decodes, so rewrite_copy_source preserves encoding exactly as the existing parse_copy_source (request.rs:104) expects when it later decodes the key — the two halves compose correctly. ?versionId= is split on the literal, unencoded delimiter, matching the real header grammar (a literal ? can't appear in a properly-encoded key). None-on-too-few-segments falls through to the raw header, so the error the client sees on a genuinely bad source is the real NoSuchBucket/InvalidRequest, not a synthesized one. Both real call sites of parse_s3_request (proxy.rs:342, proxy.rs:693) were updated; no orphaned caller left on the old signature.
• same_backing_store → same_s3_endpoint (crates/core/src/proxy.rs:1670): confirmed by reading execute_copy (proxy.rs:1585) directly — sign_s3_request signs with dest_config only; src_config is used exclusively to build the x-amz-copy-source value (bucket name + prefix) via build_copy_source_header. So the removed credential comparison never gated an actual credential use; it only rejected asymmetric-credential same-endpoint copies that should have succeeded. Caller-side authorization is untouched — dispatch_operation's CopyObject arm (proxy.rs:1073) still authorizes the destination write via the main pipeline and the source read via a synthetic GetObject through get_bucket, both before execute_copy runs. The three new authorization tests (copy_authorizes_destination_write_and_source_read and the two denial tests) pin exactly that shape.
• Docs (docs/reference/operations.md) accurately reflect the new "same-endpoint" semantics and add the path-mapping caveat with a working code snippet using real symbol names (RequestInfo::with_copy_source, PathMapping::rewrite_copy_source). Cargo.lock diff is purely the 0.6.4→0.7.0 version-bump catch-up, no dependency changes.
• Verified all real (non-test) call sites of parse_s3_request were updated, and same_backing_store has no remaining references anywhere. CI (full cargo test, clippy, fmt, wasm32 check) is green on the latest commit.

No correctness, security, or best-practice issues found in the diff.

Simplify (ponytail): nothing to cut — rewrite_copy_source reuses the existing parse rather than reimplementing segment-splitting, the credential-comparison removal is a deletion (net simpler), and the three new mock registries in proxy.rs tests each pin a genuinely distinct scenario (path-mapped 404, asymmetric OIDC credentials, two-sided authorization) rather than being redundant scaffolding.

---

💰 Estimated review cost: $1.03 · 2m10s · 30 turns

[github-actions]

📖 Docs preview deployed to https://multistore-docs-pr-128.development-seed.workers.dev

• Date: 2026-07-27T18:55:00Z
• Commit: 839ecbe

[github-actions]

🚀 Latest commit deployed to https://multistore-proxy-pr-128.development-seed.workers.dev

• Date: 2026-07-27T18:55:00Z
• Commit: 839ecbe

[alukach]

Authorization review

Question raised on review: does dropping the credential comparison weaken the permission model — is the signer actually checked for read on the source and write on the destination?

Both ends are checked, and the change does not touch that path. Traced through dispatch_operation's CopyObject arm:

• Destination — authorized by the main pipeline. S3Operation::CopyObject.action() is Action::PutObject (types.rs) and .key() is the destination key, so get_bucket(dst, identity, op) sees a write against the key being written.
• Source — authorized inside the copy handler by a synthetic GetObject { src_bucket, src_key } passed to get_bucket, i.e. the exact authorization a real GET of that source object would get. execute_copy then reuses the same src_key, so the key that was authorized is the key that gets copied.

Both land before the backend is contacted, and validate_key rejects ./.. segments on the source key, so the source's backend_prefix cannot be escaped. Anonymous callers are rejected at the destination write.

The credentials that were being compared were never an authorization control: the copy is signed with the destination's credentials, and the source config contributes only bucket_name + prefix (build_copy_source_header) — its credentials are never used for anything. Dropping the comparison therefore grants a caller nothing the registry did not already authorize. What does change: for two buckets on one endpoint backed by different credentials, the proxy now attempts the copy instead of returning 501, so the backend-side boundary is enforced by IAM (AccessDenied, passed through) rather than by a proxy-side guess. A caller still needs registry authorization on both ends to get that far.

Three tests added in aa3414b to pin this, since nothing covered it before (the existing copy tests use a registry that authorizes everything): copy_authorizes_destination_write_and_source_read asserts exactly two authorizations with the right action and key on each end, plus a denial test for each direction.

One pre-existing caveat, unrelated to this PR

x-amz-copy-source accepts ?versionId=, and that version rides through to the backend copy — but the synthetic GetObject used to authorize the source carries no version, and plain GetObject through the proxy drops ?versionId= entirely. So CopyObject is currently the only operation that can address a non-current object version: a caller with read access can copy an older version into a location they control and then read it. Whether that matters depends on whether any deployment treats "overwritten" as "no longer readable". It arrived with the CopyObject feature (#121), not with this change — flagging it rather than folding a behavior change into a bugfix PR. Happy to open a follow-up that either rejects versionId or threads it into the source authorization.