rails / protected_attributes

Protect attributes from mass-assignment in ActiveRecord models.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

This gem seems to completely disable strong_parameters in rails 4 apps?

aaronjensen opened this issue · comments

We transitioned our rails 3 app which used strong_parameters and had some models relying on attr_accessible and some on strong_parameters to rails 4. We included this gem and discovered that it opened all models that were previously protected by strong_parameters to the world. This isn't stated in the readme or anywhere obvious I don't think and seems like a HUGE security issue for apps that are transitioning. Am I missing something here?

Agreed. It should be crystal clear that the gem is a big huge switch. Better, it should allow for gradual transition.

I've been discussing this issue with @matthewd and @fxn.

That this is a huge switch should have been part of our documentation. Our docs mentioned:

Rails 4.0 has removed attr_accessible and attr_protected feature in favor of Strong Parameters. You can use the Protected Attributes gem for a smooth upgrade path.

I assume there are more people using this gem to do a partial migration towards strong parameters. This leaves them in a potentially vulnerable state.

As this gem is supposed to be a drop-in replacement to get the old behavior I suggest the following:

We add a configuration option, which determines whether you want to use only protected_attributes or a combination of both. Setting it to :only_protected_attributes will be the current behavior of this gem (drop-in replacement for the old behavior). Setting it to :mixed will activate protected_attributes only on the models where you've used one of it's macros (attr_accessible, attr_protected). The rest of the models will be protected by strong_parameters. The :mixed option will need some tinkering if you were using models without protection (maybe an Admin area) but at the same time allows for a partial upgrade path.

As some people might be in the situation right now without realizing it, we should probably refuse to start when the configuration option is not set. This way we can inform the user about the situation.

/cc @rafaelfranca

What about releasing a major upgrade of the gem that only works in mixed mode without any other configuration?

If you have an admin area with no protection on purpose just add a before filter that permits whatever comes in.

@fxn I like this idea. Having that before_filter on ApplicationController would be equal to the old behavior.

this sounds great, thanks all.

possible implementation is here #43