mirror of
https://github.com/MBombeck/HealthLog.git
synced 2026-11-09 21:10:59 +00:00
Marc-André Bombeck
60d5416cf8
A browser SSO sign-in landed on /auth/login?error=oidc_failed even though it had succeeded. Two layers conspired: - The service worker enables navigation preload, but its fetch handler returned early for /api/ paths without calling event.respondWith(). For the OIDC login/callback navigations that left the preload unconsumed, so the browser also ran its own default fetch and the callback was requested twice. The first request redeemed the single-use authorization code and set the session; the second tried to redeem the now-consumed code, failed at the IdP token endpoint, and that 307 to the error page is what the user saw. - Even with the double request gone, a legitimate retry (proxy, double navigation) hit the same wall on the server. Fix both layers: - The worker settles /api/auth/* navigations itself, consuming the preload response (or fetching once when there is none), so exactly one request reaches the server. These responses are never cached. - The callback is idempotent. When the single-use state cookie is already consumed but the request carries a database-validated, unexpired session, the callback treats it as a duplicate of a completed login and redirects into the app instead of surfacing an error. The authorization code is never exchanged on this branch, and a consumed/forged/expired state from a caller with no valid session still fails closed with the unchanged oidc_state error. Refs #600
