mirror of
https://github.com/PerpetualSoftware/pad.git
synced 2026-09-21 01:53:33 +00:00
xarmian
ae1df43438
* fix(auth): rotate sessions on password change, TOTP off, OAuth unlink (TASK-652)
handleUpdateCurrentUser previously only updated the password — an
attacker who already stole a session cookie could continue using it
forever even after the owner "rotated" their password. Same issue on
the two other credential-surface-mutating endpoints: disabling 2FA
(handleTOTPDisable) and unlinking an OAuth provider (handleOAuthUnlink).
Extract rotateSessionsAfterCredentialChange:
1. store.DeleteUserSessions(userID) — kills every existing session.
2. Mint a fresh session for the caller via store.CreateSession.
3. Set the new session cookie + CSRF cookie so the caller stays
logged in and doesn't have to re-auth on the current tab.
Call the helper from all three handlers. Best-effort on the delete
step — if it fails we log and still mint a new cookie so the caller
isn't stranded.
Test: TestPasswordChange_InvalidatesOtherSessions establishes two
sessions, changes the password from one, and asserts that (a) a new
session cookie is set, (b) the OTHER session token is 401, and (c)
the original caller token is also 401 (replaced by the fresh one).
Parent: PLAN-643 (OSS Security Hardening).
* fix(auth): return fresh token for Bearer callers after rotation per Codex P2
Codex caught that rotateSessionsAfterCredentialChange only reissued
the caller's session via Set-Cookie. CLI / API clients that authenticate
with 'Authorization: Bearer padsess_...' would be locked out on the
next request after any credential change.
Change the helper to return the new token string. Each handler
(handleUpdateCurrentUser, handleTOTPDisable, handleOAuthUnlink) now
includes the fresh token in its JSON response body so Bearer-only
clients can update their stored credential. Cookie-based clients
continue to pick up the new session transparently via Set-Cookie.