Hi,
I have a "user" model, which has present "attr_accessor
:password"
in the beginning, by which I wish only the password attribute could be
read and written from outside of this class. However, by retrieving a
user instance (e.g @user) by "find(:id)" from database, surprisingly I
noticed I could read every single attribute in this "user" instance
from the view, simply say: #{@user.login}, #{@user.email}, etc.
This is not what I expected, am I misunderstanding something about
the "attr" helper ?
--------------------------------------
The user model''s sexy migration:
create_table "users", :force => true do |t|
t.string :login, :email, :remember_token, :first_name, :last_name
t.string :crypted_password, :limit => 40
t.string :password_reset_code, :limit => 40
t.string :salt, :limit => 40
t.string :activation_code, :limit => 40
t.datetime :remember_token_expires_at, :activated_at, :deleted_at
t.string :state, :null => :no, :default =>
''passive''
t.timestamps
end
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
No, you understand attr_accessor correctly. Under normal circumstances, what you did would only expose password and no other variables. However, there is some Rails magic going on in the background. ActiveRecord automagically creates accessor methods for each attribute your model has. On Jan 29, 3:22 pm, myst_tt <tdxia...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hi, > I have a "user" model, which has present "attr_accessor :password" > in the beginning, by which I wish only the password attribute could be > read and written from outside of this class. However, by retrieving a > user instance (e.g @user) by "find(:id)" from database, surprisingly I > noticed I could read every single attribute in this "user" instance > from the view, simply say: #...@user.login}, #...@user.email}, etc. > This is not what I expected, am I misunderstanding something about > the "attr" helper ? > > -------------------------------------- > The user model''s sexy migration: > create_table "users", :force => true do |t| > > t.string :login, :email, :remember_token, :first_name, :last_name > t.string :crypted_password, :limit => 40 > t.string :password_reset_code, :limit => 40 > t.string :salt, :limit => 40 > t.string :activation_code, :limit => 40 > > t.datetime :remember_token_expires_at, :activated_at, :deleted_at > t.string :state, :null => :no, :default => ''passive'' > > t.timestamps > end--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I found a way to explicitly hide columns. Check out this Rails patch: http://dev.rubyonrails.org/ticket/8355 On Jan 29, 4:20 pm, Wyatt Greene <green...-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:> No, you understand attr_accessor correctly. Under normal > circumstances, what you did would only expose password and no other > variables. However, there is some Rails magic going on in the > background. ActiveRecord automagically creates accessor methods for > each attribute your model has. > > On Jan 29, 3:22 pm, myst_tt <tdxia...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > Hi, > > I have a "user" model, which has present "attr_accessor :password" > > in the beginning, by which I wish only the password attribute could be > > read and written from outside of this class. However, by retrieving a > > user instance (e.g @user) by "find(:id)" from database, surprisingly I > > noticed I could read every single attribute in this "user" instance > > from the view, simply say: #...@user.login}, #...@user.email}, etc. > > This is not what I expected, am I misunderstanding something about > > the "attr" helper ? > > > -------------------------------------- > > The user model''s sexy migration: > > create_table "users", :force => true do |t| > > > t.string :login, :email, :remember_token, :first_name, :last_name > > t.string :crypted_password, :limit => 40 > > t.string :password_reset_code, :limit => 40 > > t.string :salt, :limit => 40 > > t.string :activation_code, :limit => 40 > > > t.datetime :remember_token_expires_at, :activated_at, :deleted_at > > t.string :state, :null => :no, :default => ''passive'' > > > t.timestamps > > end--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Thank you Wyatt, this is so wired... I dont get why in each tutorial book, even DHH''s, it says: using attr_accessor to expose attribute, but actually it isn''t like that ... On 1月29日, 下午11时25分, Wyatt Greene <green...@yahoo.com> wrote:> I found a way to explicitly hide columns. Check out this Rails patch: > > http://dev.rubyonrails.org/ticket/8355 > > On Jan 29, 4:20 pm, Wyatt Greene <green...-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote: > > > No, you understand attr_accessor correctly. Under normal > > circumstances, what you did would only expose password and no other > > variables. However, there is some Rails magic going on in the > > background. ActiveRecord automagically creates accessor methods for > > each attribute your model has. > > > On Jan 29, 3:22 pm, myst_tt <tdxia...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > Hi, > > > I have a "user" model, which has present "attr_accessor :password" > > > in the beginning, by which I wish only the password attribute could be > > > read and written from outside of this class. However, by retrieving a > > > user instance (e.g @user) by "find(:id)" from database, surprisingly I > > > noticed I could read every single attribute in this "user" instance > > > from the view, simply say: #...@user.login}, #...@user.email}, etc. > > > This is not what I expected, am I misunderstanding something about > > > the "attr" helper ? > > > > -------------------------------------- > > > The user model''s sexy migration: > > > create_table "users", :force => true do |t| > > > > t.string :login, :email, :remember_token, :first_name, :last_name > > > t.string :crypted_password, :limit => 40 > > > t.string :password_reset_code, :limit => 40 > > > t.string :salt, :limit => 40 > > > t.string :activation_code, :limit => 40 > > > > t.datetime :remember_token_expires_at, :activated_at, :deleted_at > > > t.string :state, :null => :no, :default => ''passive'' > > > > t.timestamps > > > end--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 1/29/08, Wyatt Greene <greenewm-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:> > No, you understand attr_accessor correctly. Under normal > circumstances, what you did would only expose password and no other > variables. However, there is some Rails magic going on in the > background. ActiveRecord automagically creates accessor methods for > each attribute your model has.Actually, you don''t normally want to use attr_accessor, or attr_writer, or attr_reader for ActiveRecord attributes, despite the name. These generate methods for accessing instance variables, not database columns. And the methods generated for AR attributes get generated the first time the object gets a method_missing, so having an attr_accessor with the same name as an attribute could interfere with AR. I think that the OP is thinking of attr_accessible which is an ActiveRecord::Base class method to "whitelist" attributes for mass assignment, and it''s "blacklist brother" attr_protected -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I think that he meant that attr_accessor is what you''d use in a normal Ruby (non-Rails) context to expose an attribute. That''s a fair statement. It''s not applicable to these ActiveRecord attributes, however, since the Rails team decided to hook method_missing in ARec such that it issues attr_accessor calls for every content_column not identified in the attr_protected and attr_accessible methods you''ve mentioned. The problem with attr_accessible and attr_protected is that they still allow the attributes to be read, just not written. The original post required all the attributes be hidden entirely. On Jan 30, 5:32 pm, "Rick DeNatale" <rick.denat...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 1/29/08, Wyatt Greene <green...-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote: > > > > > No, you understand attr_accessor correctly. Under normal > > circumstances, what you did would only expose password and no other > > variables. However, there is some Rails magic going on in the > > background. ActiveRecord automagically creates accessor methods for > > each attribute your model has. > > Actually, you don''t normally want to use attr_accessor, or > attr_writer, or attr_reader for ActiveRecord attributes, despite the > name. > > These generate methods for accessing instance variables, not database > columns. And the methods generated for AR attributes get generated > the first time the object gets a method_missing, so having an > attr_accessor with the same name as an attribute could interfere with > AR. > > I think that the OP is thinking of attr_accessible which is an > ActiveRecord::Base class method to "whitelist" attributes for mass > assignment, and it''s "blacklist brother" attr_protected > > -- > Rick DeNatale > > My blog on Rubyhttp://talklikeaduck.denhaven2.com/--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---