fix(auth): silently refresh standalone (non-OIDC) sessions (MAPPS-374) #435
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/MAPPS-374-standalone-silent-refresh"
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?
Summary
Fixes MAPPS-374: standalone (legacy email+password) sessions had no silent refresh, so users were logged out roughly one access-token lifetime (~1h) after signing in.
Root cause
The SPA has two auth paths. The OIDC path (bunyip-as-OP) has
use_token_refresh(src/hooks/auth.rs), which rotates the ~10-min at+jwt before expiry. The standalone path had no refresh loop - the deferred follow-up called out insrc/pages/login.rs. A standalone session stores{ access_token, refresh_token, expires_at, user }in sessionStorage (STANDALONE_KEY) withAuthContext.tokens = None, so the OIDC loop skips it. When mokosh-server's 1-hour standalone access token expired, the next 401 hitrefresh_user_from_me, which cleared the session - even though a valid 7-day (30-day remember-me) refresh token was sitting unused in sessionStorage.Fix (client-only)
Add
use_standalone_token_refresh, the standalone twin ofuse_token_refresh, mounted once at the app root (main.rs). Each 30s tick reloads the persistedStandaloneSessionand, once the access token is within 60s of expiry, rotates it viaPOST /api/v1/auth/refresh(endpoint already exists, returns rotated tokens), persisting the result to sessionStorage and the fetch access-token holder. On any refresh failure it clears the session and redirects to /login, matching the OIDC error branch.tokens = None) - each hook owns exactly one session type.POST /api/v1/auth/refreshalready rotates and returns{ access_token, refresh_token, expires_at }.Testing
cargo fmt,cargo clippy --all-targets -- -D warnings, andcargo check --target wasm32-unknown-unknownall green in the pinned rust-builder image.Scope
This addresses only the standalone logout. The separate bunyip/OIDC logout (~10 min, a failing OIDC refresh) is being pinned from live logs/console evidence and will get its own issue + fix.