dealing with mass assignment outside of controllers about strong_parameters HOT 3 OPEN

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.

from strong_parameters.

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

from strong_parameters.

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

from strong_parameters.