This repository has been archived by the owner. It is now read-only.

dealing with mass assignment outside of controllers #98

Open
bemurphy opened this Issue Feb 15, 2013 · 3 comments

Comments

Projects
None yet
2 participants
Contributor

bemurphy commented Feb 15, 2013

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.

Contributor

bemurphy commented Feb 15, 2013

@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!

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 :).

bemurphy added a commit to bemurphy/strong_parameters that referenced this issue Feb 15, 2013

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.