psa-systems/bunyip
Watch
9
0
Fork
You've already forked bunyip
 0
Code Issues Pull requests Projects Releases 18 Packages Wiki Activity Actions

feat(settings): suppress browser autofill on email / delete-account forms #98

Merged
YousifShkara merged 1 commit from feat/bunyip-upgrade-02-settings-hygiene into main 2026-06-10 08:03:25 +02:00
Conversation 0 Commits 1 Files changed 1 +27 -11
YousifShkara commented 2026-06-10 08:03:20 +02:00
Owner
Copy link

Settings was rendering with the user's saved email pre-filled in the "New Email Address" input, and with dots in all three password fields (change-email current_password, change-password current_password, delete-account password). Both were browser autofill driven off the saved login credential, not server-side pre-fill - but the visual effect was the same: confusing on the email-change form (the user has to clear it before typing the NEW address) and genuinely risky on the delete-account form (a password manager pre-fill plus a single misclick could permanently delete the account).

The three forms differ in what we want the password manager to do, so the autocomplete hints differ too:

  • Change Email (audit findings 3 + 4a): the whole <form> gets autocomplete="off". The new-email input ALSO gets value="" explicitly (defeats the saved-username path) and autocomplete="off". The current-password input here is a confirmation-of-identity step, not a sign-in, so it gets autocomplete="off" too rather than autocomplete="current-password" (the latter would invite the manager to fill).
  • Change Password: the one form where the password manager SHOULD help. current_password keeps autocomplete="current-password" so the saved password fills; new_password and confirm get autocomplete="new-password" so the manager offers to save the updated credential after submit.
  • Delete Account (audit finding 4c): the form and its password input both get autocomplete="off". The TOTP field (rendered when user.two_factor_enabled) picks up inputmode="numeric" and autocomplete="one-time-code" so AutoFill can surface a freshly-arrived code from a sibling tab without touching the password field.

autocomplete="off" on password fields is best-effort - some browsers ignore it - but the combination of autocomplete="off" on the form + value="" + the absence of the affirmative autocomplete="current-password" hint is the strongest signal the spec lets us send.

Closes audit findings 3 (new-email pre-fill) and 4 (password fields pre-filled). See docs/bunyip-upgrade/02-settings-form-hygiene.md for the full spec.

Settings was rendering with the user's saved email pre-filled in the "New Email Address" input, and with dots in all three password fields (change-email current_password, change-password current_password, delete-account password). Both were browser autofill driven off the saved login credential, not server-side pre-fill - but the visual effect was the same: confusing on the email-change form (the user has to clear it before typing the NEW address) and genuinely risky on the delete-account form (a password manager pre-fill plus a single misclick could permanently delete the account). The three forms differ in what we want the password manager to do, so the autocomplete hints differ too: - **Change Email** (audit findings 3 + 4a): the whole `<form>` gets `autocomplete="off"`. The new-email input ALSO gets `value=""` explicitly (defeats the saved-username path) and `autocomplete="off"`. The current-password input here is a confirmation-of-identity step, not a sign-in, so it gets `autocomplete="off"` too rather than `autocomplete="current-password"` (the latter would invite the manager to fill). - **Change Password**: the one form where the password manager SHOULD help. current_password keeps `autocomplete="current-password"` so the saved password fills; new_password and confirm get `autocomplete="new-password"` so the manager offers to save the updated credential after submit. - **Delete Account** (audit finding 4c): the form and its password input both get `autocomplete="off"`. The TOTP field (rendered when `user.two_factor_enabled`) picks up `inputmode="numeric"` and `autocomplete="one-time-code"` so AutoFill can surface a freshly-arrived code from a sibling tab without touching the password field. `autocomplete="off"` on password fields is best-effort - some browsers ignore it - but the combination of `autocomplete="off"` on the form + `value=""` + the absence of the affirmative `autocomplete="current-password"` hint is the strongest signal the spec lets us send. Closes audit findings 3 (new-email pre-fill) and 4 (password fields pre-filled). See `docs/bunyip-upgrade/02-settings-form-hygiene.md` for the full spec.
feat(settings): suppress browser autofill on email / delete-account forms
All checks were successful
Create release / Create release from merged PR (pull_request) Has been skipped
Details
Check / fmt / clippy / build / test (pull_request) Successful in 1m6s
Details
296ea05412 
Settings was rendering with the user's saved email pre-filled in the "New Email Address" input, and with dots in all three password fields (change-email current_password, change-password current_password, delete-account password). Both were browser autofill driven off the saved login credential, not server-side pre-fill - but the visual effect was the same: confusing on the email-change form (the user has to clear it before typing the NEW address) and genuinely risky on the delete-account form (a password manager pre-fill plus a single misclick could permanently delete the account).

The three forms differ in what we want the password manager to do, so the autocomplete hints differ too:

- **Change Email** (audit findings 3 + 4a): the whole `<form>` gets `autocomplete="off"`. The new-email input ALSO gets `value=""` explicitly (defeats the saved-username path) and `autocomplete="off"`. The current-password input here is a confirmation-of-identity step, not a sign-in, so it gets `autocomplete="off"` too rather than `autocomplete="current-password"` (the latter would invite the manager to fill).
- **Change Password**: the one form where the password manager SHOULD help. current_password keeps `autocomplete="current-password"` so the saved password fills; new_password and confirm get `autocomplete="new-password"` so the manager offers to save the updated credential after submit.
- **Delete Account** (audit finding 4c): the form and its password input both get `autocomplete="off"`. The TOTP field (rendered when `user.two_factor_enabled`) picks up `inputmode="numeric"` and `autocomplete="one-time-code"` so AutoFill can surface a freshly-arrived code from a sibling tab without touching the password field.

`autocomplete="off"` on password fields is best-effort - some browsers ignore it - but the combination of `autocomplete="off"` on the form + `value=""` + the absence of the affirmative `autocomplete="current-password"` hint is the strongest signal the spec lets us send.

Closes audit findings 3 (new-email pre-fill) and 4 (password fields pre-filled). See `docs/bunyip-upgrade/02-settings-form-hygiene.md` for the full spec.
YousifShkara deleted branch feat/bunyip-upgrade-02-settings-hygiene 2026-06-10 08:03:25 +02:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
YousifShkara
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
psa-systems/bunyip!98
No description provided.