fix(auth): source the user role from mokosh-server /api/v1/auth/me (PMS-158) #100

Merged

longjacksonle merged 1 commit from fix/mapps-158-role-from-server-me into main

2026-06-10 00:40:58 +02:00

longjacksonle commented

2026-06-10 00:38:02 +02:00

Owner

What

Fix the signed-in user's role always displaying as technician (PMS-158) by sourcing the role from mokosh-server's authoritative GET /api/v1/auth/me.

Root cause

The role was read from the OIDC id_token, but that claim cannot carry the mokosh role: bunyip mints its own bunyip_role (subscriber / admin) and the mapping to a mokosh role (admin -> super_admin, etc.) is applied server-side (PMS-172). So the id_token claim the SPA parsed was absent and every user fell back to the Technician default. The code that would have corrected it fetched /v1/auth/me from the issuer (bunyip), which 404s (observed in dev logs).

Changes

refresh_user_from_me now fetches GET /api/v1/auth/me via the API client (the mokosh-server endpoint that returns the already-translated role), dropping the unused OidcConfig argument.
An unrecognized role value is handled explicitly (warn + keep the current role) instead of being silently coerced to Technician.
Add use_current_user_loader, mounted at the app root, so the authoritative user is fetched once on first authenticated mount. Previously the merge only ran inside the token-refresh loop, so the corrected role would not appear until the first refresh window; now it is correct right after login and on rehydrate.

Unblocks

MAPPS-133: a technician fails can_view_financials, so once the role is correct an admin / manager can open the billing pages.

Dependencies

bunyip emitting bunyip_role - access token: BUNYIP-66 (already merged); id token: companion bunyip PR psa-systems/bunyip#86. mokosh-server needs no change (PMS-172 already reads bunyip_role).

Verification

cargo check --target wasm32-unknown-unknown and cargo fmt --check clean. (The one host clippy hit is clippy::manual_checked_ops on pre-existing projects.rs:685, a lint that only exists in host rust 1.95; CI runs rust 1.94 where it does not fire.)

🤖 Generated with Claude Code

## What Fix the signed-in user's role always displaying as **technician** (PMS-158) by sourcing the role from mokosh-server's authoritative `GET /api/v1/auth/me`. ## Root cause The role was read from the OIDC **id_token**, but that claim cannot carry the *mokosh* role: bunyip mints its own `bunyip_role` (`subscriber` / `admin`) and the mapping to a mokosh role (`admin -> super_admin`, etc.) is applied **server-side** (PMS-172). So the id_token claim the SPA parsed was absent and every user fell back to the `Technician` default. The code that would have corrected it fetched `/v1/auth/me` from the **issuer (bunyip)**, which 404s (observed in dev logs). ## Changes - `refresh_user_from_me` now fetches `GET /api/v1/auth/me` via the API client (the mokosh-server endpoint that returns the already-translated role), dropping the unused `OidcConfig` argument. - An unrecognized role value is handled explicitly (warn + keep the current role) instead of being silently coerced to `Technician`. - Add `use_current_user_loader`, mounted at the app root, so the authoritative user is fetched once on first authenticated mount. Previously the merge only ran inside the token-refresh loop, so the corrected role would not appear until the first refresh window; now it is correct right after login and on rehydrate. ## Unblocks MAPPS-133: a technician fails `can_view_financials`, so once the role is correct an admin / manager can open the billing pages. ## Dependencies bunyip emitting `bunyip_role` - access token: **BUNYIP-66** (already merged); id token: companion bunyip PR psa-systems/bunyip#86. mokosh-server needs no change (PMS-172 already reads `bunyip_role`). ## Verification `cargo check --target wasm32-unknown-unknown` and `cargo fmt --check` clean. (The one host clippy hit is `clippy::manual_checked_ops` on pre-existing `projects.rs:685`, a lint that only exists in host rust 1.95; CI runs rust 1.94 where it does not fire.) 🤖 Generated with [Claude Code](https://claude.com/claude-code)

longjacksonle added 1 commit

2026-06-10 00:38:02 +02:00

fix(auth): source the user role from mokosh-server /api/v1/auth/me (PMS-158)

Check / clippy + fmt + tests (pull_request) Successful in 44s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

3508e1eb95

The signed-in user's role always displayed as technician. The role was read from the OIDC id_token, but that claim cannot carry the mokosh role: bunyip mints its own bunyip_role (subscriber / admin) and the mapping to a mokosh role (admin -> super_admin, etc.) is applied server-side (PMS-172). So the id_token claim the SPA parsed was absent and every user fell back to the Technician default. The code that would have corrected it fetched /v1/auth/me from the issuer (bunyip), which 404s.

Point the correction at the authoritative source instead: GET /api/v1/auth/me on mokosh-server, which returns the already-translated mokosh role. refresh_user_from_me now fetches via the API client (dropping the unused OidcConfig argument), and an unrecognized role is handled explicitly (warn + keep the current role) rather than silently coerced to Technician.

Add use_current_user_loader, mounted at the app root, so the authoritative user (role, name, avatar) is fetched once on first authenticated mount. Previously the merge only ran inside the token-refresh loop, so the corrected role would not appear until the first refresh window; now it is correct right after login and on rehydrate.

This unblocks MAPPS-133: a technician fails can_view_financials, so once the role is correct an admin / manager can open the billing pages.

Depends on bunyip emitting bunyip_role (access token: BUNYIP-66, already merged; id token: the companion bunyip PR). mokosh-server needs no change (PMS-172 already reads bunyip_role). Verified: cargo check --target wasm32-unknown-unknown and cargo fmt --check clean.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>