On 5/11/06, Mohammad <name.goes.here44@gmail.com>
wrote:> okay, I''m using login generator. And when I log in alwase get
failed. So
> I looked at my log, I gatherd infomation that says on creation the
> salted pass was: 2b8b06e5a650a4b97f146e6b5ae7ab82c43707e
> on login the salted pass is:
> 2b8b06e5a650a4b97f146e6b5ae7ab82c43707e
> and in my DB it is:
> 2054d52ca901ff70b5a334cb3e13d8c67940c3f3
>
> So in my DB it change why?
While the cause of your problem could be several things, there''s one
thing in particular you should be careful about when using the
login_generator''s generated user model. If you are maintaining
additional attributes in your user model, such as for example
some_flag_attrib1, some_flag_attrib2, and you have an action that
updates only these attributes for some user record, be careful to do
something like this:
@user = User.find(...)
@user.some_flag_attrib1 = value1
@user.some_flag_attrib2 = value2
@user.password_confirmation = @user.password = ""
@user.save_with_validation(false)
If you don''t set password_confirmation and password to an empty
string, the before_update crypt_unless_empty hook in the user model
will clobber your @user''s password with a new (bogus) one (i.e., with
the result of sha1(sha1(original_password))). To prevent this you set
the password_confirmation and password to an empty string (that
crypt_unless_empty does the right thing on the save), but in order to
do this you also have to make sure that any validations that may exist
on the password and/or password_confirmation field do not run on your
save (hence the save_with_validation(false)).
There are other ways around this, but it''s something to keep in mind.
Regards,
--
Bosko Milekic <bosko.milekic@gmail.com>