Forum: Ruby on Rails reuse of attribute

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.
Scott P. (Guest)
on 2008-11-28 21:47
Attachment: player.rb (0 Bytes)
Kind of confused about why this happened.

Initially, my "players" table had a column named "password".  While
learning about hashing, I had a model similar to the above, except the
before_create looked like this:

  self.password = Player.hashed_password(self.password)

When I saved a player, I always got null in the password in the
database.

But, if I set the hashed_password into some other attribute
(self.last_name, let's say), I ended up with a hash value in the
last_name column.

So all I did was to drop and create the table with the column called
"hashed_password" instead, and updated the model as attached, and off I
went.

I don't understand why the 'password' column kept getting nulled
initially, though.  I expected it would act like java; a reference to
the password attribute (string) would be passed into the hashed_password
method, which would return a reference to a new string, which I would
happen to assign to the hashed_password attribute.

Can anyone shed a little light on what's under the covers?  Just a
curiousity question, it's all good after the rename.
Erol F. (Guest)
on 2008-11-29 11:17
(Received via mailing list)
On Nov 29, 3:47 am, Scott P. <removed_email_address@domain.invalid>
wrote:
>
> the password attribute (string) would be passed into the hashed_password
> method, which would return a reference to a new string, which I would
> happen to assign to the hashed_password attribute.
>
> Can anyone shed a little light on what's under the covers?  Just a
> curiousity question, it's all good after the rename.
>
> Attachments:http://www.ruby-forum.com/attachment/2981/player.rb
>
> --
> Posted viahttp://www.ruby-forum.com/.

I'm guessing that you may have overwritten the default AR accessor for
'password' with your call to:

attr_accessor :password

Hence, the 'password' field not being saved to the db.

A better approach, IMHO, is naming your password field differently
(like password_hash) and saving it with a the below password method:

def password=(password)
  self.password_hash = Digest::SHA1.hexdigest(password)
end

That way, you can set a new password for the given player even after
it has already been created.
Scott P. (Guest)
on 2008-11-29 20:45
Erol F. wrote:
> On Nov 29, 3:47?am, Scott P. <removed_email_address@domain.invalid>
> wrote:
>>
>> the password attribute (string) would be passed into the hashed_password
>> method, which would return a reference to a new string, which I would
>> happen to assign to the hashed_password attribute.
>>
>> Can anyone shed a little light on what's under the covers? ?Just a
>> curiousity question, it's all good after the rename.
>>
>> Attachments:http://www.ruby-forum.com/attachment/2981/player.rb
>>
>> --
>> Posted viahttp://www.ruby-forum.com/.
>
> I'm guessing that you may have overwritten the default AR accessor for
> 'password' with your call to:
>
> attr_accessor :password
>
> Hence, the 'password' field not being saved to the db.
>
> A better approach, IMHO, is naming your password field differently
> (like password_hash) and saving it with a the below password method:
>
> def password=(password)
>   self.password_hash = Digest::SHA1.hexdigest(password)
> end
>
> That way, you can set a new password for the given player even after
> it has already been created.

Yep, absolutely right--exactly what I did is re-name the db column as
you show, and off I went.

I was thinking of them like members of a java class, I'll have to read
up on the attr_accessor and how these objects actually act.

Thank you for the response.
This topic is locked and can not be replied to.