Hi there, I use login generator to do user authorization and things works fine. But now if I have a user edit form, even though I don''t include the password column inside the form for edit, once user click saved the password will be changed and I have to reset the password again. I have a feeling it''s due to the format of the password. Is there any command or something I need to make sure the password format be unchanged when I use anything update or save? Thank you . sammy --------------------------------- DO YOU YAHOO!? 雅虎免费G邮箱－中国第一绝无垃圾邮件骚扰超大邮箱 _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
The login generator only re-encrypts/saves the password if it''s not empty, so my suggestion is to make sure that @user.password is empty (nil) at all times, except for when you purposely populate it with a new password. Eg: @user.password = @params[:new_password] @user.password_confirmation = @params[:new_password_confirmation] Do some experimenting, and you should be able to understand what''s going on. Justin On 06/09/2005, at 10:52 AM, s c wrote:> Hi there, > I use login generator to do user authorization and things works > fine. But now if I have a user edit form, even though I don''t > include the password column inside the form for edit, once user > click saved the password will be changed and I have to reset the > password again. I have a feeling it''s due to the format of the > password. Is there any command or something I need to make sure the > password format be unchanged when I use anything update or save? > > Thank you . > sammy > > DO YOU YAHOO!? > 雅虎免费G邮箱－中国第一绝无垃圾邮件骚扰超大邮箱 > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >--- Justin French, Indent.com.au justin.french-zULN+VWqVOIpAS55Wn97og@public.gmane.org Web Application Development & Graphic Design
The default "login generator" code does a "before_save" callback called hash_unless_empty or something like that. (Going from memory here.) The problem is that this assumes the user has filled in the password field again with something plaintext. Otherwise, it''s re-hashing your hashed password, and mangling it beyond repair. You can: 1. Disable that before_save call. 2. Modify it so that it doesn''t get called in the particular circumstance you''ve run into. 3. Define a separate accessor in the model for the cleartext password that is not a column in the database. (e.g. password, when ''hashed_password'' is the database column.) You would then modify the User model to support this. #3 is what I ended up doing, because it makes it easy to see what''s going on in the code. If ''password'' has something in it, and we''re saving the User, then hash it and store that in the hashed_password field. Otherwise, we''re not changing the password, so leave it all alone. --Wilson. On 9/5/05, s c <inno_hub-/E1597aS9LRv1O+Z8WTAqQ@public.gmane.org> wrote:> Hi there, > I use login generator to do user authorization and things works fine. But > now if I have a user edit form, even though I don''t include the password > column inside the form for edit, once user click saved the password will be > changed and I have to reset the password again. I have a feeling it''s due > to the format of the password. Is there any command or something I need to > make sure the password format be unchanged when I use anything update or > save? >
On 9/5/05, Wilson Bilkovich <wilsonb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > The default "login generator" code does a "before_save" callback > called hash_unless_empty or something like that. (Going from memory > here.) > > The problem is that this assumes the user has filled in the password > field again with something plaintext. Otherwise, it''s re-hashing your > hashed password, and mangling it beyond repair. > You can: > 1. Disable that before_save call. > 2. Modify it so that it doesn''t get called in the particular > circumstance you''ve run into. > 3. Define a separate accessor in the model for the cleartext password > that is not a column in the database. (e.g. password, when > ''hashed_password'' is the database column.) You would then modify the > User model to support this. > > #3 is what I ended up doing, because it makes it easy to see what''s > going on in the code. If ''password'' has something in it, and we''re > saving the User, then hash it and store that in the hashed_password > field. Otherwise, we''re not changing the password, so leave it all > alone.I usually make the password update a separate form with it''s own action that only updates the password, with the password field labeled as ''New Password'' and always empty. In the OP''s case though the simplest thing to do is to just have a hidden field for the password and make it empty. Chris _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails