Allow more advanced, custom password logic #115
Conversation
| @@ -210,7 +221,7 @@ def validate(self): | |||
| user, user_email = user_manager.find_user_by_email(self.email.data) | |||
|
|
|||
| # Handle successful authentication | |||
| if user and user.password and user_manager.verify_password(self.password.data, user): | |||
| if user and user_manager.verify_password(self.password.data, user): | |||
There was a problem hiding this comment.
This change minimizes the assumption that password is a field on the user entity. In reality, verify_password should never be returning True if the user has no password at all.
There was a problem hiding this comment.
For heterogeneous authorization systems, some users do not have a local password (such as those users relying on an external OAuth server). Without a defined password, an attribute error is raised when trying to pass self.password.data into verify_password - thus mandating the extra check.
There was a problem hiding this comment.
self.password.data is on the form itself. I don't know how that could fail unless you're overriding the password input on the form, in which case you can override the validate method as well.
There was a problem hiding this comment.
@pbugni I see now that you added that check. I'm confused why you needed it. With my change (and the way it was before), you can always check user.password within the body of user_manager.verify_password if you override that method on the UserManager.
There was a problem hiding this comment.
If self.password does not exist, then you have clearly changed the original form class and it would make sense that you need to also override the form's validate method to accomodate your changes.
There was a problem hiding this comment.
@3noch - Your assertions are correct about form data - the problem is that when a user doesn't have a password and then they attempt to log in - an error is raised in the call to user_manager.verify_password. I'd forgotten the details when replying earlier today, but it's easy to reproduce - clear the db password for a user and attempt to log in - at the bottom of the error stack:
File ".../env/local/lib/python2.7/site-packages/passlib/context.py", line 1447, in identify_record
raise ExpectedStringError(hash, "hash")
TypeError: hash must be unicode or bytes, not None
The point of this check is clear - if the user doesn't have a password, don't bother trying to verify. Yes, you could alternatively patch the lower level checks, but this seemed like the clean work around to me.
There was a problem hiding this comment.
I can re-add that check to the default implementation of verify_password. Do you think that would solve your case?
There was a problem hiding this comment.
Yes - that'd be great. I can test your branch when it's ready. Thanks.
There was a problem hiding this comment.
@pbugni Ok, I added that check to verify_password.
|
Hi @3noch! Thank you for your contribution! During last 4 years (I'm sorry that you are waiting for so long) many things were changed in |
and-semakin
added
the
Rebase Requested
I needed to validate passwords based on the user's information (username not included in password, password not reused from previous password). This motivated several changes:
userentity available to password-handling forms (and therefore their validators)passwordfield on theUserentity when verifying passwords (since passwords might be in another table).I designed this change in such a way that it should have minimal effect on current users of
Flask-User. They are likely subclassing your Form classes, so the additionaluserinformation will be silently ignored in their case but won't cause any issues.