Hi Ramsey,
On 26 Feb 2015, at 3:34 am, Ramsey Gurley <email@hidden> wrote:
On Feb 25, 2015, at 3:07 AM, Paul Hoadley < email@hidden> wrote: Hello,
I have a User entity with a password attribute that contains a BCrypt-hashed password. So User has setPassword() and password() methods, and also cover methods setPlaintextPassword() that does the hashing (and then calls setPassword()) and plaintextPassword() that returns null. It works fine.
Not to get all over your case about it, but how would you ever return a plaintextPassword() from a one way hash?
I don't. It returns null. That indicates to me you are storing the plain password somewhere when you probably shouldn’t.
I'm not. But thanks for caring! :-)
1. Changing the password. A method User.changePassword(String oldPassword, String newPassword, String confirmPassword) would take those form values and do the obvious: change the password if oldPassword hashes correctly and newPassword == confirmPassword.
To me, this doesn’t seem like model logic. I would implement this in a custom component especially for editing passwords.
I think you could make a case for it either way. It seems like an algorithm for describing the circumstances under which User.password is allowed to change.
What I'd like is for it all to be part of the validation system, such that when saveChanges() is called, validateForSave() throws appropriate exceptions and messages could be sent to the view layer. But it's a bit hairy. Consider just setPlaintextPassword(). Say the supplied string is too short and it fails the password length test. My naive solution was to create the ValidationException, but hang onto it until saveChanges() is called—but, and you can see where this is leading, validateForSave() doesn't get called unless the password is actually changed (assuming nothing else on the User is changed), so I don't get to throw that exception I stashed earlier. In that case I might be able to make the change to the too-short string, and do what I was planning, but the changePassword() method is another story.
While WOComponents can have validateKey methods, what you want to do here is validate two values: newPass1, newPass2. That’s something you’d typically do in a validateFor method. But that’s EOValidation interface, and WOComponents don’t do that. In this case, what I would do (did) is compare these values in takeValuesFromRequest on the component and if they are mismatched/empty then create a validation exception and pass it to validationFailedWithException there.
Yeah, I've done something similar in the past.
Thanks Ramsey, I'll check it out. I've also got a custom component for this, I was just wondering if I might get rid of it. Looks like the answer is no.
|