Repository navigation
Validate a password set through the API before hashing it; a password change no longer verifies the email (#570) - #577
Merged
Conversation
… password change verifying the email address (#570)
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #577 +/- ##
=========================================
Coverage 97.04% 97.04%
- Complexity 5298 5302 +4
=========================================
Files 432 433 +1
Lines 13719 13724 +5
=========================================
+ Hits 13313 13318 +5
Misses 406 406
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
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.
Fixes #570.
Validation.
UserNormalizercalledprocessChanges(), which hashedplainPasswordand erased it during denormalization, so API Platform's validation never saw it:PATCH /users/{id} {"plainPassword": "abc"}was a 200, and a password over 4096 characters was a 500 from the hasher.processChanges()no longer hashes.UserDataProcessor::hashPassword()is public and called after validation: on the API by a newUserPasswordStateProcessor(decoratesapi_platform.state_processor.locatorat 16, before the persist and inside the user notification decorator, so the password changed email still compares the new hash), and inEntityPersistFormListenerafterprocessChanges(), after the form has validated.plainPasswordLength(min: 6, max: 4096)is now inDefaultas well asUser:password:create. It ignores null, so a user write without a password is unaffected;NotBlankstays inUser:password:create, so the forms still require a password and the API does not. A constraint in both groups is validated once, so the register form (which validatesDefaultandUser:password:create) reports one violation.Side effect.
hashPassword()no longer setsemailAddressVerified. OnlypasswordReset()sets it, since the reset link proves the inbox (and the unverified login message tells users to reset their password). A password set through the API, the change password form or any custom path leaves verification as it was.Tests:
User\UserPasswordTest: a short or over-long password on PATCH is a 422 onplainPasswordwith the password unchanged and no email; a super admin's POST with a short password is a 422; a valid password is saved hashed and the password changed email sent; setting a password on an unverified user leaves them unverified.UserPasswordStateProcessorTest,UserDataProcessorTest(hashing, no verify,processChanges()does not hash, reset verifies),EntityPersistFormListenerTest(the form path hashes),StateDecoratorServicesTest.🤖 Generated with Claude Code