Duane Johnson
2005-Apr-27 04:40 UTC
What''s the best way for the salted login generator to skip encryption/validation?
I followed Dave Goodlad''s and Joseph Hosteny''s posts about validation. I have a similar issue: I''m using Joseph''s salted login generator and would like to update a record without modifying the password. However, it appears that the validation and hashing of the password occurs every time I update, therefore causing either a) a validation error (e.g. password_confirmation != password) or else b) the password changes due to an encrypted password being encrypted once again. Perhaps someone can help me out with this one, as I''ve found myself running around in loops trying to figure out how to validate in some cases, but not others. It appears from the login generator that the password field goes from [form] through [encryption] to [database]. This is unlike Joseph''s suggestion to Dave that a password_hash field be used to store the encrypted password (and a virtual "password" field used for the form validation etc.) To Joseph: Is there some reason the login generator does not use this password/password_hash mechanism? As the login generator is right now, is there a way to allow a record to be loaded, then saved without the encryption step in between for cases like mine? Thanks for the great job! I sure appreciate the work you (Joseph) have done to make rails coding even easier! -- Duane Johnson (canadaduane)
Joseph Hosteny
2005-Apr-27 12:27 UTC
Re: What''s the best way for the salted login generator to skip encryption/validation?
Duane, See Rails ticket 1196 for an detailed explanation of a proposed solution for this (which I have implemented temporarily in a forthcoming revision of the generator). A number of people responded with good suggestions to my original question. The updated version uses Dave''s suggestion, but there was still the problem to be fixed - how do you turn off password validation (for the builtin validations) when updating a record that was loaded, and therefore the virtual fields were never written to (e.g., during sign-on or password update)? Certainly you can hand code them in the derived validate_on_update handlers - I just didn''t want to rewrite the validations. Joe On Apr 27, 2005, at 12:40 AM, Duane Johnson wrote:> I followed Dave Goodlad''s and Joseph Hosteny''s posts about validation. > I have a similar issue: I''m using Joseph''s salted login generator > and would like to update a record without modifying the password. > However, it appears that the validation and hashing of the password > occurs every time I update, therefore causing either a) a validation > error (e.g. password_confirmation != password) or else b) the password > changes due to an encrypted password being encrypted once again. > > Perhaps someone can help me out with this one, as I''ve found myself > running around in loops trying to figure out how to validate in some > cases, but not others. It appears from the login generator that the > password field goes from [form] through [encryption] to [database]. > This is unlike Joseph''s suggestion to Dave that a password_hash field > be used to store the encrypted password (and a virtual "password" > field used for the form validation etc.) To Joseph: Is there some > reason the login generator does not use this password/password_hash > mechanism? As the login generator is right now, is there a way to > allow a record to be loaded, then saved without the encryption step in > between for cases like mine? > > Thanks for the great job! I sure appreciate the work you (Joseph) > have done to make rails coding even easier! > > -- > Duane Johnson > (canadaduane) > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >