[tptacek]

Broken record:

Remember that attr_accessible does NOT mean attributes that the application can change. It does NOT mean attributes that have automatic setters and getters. Even if an attribute isn't listed in attr_accessible, you can still write controller code to work with the attribute!

What attr_accessible means is "attributes that can be changed via mass-assignment, through #update_attributes or #create". These are the attributes that you are allowing users to change without supervision.

Keep attr_accessible minimal. Avoid the temptation to list every attribute your application will allow users to change. You can always write line-by-line setters, like:

    u.role = params[:role] if role_safe?(params[:role])

If you don't keep your attr_accessible statements minimal, you can end up with mass-assignment problems even when you have whitelisting enabled.

[Empact]

Yep, and the new strong_parameters library from core team supports this and is a taste of things to come: moving towards consistently controller-based access-control. http://weblog.rubyonrails.org/2012/3/21/strong-parameters/

[tptacek]

I am not, by the way, sold on this particular ideology about models and controllers. The controller-based pattern has stuff to recommend it, as does the model-based pattern. I think most apps are going to end up wanting to do both.