feat(auth): rewritten path support#34
Merged
Merged
Conversation
|
🚀 Latest commit deployed to https://multistore-proxy-pr-34.development-seed.workers.dev
|
e50e70f to
fb6900c
Compare
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
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.
What I'm changing
When
path-mappingrewrites an incoming request (e.g./acme/data/report.csv→/acme:data/report.csv, or stripping a prefix segment from aprefix=query param during a list), the proxy was running SigV4 verification against the rewritten path/query. Since clients sign the path they actually sent, verification fails for any request that triggers a rewrite. This change carries the original client-facing path and query through to the auth step so signature verification matches what the client signed, while operation parsing continues to use the rewritten form.How I did it
path-mapping: replaced the(String, Option<String>)return tuple fromPathMapping::rewrite_requestwith a newRewriteResult { path, query, signing_path, signing_query }struct. The rewritten values feed the operation parser; the signing values preserve the original client-facing path/query for signature verification. All three rewrite branches (direct map, prefix-routed list, pass-through) populate the new fields, with tests updated and expanded to assert on both pairs.route_handler::RequestInfo: added optionalsigning_pathandsigning_queryfields, pluswith_signing_path/with_signing_querybuilder methods. When unset, the request's ownpath/queryare used so existing callers that don't rewrite are unaffected.router: threadssigning_path/signing_queryfrom the incomingRequestInfointo the matched route'sRequestInfoso rewrites set upstream survive the route match.proxy::resolve_request_with_metadata: refactored from a 5-parameter signature into one that takes&RequestInfo<'_>. This was a prerequisite to thread the new signing fields through cleanly without growing the parameter list further.auth::resolve_identityis now called withsigning_path.unwrap_or(path)andsigning_query.or(query)so verification uses the client-signed values when present.Test plan
cargo check— passescargo check -p multistore-cf-workers --target wasm32-unknown-unknown— passespath-mappingtests updated to cover both rewritten and signing fields across all rewrite cases