fix(auth): logout via bunyip OptionalUser endpoint, Profile -> /settings, synthesize memberships locally #78

Merged
YousifShkara merged 1 commit from fix/logout-profile-memberships-noise into main 2026-06-06 02:32:43 +02:00
Owner

Three independent regressions on the calendar screenshot, all rooted in mokosh-clients' interaction with the Bunyip identity provider.

Profile link 404. The user menu pointed at ${hub}/settings/profile. bunyip-web has /settings (general account settings) but no /settings/profile route, so the link 404'd on Bunyip. Pointed the menu item at /settings until Bunyip ships a dedicated profile page.

Logout no-op. The menu's logout navigated to bunyip-web /logout, which proxies through bunyip-api POST /v1/auth/logout (requires AuthenticatedUser). bunyip's AuthenticatedUser extractor only validates legacy HS256 access tokens; users who arrived through OIDC may not satisfy that extractor cleanly, in which case bunyip-web's .unwrap_or_default() swallows the 401 and forwards to /login without clearing cookies. /login's is_signed_in() then bounces them straight back to the dashboard. Switched the redirect target to bunyip-api GET /v1/auth/logout?url=<bunyip-login>, which is backed by OptionalUser (always clears the .a8n.systems-scoped cookies via Set-Cookie, regardless of token validation) and redirects to bunyip-web /login?redirect=...&checked=1. The user ends up on bunyip's login page, fully signed out.

Memberships 401. use_memberships_loader called bunyip's GET /v1/auth/memberships with the OIDC at+jwt the SPA holds. That extractor only validates HS256, so the EdDSA at+jwt fails and the call always 401s on OIDC-authenticated users. Until bunyip's auth extractors accept the at+jwt the issuer itself mints (tracked separately on bunyip), synthesize the same single-membership payload locally: default tenant id 00000000-0000-0000-0000-000000000001, tenant_name = user email, role = owner, status = active. Identical shape to bunyip's stub, no network call, no console noise.

Three independent regressions on the calendar screenshot, all rooted in mokosh-clients' interaction with the Bunyip identity provider. Profile link 404. The user menu pointed at `${hub}/settings/profile`. bunyip-web has `/settings` (general account settings) but no `/settings/profile` route, so the link 404'd on Bunyip. Pointed the menu item at `/settings` until Bunyip ships a dedicated profile page. Logout no-op. The menu's logout navigated to bunyip-web `/logout`, which proxies through bunyip-api `POST /v1/auth/logout` (requires `AuthenticatedUser`). bunyip's `AuthenticatedUser` extractor only validates legacy HS256 access tokens; users who arrived through OIDC may not satisfy that extractor cleanly, in which case bunyip-web's `.unwrap_or_default()` swallows the 401 and forwards to `/login` without clearing cookies. `/login`'s `is_signed_in()` then bounces them straight back to the dashboard. Switched the redirect target to bunyip-api `GET /v1/auth/logout?url=<bunyip-login>`, which is backed by `OptionalUser` (always clears the .a8n.systems-scoped cookies via `Set-Cookie`, regardless of token validation) and redirects to bunyip-web `/login?redirect=...&checked=1`. The user ends up on bunyip's login page, fully signed out. Memberships 401. `use_memberships_loader` called bunyip's `GET /v1/auth/memberships` with the OIDC at+jwt the SPA holds. That extractor only validates HS256, so the EdDSA at+jwt fails and the call always 401s on OIDC-authenticated users. Until bunyip's auth extractors accept the at+jwt the issuer itself mints (tracked separately on bunyip), synthesize the same single-membership payload locally: default tenant id `00000000-0000-0000-0000-000000000001`, tenant_name = user email, role = owner, status = active. Identical shape to bunyip's stub, no network call, no console noise.
fix(auth): logout via bunyip OptionalUser endpoint, Profile -> /settings, synthesize memberships locally
All checks were successful
Create release / Create release from merged PR (pull_request) Has been skipped
Check / clippy + fmt + tests (pull_request) Successful in 1m7s
f076391d19
Three independent regressions on the calendar screenshot, all rooted in mokosh-clients' interaction with the Bunyip identity provider.

Profile link 404. The user menu pointed at `${hub}/settings/profile`. bunyip-web has `/settings` (general account settings) but no `/settings/profile` route, so the link 404'd on Bunyip. Pointed the menu item at `/settings` until Bunyip ships a dedicated profile page.

Logout no-op. The menu's logout navigated to bunyip-web `/logout`, which proxies through bunyip-api `POST /v1/auth/logout` (requires `AuthenticatedUser`). bunyip's `AuthenticatedUser` extractor only validates legacy HS256 access tokens; users who arrived through OIDC may not satisfy that extractor cleanly, in which case bunyip-web's `.unwrap_or_default()` swallows the 401 and forwards to `/login` without clearing cookies. `/login`'s `is_signed_in()` then bounces them straight back to the dashboard. Switched the redirect target to bunyip-api `GET /v1/auth/logout?url=<bunyip-login>`, which is backed by `OptionalUser` (always clears the .a8n.systems-scoped cookies via `Set-Cookie`, regardless of token validation) and redirects to bunyip-web `/login?redirect=...&checked=1`. The user ends up on bunyip's login page, fully signed out.

Memberships 401. `use_memberships_loader` called bunyip's `GET /v1/auth/memberships` with the OIDC at+jwt the SPA holds. That extractor only validates HS256, so the EdDSA at+jwt fails and the call always 401s on OIDC-authenticated users. Until bunyip's auth extractors accept the at+jwt the issuer itself mints (tracked separately on bunyip), synthesize the same single-membership payload locally: default tenant id `00000000-0000-0000-0000-000000000001`, tenant_name = user email, role = owner, status = active. Identical shape to bunyip's stub, no network call, no console noise.
YousifShkara deleted branch fix/logout-profile-memberships-noise 2026-06-06 02:32:43 +02:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
psa-systems/mokosh-apps!78
No description provided.