GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
I have a question about mass assignment outside of controllers.
If I call #update_attributes on an model using ForbiddenAttributesProtection and pass it a vanilla ruby hash, my understanding is the permitted check is bypassed.
What is the recommended practice for such mass assignments if the hash hasn't been wrapped by ActionController::Parameters because it's not in a controller context?
The only issue is related to receiving external input and mass assigning to a model instance, which is likely to exist only in controller scenarios. Do you have any other use case where user input is expected? If that's a case, you should be able to manually instantiate the Parameters object and use permit and brothers as in the controllers.
@carlosantoniodasilva Thanks for your reply.
As a specific example, I've written code before in the context of callbacks, where our server would receive an id via a POST, create a background job, which then would call out to a remote endpoint url to fetch more complete json data that was used to create a new model. Usually we try to be clean and remember to sanitize the JSON we get back, but it could be easy to forget or be lazy and send the unchecked or partially checked hash on for mass assignment.
Another possible scenario is if you have a mounted rack app alongside your rails app, that is sharing the db connection and models. In such a situation it would definitely be prudent to wrap the params in the rack app as ActionController::Parameters as you have suggested.
I'm asking this because the previous (well, current) attr_accessible scheme protects against forgetting/sloppiness in such instances.
I very much like having the strong_parameters contextually filtering in this new way, I just have this one hangup I'm trying to hone so I don't make mistakes.
Thanks for the examples. I think that for such scenarios, the best choice would be to either go with creating the parameters hash and permitting as necessary, or at least slicing the received args to only the ones you really want to pass along to the model, to avoid unwanted attributes. That's how I can think of contextual/case-by-case filtering, and indeed we'll have to get used to it :).
Add doc section about use outside of controllers.
See gh-98 for a discussion on this.