I think of mass_assignment more in a context-driven way. I have in one of my apps a user model which has a lot of attributes. What is allowed to be edited/assigned is dependent on the context I'm approaching the model, is it from the frontend, is it from the backoffice by a support user, is it from the backoffice from an admin user, is it from the API, ...
For this I think it's best to work with pre-defined contexts in your user model. For example: attr_accessible :name, :first_name, :context => :default attr_accessible :can_login, :context => :support attr_accessible :can_login, :is_admin, :context => :admin And in your controller you can say user.update_attributes(params[:user ], :context => :support) I've implemented this as a rails plugin for you guys to give it a spin, see what you think. The code isn't what I want it to be but it's quite hard overriding create / new / attributes= / ... for these kind of things. The plugin is at http://github.com/DefV/context_assignment/tree/ master . Let me know what you think. regards, Jan De Poorter On 28 May 2009, at 20:32, Kevin Whinnery wrote: > > I agree with Ryan that model security should be pessimistic by > default. Doing a bit of extra work to use the elegant mass assignment > syntax in exchange for security is a good compromise. > > On May 28, 12:53 pm, Ryan Bates <[email protected]> wrote: >> The problem with Hash#slice/except is that it does not make security >> the default. If one forgets to do this in one request then it >> leaves a >> security hole which is difficult to see because the app behaves >> normally. >> >> With attr_accessible security is the default and one must explicitly >> bypass it - I believe that is the way it should be. The problem is >> there is no easy way to do that. This discourages the use of >> attr_accessible - not a good thing at all. >> >> Rails 3 is already moving into this idea of default security with >> HTML >> injection. One must explicitly specify if they don't want the HTML to >> be escaped. I think we can take the same concept and apply it here. >> >> What if params[] was a special subclass of Hash and had some security >> built into it. By default it would assume all content is dangerous >> but >> one can specify that directly. >> >> User.new(params[:user].trusted) >> >> Or like this: >> >> params[:user].trusted! if admin? >> User.new(params[:user]) >> >> The method could take a list of arguments defining which attributes >> are trusted to handle more complex scenarios: >> >> params[:user].trusted!(:username, :email) if moderator? >> >> The mass assignment can look for this type of hash and bypass >> attribute protection on trusted values. I could see this concept of >> params security being applied to other methods too (such as AR >> finds). >> >> Also, I want to point out a bigger issue here is that attr_accessible >> is WAY underused leaving so many apps vulnerable when they don't even >> know it. Anything we can do to make it more friendly is a good thing. >> See the section titled "The Reality" on this excellent >> writup:http://railspikes.com/2008/9/22/is-your-rails-application-safe-from-m >> ... >> >> Regards, >> >> Ryan >> >> On May 27, 2:26 am, Hongli Lai <[email protected]> wrote: >> >>> On May 27, 2:57 am, cainlevy <[email protected]> wrote: >> >>>> After playing with a reimagined version of attr_accessible/ >>>> attr_protected in my plugin, I'm much happier with the model-side >>>> filtering approach. I think it allows for more interesting and >>>> useful >>>> defaults. >> >>>> Since this API is to live only as a plugin for a bit, I'm unsure >>>> whether this thread is the place to continue discussion? I think >>>> that >>>> Xavier's improved documentation is probably all that can/should be >>>> done to core at this time. Anyone interested in playing with the >>>> mass >>>> assignment API is welcome to contact me directly or through GitHub. >> >>> Just publish the code. Real-world experience will teach us whether >>> it >>> has any advantages over Hash#slice/Hash#except. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
