The problem with Hash#slice/except is that it does not make security
the default. If one forgets to do this in one request then it leaves a
security hole which is difficult to see because the app behaves
normally.

With attr_accessible security is the default and one must explicitly
bypass it - I believe that is the way it should be. The problem is
there is no easy way to do that. This discourages the use of
attr_accessible - not a good thing at all.

Rails 3 is already moving into this idea of default security with HTML
injection. One must explicitly specify if they don't want the HTML to
be escaped. I think we can take the same concept and apply it here.

What if params[] was a special subclass of Hash and had some security
built into it. By default it would assume all content is dangerous but
one can specify that directly.

User.new(params[:user].trusted)

Or like this:

params[:user].trusted! if admin?
User.new(params[:user])

The method could take a list of arguments defining which attributes
are trusted to handle more complex scenarios:

params[:user].trusted!(:username, :email) if moderator?

The mass assignment can look for this type of hash and bypass
attribute protection on trusted values. I could see this concept of
params security being applied to other methods too (such as AR finds).

Also, I want to point out a bigger issue here is that attr_accessible
is WAY underused leaving so many apps vulnerable when they don't even
know it. Anything we can do to make it more friendly is a good thing.
See the section titled "The Reality" on this excellent writup:
http://railspikes.com/2008/9/22/is-your-rails-application-safe-from-mass-assignment

Regards,

Ryan

On May 27, 2:26 am, Hongli Lai <[email protected]> wrote:
> On May 27, 2:57 am, cainlevy <[email protected]> wrote:
>
> > After playing with a reimagined version of attr_accessible/
> > attr_protected in my plugin, I'm much happier with the model-side
> > filtering approach. I think it allows for more interesting and useful
> > defaults.
>
> > Since this API is to live only as a plugin for a bit, I'm unsure
> > whether this thread is the place to continue discussion? I think that
> > Xavier's improved documentation is probably all that can/should be
> > done to core at this time. Anyone interested in playing with the mass
> > assignment API is welcome to contact me directly or through GitHub.
>
> Just publish the code. Real-world experience will teach us whether it
> has any advantages over Hash#slice/Hash#except.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to