fix: allow password change in user settings#2322
Open
mvanhorn wants to merge 2 commits into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds the ability to change your password from user settings. The settings page now shows a password-change form (current + new password) for accounts that have a local password, posts to a new
PUT /api/v1/settings/passwordendpoint that verifies the current password before updating, and hides the form for OAuth-only accounts.Why this matters
Issue #1321 reports there is no way to change a password in user settings. Accounts created with email/password had no in-app path to rotate their password. This adds the missing flow end to end: a
change_passwordchangeset onCodebattle.Userthat validates the current password againstpassword_hashand applies the new one, asettings_controlleraction wired atPUT /api/v1/settings/password, and the settings form UI to drive it.Whether the form appears is driven by a real
has_passwordcapability sent in the initial page payload (viaAssignGon.prepare_user), so a Firebase/email-password user and a local-password-with-OAuth user each see the correct form on first render, rather than the frontend guessing from linked-provider IDs.Testing
mix teston the settings controller and the AssignGon plug — 11 tests pass, covering a correct current password, a wrong current password (rejected), and thehas_passwordpayload for local vs OAuth users.jest UserSettings.test.jsx— 8 tests pass, covering first-render form visibility for local-password, Firebase, and OAuth-linked accounts.mix format --check-formattedandoxfmt --checkclean on changed files.Fixes #1321