I've typically done something like this, which DHH has put even more succinctly:
https://gist.github.com/1975644 class PostsController < ActionController::Base def create Post.create(post_params) end def update Post.find(params[:id]).update_attributes!(post_params) end private def post_params params[:post].slice(:title, :content) end end Regards, John Lynch [email protected] On Tue, Mar 6, 2012 at 11:07 AM, GW <[email protected]> wrote: > Mmm, yes & no. I have a standardized model editing layer that handles many > typical CRUD behaviors expressed in typical web UIs. That layer builds all > its own SQL or AR calls and handles a lot of common user interaction -- > lind of like an automated back end for most sites. So, the params filtering > is buried in that with a number of other integral features which in turn > integrates into AR. > > Essentially, though it's just a simple comparison of the actual input > parameters and a list of allowed inputs. > > Define allowed inputs as a simple array of params names, pass along the > controller params: > > def distill_params(allowed_inputs, input_params) > return if input_params.nil? > input_params.delete_if do |input_name, input_value| > !(allowed_inputs.include?(input_name.to_sym)) > end > end > > I extend that with follow-up call to merge "implied" inputs (those which > don't appear in the form, but which are included in the final CRUD query). > > So, I have 3 lists: params hash from the submtted form, array of allowed > param names, and a hash which defines additional n-v params to pass to AR > which are not in the form. > > So, the technique itself is very simple, it's just that I do that with > every form -- not as an assumed universal set of rules at the model or even > the controller level. It's at the form level. That concept is more > important than the technique IMO. > > The amount of coding is limited to defining the allowed and implicit > lists. Everything else is automated so I don't have to write the workflow > and AR calls for each form. > > I've been doing this for over 10 years now across a couple of languages, > and implemented this in Rails a long time ago. > > If MassAssignmentSecurity can be used to do that, then eventually I'll > have a look at that so my system morphs into a more idiomatic one for > future apps, but for now, existing projects may as well stay as they are. > > -- gw > > > > On Mar 6, 2012, at 8:56 AM, Ylan Segal wrote: > > > GW, > > > > That sounds like the right way to go. Is your code something that you > can share? I'd be interested in a solution like you describe. > > > > For my current app, I am using attr_protected, but as you mentioned, in > the admin context and the public context, the list of attributes is > different, so it would definitely be more appropriate to handle at the > controller level. > > > > -- > > Ylan > > > > On Mar 5, 2012, at 9:38 PM, GW wrote: > > > >> I've always thought Rails had poor tools for this. Even attr_protected > etc are poor solutions IMO (right idea, wrong place). > >> > >> Borrowing from a framework I developed 2001-2006, I've added a layer to > my controller-model conversation which requires an allowed_parameters for > every form. On the GET side, it prevents search forms from including fields > not intended for the context, and for POST it prevents any field from being > updated out of context. > >> > >> IMO, that's correct place to do it: each form, in context, at the > controller/model interface with the controller dictating what's allowed for > the specifoc context--a list of submitted params, and a list of allowed > params. The latter filters the former before the model does much else. Then > these kind of exploits simply aren't possible. > >> > >> -- gw > >> > >> > >> > >> On Mar 5, 2012, at 5:40 PM, Chris McCann wrote: > >> > >>> A developer used the Rails mass assignment vulnerability to basically > >>> give himself push access to any Github repo. He claims he made Github > >>> aware of the problem before taking action to highlight it. > >>> > >>> Here's an article about it: > >>> > >>> > http://www.h-online.com/open/news/item/GitHub-security-incident-highlights-Ruby-on-Rails-problem-1463207.html > >>> > >>> The take-away: make sure you're not leaving your Rails apps open to > >>> exploit this way. Be sure to use attribute white-lists or black-lists > >>> to protect assignment that could give users elevated privileges or > >>> access to other users' stuff. > >>> > >>> See the Rails Security Guide > http://guides.rubyonrails.org/security.html#mass-assignment. > >> > >> -- > >> SD Ruby mailing list > >> [email protected] > >> http://groups.google.com/group/sdruby > > > > -- > > SD Ruby mailing list > > [email protected] > > http://groups.google.com/group/sdruby > > > > -- > SD Ruby mailing list > [email protected] > http://groups.google.com/group/sdruby > -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
