Forum: Ruby on Rails Login Generator and Salter

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
0a36dd2d45a8cead5dcfd27a9346f620?d=identicon&s=25 Mohammad (Guest)
on 2006-05-11 06:51
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?
Fb23bc8cd4030c526b0689276b34c8bd?d=identicon&s=25 Bryan Duxbury (bryanduxbury)
on 2006-05-11 16:43
Did you change your salt value in user.rb? If so, that would explain why
the same password doesn't hash the same way anymore.
Dce90ceb553a872aa5c621c363c5ff57?d=identicon&s=25 Bosko Milekic (Guest)
on 2006-05-11 17:45
(Received via mailing list)
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,
This topic is locked and can not be replied to.