
Use attr_protected or we will hack you - pius
http://b.lesseverything.com/2008/3/11/use-attr_protected-or-we-will-hack-you
======
russ
As other commenters have said, attr_accessible is a better choice IMO. I'd
rather protect everything by default.

------
mhartl
They advocate a split between the resources for users and people/profiles.
I've tried it both ways, and my current thinking is that the split isn't worth
the trouble. Being paranoid with attr_accessible and writing good tests are
probably enough. (But I might be wrong.)

------
jsjenkins168
The fact that user credentials (or any sensitive data) is directly modifiable
through a web interface is concerning to me. Shouldn't this logic be protected
in the controller layer?

~~~
fendale
Yes, but it gets protected automatically if you use the mentioned
attr_protected or the accessible version.

Basic Rails code to update your own details on the 'view my details' screen is
something like

    
    
        def update_details
          @logged_in_user = User.find_by_id(session[:userid])
          @logged_in_user.update_attrs(params[:user])
          @logged_in_user.save 
        end
    

Obviously you would never expose the :is_admin flag on the update_details
screen, but a not even very cunning user could guess its there and manufacture
up a post request containing the is_admin flag, setting it using the bulk
assignment above.

Sticking in attr_protected :is_admin in your model means that ActiveRecord
will just ignore that attribute if it is bulk assigned securing it with a
single line of code.

Attr_accessible was new in Rails 2 (I think) - its says deny all BUT the ones
listed - best way by far.

~~~
timr
fyi: the save is redundant. update_attributes saves the record for you.

------
icky
Don't send object publishing to do a URL dispatcher's job!

------
jasonlbaptiste
not a rails guy, but great no bullshit advice nonetheless.

------
bprater
Great advice!

------
ajkirwin
I'm not sure this would actually affect my rails app, because we have a
seperate and distinct authentication process on accounts (which helps!).

Users register and the information is written into a temporary table. Then
user data is copied from that table (and the temporary table doesn't store
anything like 'is_admin') into the active user table upon authentication.

Users are automatically not administrators of course, and the setting of an
admin flag must be done manually.

Works well for us :)

