mass-assign & ubiquo scaffolds

[Bernat Foj Capell]

As you know Rails apps >= 3.2.3 come with whitelist_attributes = true by default.

http://www.h-online.com/security/news/item/Rails-3-2-3-makes-mass-assignment-change-1498547.html

This means you must have an attr_accessible or attr_protected in all models. But then there is the scaffolds problem. So they whitelisted all attributes by default

https://github.com/rails/rails/commit/641a4f62405cc2765424320932902ed8076b5d38

So the theory is that you should be using whitelist_attributes=true, which will slow you down when you are developing, on the console, etc. But then attributes are white by default. Great.

I don't think that's security by default. That's just annoying by default. Anyway, in Ubiquo scaffolds something must be done and we have some options:

* Do the same than in Rails scaffolds: whitelist everything. Defeats the purpose of this feature and gets in your way.

* Do not whitelist anything. Expect the developer to create this list. Highly annoying, and the developer will simply put in the list everything he needs at that moment. 

* Set the whitelist_attributes to false in ubiquo projects. Not nice to force this.

* Use :without_protection => true in our generated controllers. 

* Generate controllers like this:

https://gist.github.com/1975644

Filtering params in the controller looks like the right way, because the non-ubiquo controllers won't be affected by our policy. It's still somewhat annoying because you have to add/delete new fields from views and controllers. 

Looks like Rails 4 will finally filter params at controllers,

http://weblog.rubyonrails.org/2012/3/21/strong-parameters/

But even if that's the case, whitelist_attributes is still defaulting to true, so something else must be done.

At this point I see two acceptable solutions:

A) Use :without_protection => true in our controllers

B) Create models with an empty attr_protected call, so that by default everything is white. Looks cleaner than listing everything... and the fact is that the developer has the same amount of work to do.

And then regarding Ubiquo controllers:

1) Do nothing (if it's considered that an Ubiquo environment is not public by default)

2) Filter params in controllers using the strong_parameters gem.

3) Create a "signature" using ubiquo_form_builder. Check this signature in the controllers, so that we only accept the fields that are generated in the view. IMHO this is the most convenient for developers, but it's more work.

If you have an opinion for this I'd love to hear it. 

--
Bernat Foj Capell
bf...@gnuine.com

gnuine
www.gnuine.com
C/ Pamplona, 96
Local 17
22@ - 08018 Barcelona

Tel: +34.93.567.94.94
Fax: +34.93.567.94.95

[Ramon Salvadó]

Hi Bernat,

  Thanks for the very detailed explanation of the issue.

  I would just do the same that rails does with scaffolds right now, I would try to go with the flow on this one and try to do the least amount of work possible at this point. Why?

Extracted from http://weblog.rubyonrails.org/2012/3/21/strong-parameters/ :

"We're exploring a new way to deal with mass-assignment protection in Rails."

"We're still fiddling with the API, but it's good enough to use now..."

"We're still working on a tidy way to deal with nested parameters, but there's a design ready for implementation, so it shouldn't be far off..."

  Probably it would be easier to update to the new method when the rails scaffolds do.

Regards
Ramon

--
Heu rebut aquest missatge perquè esteu subscrit al grup "ubiquo" de Google Grups.
Per publicar a aquest grup, envieu un correu electrònic a ubiquo...@googlegroups.com.
Per anul·lar la subscripció a aquest grup, envieu un correu electrònic a ubiquo-gnuin...@googlegroups.com.
Per obtenir més opcions, visiteu aquest grup a http://groups.google.com/group/ubiquo-gnuine?hl=ca.

[Bernat Foj Capell]

Hi Ramon,

Thanks for the answer,

Yes I concur in doing the least possible amount of work, you're right that their api could change. I think that this will involve using the :without_protection flag for now, because we have more cases to deal than rails scaffolds (media_attachments, relation_selectors, categories..) and that would involve a more complex logic.

Cheers

Bernat