Clarify Portal reset token and profile save behavior

This commit is contained in:
jester 2026-04-28 21:34:37 +00:00
parent e205af0537
commit cd521513b3

View File

@ -48,12 +48,19 @@ This file records what is implemented now.
## Billing / auth / onboarding
- billing UI alignment exists with the newer billing state model.
- profile save now sends the backend-supported account fields to authenticated `PATCH /api/auth/me`:
- `email` normalized to lowercase after trim
- `username` trimmed
- `firstName`, `lastName`, and `displayName` trimmed
- `409` responses surface a duplicate email/username message
- forgot/reset password flow exists:
- login includes a `Forgot password?` link to `/forgot-password`
- `/forgot-password` posts `{ email }` to `POST /api/auth/password-reset/request`
- the Portal always shows `If the account exists, a reset link has been sent.` for account-lookup-style responses
- `/reset-password?token=...` reads `token`, validates 8+ character password and confirmation match, then posts `{ token, password }` to `POST /api/auth/password-reset/confirm`
- missing, invalid, or expired reset tokens show `This reset link is invalid or has expired.`
- `/reset-password?token=...` reads `token` from query params, trims it, and requires it to be a 64-character hex token before submit
- valid reset submissions post `{ token, password }` to `POST /api/auth/password-reset/confirm`
- client validation requires an 8+ character password and confirmation match
- missing, malformed, invalid, or expired reset tokens show `This reset link is invalid or has expired.`
- successful reset does not auto-login; Portal leaves the user with login navigation
- profile change-password UI exists:
- profile includes current password, new password, and confirm new password fields