mirror of
https://github.com/bulwarkmail/webmail.git
synced 2026-10-31 08:13:50 +00:00
Maxwell
8b164c556e
The multi-account refresh-token cookie slot wiring was half-implemented: every account's refresh token ended up on slot 0, so "+ Add Account" silently clobbered the previous account's `jmap_rt` cookie. On page refresh, only the most-recently-added account had a working refresh token; the others bounced to login. Three coordinated changes: 1. `app/[locale]/login/page.tsx` (handleOAuthLogin): write the next-free cookie slot to `sessionStorage['oauth_cookie_slot']` before redirecting to the IdP. `loginWithOAuth` already reads this key but it was never written, so it always defaulted to 0. 2. `stores/auth-store.ts` (loginWithOAuth): distinguish "no value set" (`rawSlot === null`) from "value is 0". Previously `parseInt(getItem(...) || '0')` collapsed both cases, making the `getNextCookieSlot()` fallback unreachable. 3. `stores/auth-store.ts` (loginWithServerSso) + `app/api/auth/sso/complete/route.ts`: pass the slot through the body of the POST and use it for `refreshTokenCookieName(slot)`. Same pattern as the existing `/api/auth/token POST` that already accepts a slot. The server defaults to 0 for back-compat with any caller that omits it. After the fix, signing in with multiple accounts produces distinct `jmap_rt`, `jmap_rt_1`, `jmap_rt_2`, ... cookies (matching the cookieSlot field in account-store) and all accounts survive a page refresh. Repro before the fix: - Sign in with one account, refresh — works. - Click "+ Add Account", sign in with a second account, refresh — second account vanishes from the dropdown; switching to the first account in the dropdown still shows the second account's identity in the From box.