#26 Hackers Love Mass Assignment (revised)

Nevermind, I just read the show notes.

Yeah, after seeing DHH's example I had some fun spending a few minutes making a little "plugin" for that[1].
We already use the as option[2] in our code though so I haven't had the chance to really work on that yet.

[1] = https://gist.github.com/2014589
[2] = http://guides.rubyonrails.org/security.html#countermeasures

Tax deductable if you own a business, or print out the invoice and ask your employer for a reimbursement. Just like David said below, this is one of the few places that I can always find good ACTIONABLE!! content and not feel ripped off, at $9 / month it's cheap.

I enjoyed Railscasts for years, I pretty much learned rails through railscasts. This month I got my subscription to pro. I don't regret one penny.
I guess, in the long run, that's necessary to keep Ryan doing what he does. Advertising financed only gets you so far.

And important episodes, like this one, may help in creating a bit more revenue, don't you think?

For everyone telling me to get a subscription. I already have one or I wouldn't have been able to comment here in the first place.

I was merely pointing out that since this is suddenly a large, important, issue which has blown up in everyone's faces maybe this one time the revised episode could go out to all in the spirit of public service.

I believe the ActiveModel::MassAssignmentSecurity module was changed for the release of Rails 3.1.

Now you can do this (in a non-ActiveRecord class):

include ActiveModel::MassAssignmentSecurity

attr_accessible :first_name, :last_name
attr_accessible :first_name, :last_name, :plan_id, :as => :admin

http://api.rubyonrails.org/classes/ActiveModel/MassAssignmentSecurity.html
http://api.rubyonrails.org/classes/ActiveModel/MassAssignmentSecurity/ClassMethods.html

On the other hand there is an argument for putting the protection into the model rather than controller:

Protecting attributes from within controllers sounds like a setup to have multiple points of fault. If I have more than one controller making saves/updates on the same model (ignoring a debate over if that is good design), then I have to remember to protect attributes in multiple controllers. If I handle mass assignment from the model, there's a single, definitive barrier between submitted params and persistence, irrespective of where that data originated. -- @Eleo

@Eleo exactly. That's what I tried to say [to] dhh in my gist. Controller has nothing to do with unintended params. It doesnt filter. It handles, manages, controls business logic.
IMO You should write your controllers way described below:
1) have all critical fields protected/updateable - accessible
2) control saving new record in controller using role checks, dependencies and abilities. Not just by filtering :user_id
3) Never simplify business logic for "update". People got role checks in "create" but trying to manage just "update_attributes" in edit and that's why this has happened. If you check role - check it on create and on update.

Don't be lazy. sic! -- @homakov

See: Mass assignment vulnerability - how to force dev. define attr_accesible?