fix(auth): re-enable real GET /v1/auth/memberships call (MAPPS-379) #441
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/mapps-379-memberships"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What
Re-enable the real
GET /v1/auth/membershipscall inuse_memberships_loaderso AuthContext reflects the user's actual bunyip memberships, replacing the locally synthesized single membership (MAPPS-379).Why
The synthetic membership was introduced because bunyip's
AuthenticatedUserextractor only validated legacy HS256 access tokens, so the SPA's EdDSAat+jwt401'd. BUNYIP-55 removed that blocker: the extractor now routestyp == "at+jwt"tokens to the OidcProvider verifier (signature +iss+exp+typ, withvalidate_aud = false), so the SPA's Mokosh-audienceat+jwtis accepted at bunyip's/v1/*endpoints. The inline comment claiming bunyip rejects the EdDSAat+jwtwas therefore stale, and theMembershipViewdeserialize struct was dead code.Changes
src/hooks/auth.rs:use_memberships_loadernow callsissuer_get_authed::<Body>(&cfg, "/v1/auth/memberships")and, on a non-empty response, stores the deserializedMembershipViewrows and adopts the response'sactive_tenant_id.synthesize_single_membershiphelper. This keeps the switcher UI working (correct today under single-tenant-per-user, PMS-447) and prevents the effect from re-firing forever on a persistently empty membership list.at+jwtwith a 401) with the accurate BUNYIP-55 rationale.Tests
just pre-commitin the CI-matchingrust-builder-glibcimage:cargo fmt --all --check,cargo clippy --all-targets -- -D warnings,cargo check --target wasm32-unknown-unknown, andcargo test --liball pass (see PR checks for the recorded run)./v1/auth/memberships.