0

I am following Michael Hartls rails tutorial . Here is the User model class .

class User < ActiveRecord::Base attr_accessible :name, :email, :password, :password_confirmation, :nick_name has_many :microposts, dependent: :destroy has_secure_password end 

The User table in database doesnt contain password/password_confirmation fields. It only has a

password_digest
field. I'm confused , Shouldn't I be using an attr_accessor method on fields that are not present in a table ? I thought that the code must look something like this :

class User < ActiveRecord::Base attr_accessible :name, :email, :password, :password_confirmation, :nick_name attr_accessor :password, :password_confirmation has_many :microposts, dependent: :destroy has_secure_password end 

Because password/password_confirmation are not present in table column , Is'nt attr_accessor required ? I'm thoroughly confused .

2 Answers 2

1

Read the source and it will make sense why the User class does not call attr_accessor :password. The macro itself calls attr_reader :password and you have no need for a password_confirmation accessor.

You also need to think of what the User class should actually be concerned with. password and password_confirmation has to do with authentication. Even though has_secure_password ends up defining authentication related methods in the User class, I argue that we should not be concerned with the implementation details of authentication specifically in the User class. Instead ActiveModel::SecurePassword is. Hence you should not be concerned with defining methods for password and password_confirmation unless specific features that you yourself are defining need to access these attributes.

It's just unfortunate that attr_accessible is required to allow mass assignment of these values in the controller. But there's a reason why this is deprecated in Rails 4.

Sign up to request clarification or add additional context in comments.

4 Comments

Ah..Thanks a lot . I always forget to read the source . Can I ask why it is bad that attr_accessible is required for password and password_confirmation ?
Can you also tell me ,where are we defining the variables password,password_confirmation, name etc ? In the above code , Are they like class instance variables ?
It's not necessarily "bad", but going by my argument in the answer, specifying the "accessibility" of these two attributes give knowledge of implementation details to the User class about authentication. My argument is that User should not really care about the implementation details of authentication since we're relying on has_secure_password to do that for us. I personally trust the developers who wrote this macro and therefore I as the writer of User don't need to worry about white-listing attributes that are has_secure_password specific.
password is an instance variable managed by has_secure_password as shown in the source. password_confirmation is not an instance variable, nor class instance variable, They are accepted as arguments to new, create and etc. in order to confirm that the submitted password is really intended when the object is created.
1

No need to be confused. You are right, attr_accessor is required for non-db backed fields, as it's the getter/setter for that field. On the other hand, attr_accessible is used by Rails to identify which properties are allowed to be assigned by a request (aka. a white list). Given your example, if you don't include password and password_confirmation in the attr_accessible attributes, you wouldn't be able to mass assign them in a request.

2 Comments

So, If I add attr_accessor on password, what is the additional functionality that I can get ?
If I understand correctly, and the password field is not backed by the database, then you gain the ability to get and set its contents. Then if you add it to attr_accessible, you can mass assign.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.