8 ms·
Use attr_protected or we will hack you
- icky 19y agoDon't send object publishing to do a URL dispatcher's job!
- bprater 19y agoGreat advice!
- russ 19y agoAs other commenters have said, attr_accessible is a better choice IMO. I'd rather protect everything by default.
- jasonlbaptiste 19y agonot a rails guy, but great no bullshit advice nonetheless.
- jsjenkins168 19y agoThe 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 19y agoYes, 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 19y agofyi: the save is redundant. update_attributes saves the record for you.
- deleted 19y ago[deleted]
- mhartl 19y agoThey 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.)
- ajkirwin 19y agoI'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 :)