Hi Ramsey, On 26 Feb 2015, at 3:34 am, Ramsey Gurley <[email protected]> wrote:
> On Feb 25, 2015, at 3:07 AM, Paul Hoadley <[email protected]> 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. > If you’d like, have a look at my implementation: > > https://github.com/nullterminated/ponder/blob/master/ERAuth/Sources/er/auth/components/ERAEditPassword.java > > https://github.com/nullterminated/ponder/blob/master/ERUsers/Sources/er/users/model/ERUser.java 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. -- Paul Hoadley http://logicsquad.net/
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
