Jeff, I largely agree with you, but in this case I think it warrants an
exception. If you've enabled encryption, you always have to encrypt
the password, otherwise it won't work when identity goes to verify the
user. So even if you do:
user.password = "foobar"
before you are done setting things up you are going to need to do
user.password = encrypt_password("foobar")
I think that is a pretty short window for people to get tripped up.
The one use case for fiddling with the unencrypted password that I can
think of is a strict password policy. However, you could implement
whatever checks you want to make on the incoming candidate password,
before assigning it to the model.
I know you know all this, so the above is intended to more fully lay
out the argument rather than try to convince you. So when it's
rejected, it's done with open eyes. :-)
The thing that tipped me on this issue was catwalk. If catwalk is
going to be able to set these encrypted passwords, catwalk is going to
need to be modified to allow you to call methods on your model, or this
change is going to need to be made.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~----------~----~----~----~------~----~------~--~---
