Skip to content

chore(deps): bump multistore to 0.7.0 - #190

Merged
alukach merged 2 commits into
mainfrom
chore/bump-multistore-0.7.0
Jul 22, 2026
Merged

chore(deps): bump multistore to 0.7.0#190
alukach merged 2 commits into
mainfrom
chore/bump-multistore-0.7.0

Conversation

@alukach

@alukach alukach commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

Bumps the multistore crate family to 0.7.0, pulling in developmentseed/multistore#115 and the rest of the 0.7.0 release.

What's in 0.7.0

Knock-on changes required by the dep upgrades

The object_store/reqwest/worker bumps in 0.7.0 forced a few local adjustments:

  • worker / worker-macros =0.7.4 → =0.7.5 — multistore-cf-workers 0.7.0 requires worker ^0.7.5
  • our own reqwest 0.12 → 0.13 so HTTP_CLIENT's Client type matches the one multistore-sts::jwks::new now expects (keeps a single reqwest in the tree)
  • enable reqwest's new form feature — .form() became opt-in in 0.13 (was always-on in 0.12) and is needed for the STS post_form call in FetchHttpExchange

Verification

  • cargo check --target wasm32-unknown-unknown ✓
  • cargo clippy --target wasm32-unknown-unknown -- -D warnings ✓
  • cargo test — all suites pass ✓

🤖 Generated with Claude Code

@claude

claude Bot commented Jul 22, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Claude finished @alukach's task in 1m 6s —— View job

Reviewing PR #190: bump multistore to 0.7.0

  • Gather context (PR diff, files changed)
  • Review Cargo.toml changes
  • Review Cargo.lock changes
  • Check for security/correctness issues in dependency bump
  • Post final review

✅ No blocking issues — safe to merge.

  • Cargo.toml:39-42,70 — multistore crate family bumped 0.6.4 → 0.7.0 consistently across all four crates (multistore, multistore-oidc-provider, multistore-path-mapping, multistore-sts, multistore-cf-workers); Cargo.lock confirms matching checksums for all five, no version skew.
  • Cargo.toml:75 — reqwest bumped 0.12 → 0.13 with default-features = false, features = ["form"]. Verified via Cargo.lock that only a single reqwest version resolves in the tree (no duplicate reqwest instances), matching the PR description's stated goal of keeping one reqwest so HTTP_CLIENT's Client type matches what multistore-sts::jwks::new expects.
  • Cargo.toml:87-88 — worker/worker-macros pinned =0.7.4 → =0.7.5, satisfying multistore-cf-workers 0.7.0's worker ^0.7.5 requirement.
  • Cargo.lock diff is consistent with the Cargo.toml bumps — transitive changes (e.g. webpki-roots → rustls-platform-verifier/webpki-root-certs, new aws-lc-rs/aws-lc-sys) are expected fallout of the reqwest 0.12 → 0.13 upgrade (its new default TLS cert-verification stack), not anything introduced by this PR directly. Since the wasm32 target build uses default-features = false here, these TLS-stack deps only apply to non-wasm (test) builds.
  • No stray/unrelated dependency changes, no version downgrades, no obviously vulnerable transitive deps introduced.
  • PR description states cargo check --target wasm32-unknown-unknown, cargo clippy -- -D warnings, and cargo test all pass, consistent with what the diff would require.

@github-actions

github-actions Bot commented Jul 22, 2026 •
edited
Loading

Copy link
Copy Markdown

🚀 Latest commit deployed to https://source-data-proxy-pr-190.source-coop.workers.dev

  • Date: 2026-07-22T23:12:35Z
  • Commit: 1b07f42

@alukach @claude
chore(deps): bump multistore to 0.7.0
85dbedc 
Picks up developmentseed/multistore#115 (0.7.0): STS accepts
AssumeRoleWithWebIdentity params from form-encoded POST bodies,
conditional-write preconditions on PutObject, same-store CopyObject,
plus the object_store 0.14 / reqwest 0.13 / worker unpin upgrade.

Knock-on changes required by the dependency upgrades in 0.7.0:
- worker/worker-macros =0.7.4 -> =0.7.5 (multistore-cf-workers 0.7.0
  requires worker ^0.7.5)
- our own reqwest 0.12 -> 0.13 so HTTP_CLIENT's Client type matches the
  one multistore-sts::jwks::new now expects (single reqwest in the tree)
- enable reqwest's new `form` feature: `.form()` became opt-in in 0.13
  (was always-on in 0.12); needed for the STS post_form call

Verified: cargo check + clippy -D warnings on wasm32, cargo test all pass.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@alukach
alukach force-pushed the chore/bump-multistore-0.7.0 branch from c576d5a to 85dbedc Compare July 22, 2026 05:37
@alukach
alukach marked this pull request as ready for review July 22, 2026 23:11
@alukach
alukach enabled auto-merge (squash) July 22, 2026 23:23
@alukach
alukach disabled auto-merge July 22, 2026 23:23
@alukach
alukach merged commit f8318a0 into main Jul 22, 2026
13 checks passed
@alukach
alukach deleted the chore/bump-multistore-0.7.0 branch July 22, 2026 23:23
@alukach alukach mentioned this pull request Jul 27, 2026
Merged
alukach added a commit that referenced this pull request Jul 27, 2026
@alukach @claude
feat(sts): accept AssumeRoleWithWebIdentity from form-encoded POST bo…
f77e8d2 
…dies (#196)

AWS SDKs send query-protocol operations as a form-encoded `POST` body
with no query string at all, but the worker only ever surfaced the query
string to the router. The STS handler reads its parameters from
`RequestInfo::form_body`, which stayed `None`, so every SDK-shaped
request fell through to the S3 pipeline.

multistore 0.7.0
([developmentseed/multistore#112](developmentseed/multistore#112),
pulled in by #190) added `RequestParts::absorb_form_body` for exactly
this. The dep bump alone does not enable it — the runtime has to call
it, which is what this PR does.

## Behavior

`POST /.sts` with
`Action=AssumeRoleWithWebIdentity&RoleArn=_default&WebIdentityToken=…`
in the body:

| | before | after |
|---|---|---|
| response | 400 `InvalidRequest: unsupported POST operation` | routed
to the STS handler |

Verified locally against `wrangler dev` with the stub API and a
throwaway OIDC key, rebuilding the worker each way to confirm the
difference is this change and not a stale isolate.

## Safety

`absorb_form_body` is a no-op passthrough for every request shape that
is not a form-encoded `POST`, and it rebuilds the body from the
collected bytes — so a mislabeled S3 write (`Content-Type` is
client-controlled: `CompleteMultipartUpload`, `DeleteObjects`) still
reaches the gateway with its payload intact. Collection is skipped
entirely for a form `POST` with a missing or oversized `Content-Length`
rather than buffering it into WASM memory.

## Tests

- `test_sts_form_encoded_body_reaches_the_sts_handler` — needs no
identity token, so it runs on fork PRs. Asserts the response is an STS
rejection (`InvalidIdentityToken`) rather than the S3 fall-through; the
status code alone does not discriminate, since both are 400. Fails on
`main`.
- `test_sts_exchange_accepts_a_form_encoded_body` — the positive path,
under the existing `needs_token` gate.

Full local integration run: 24 passed, 11 skipped (credentialed tier, no
GitHub OIDC token locally).

## Scope

Part of #184. This is one of the two blockers for a true SDK drop-in;
the other is #185 — AWS SDKs validate `RoleArn` client-side (min 20
chars), so `_default` is rejected before the request is ever sent. Both
are needed before `boto3.client("sts", endpoint_url=…)` works
unmodified.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

chore

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@alukach