Jay, this solution doesn't play nice with inheritance. Rafael Mendonça França http://twitter.com/rafaelfranca https://github.com/rafaelfranca
On Tue, Jul 10, 2012 at 10:59 AM, Jay Feldblum <[email protected]> wrote: > In this type of case, it makes sense either to declare a whitelist or to > declare a blacklist. But it doesn't make much sense to declare both of them. > > Solution #3: ActiveRecord (or ActiveModel) should raise if a class > declares both a whitelist and a blacklist of mass-assignable attributes. > > class Comment > attr_accessible: title > attr_protected: author_id # raises immediately > end > > Cheers, > Jay > > On Monday, July 9, 2012 6:19:12 PM UTC-4, Uberbrady wrote: >> >> (I posted this as a bug in GitHub (https://github.com/rails/** >> rails/issues/7018 <https://github.com/rails/rails/issues/7018>), but >> then someone there told me I should post it here, so here it is.) >> >> If you set attr_accessible on some properties in an >> ActiveRecord-descended class, and then attr_protected on others - the class >> becomes 'default-open' - if any properties are missed or added later, they >> will be accessible by default to MassAssignment. >> >> This undoes the entire point of having put attr_accessible in one's class. >> >> Two possible solutions - >> >> #1) 'default-closed' - the attr_protected statements will either be >> ignored, or just used to override attr_accessiblefor a particular >> property. >> #2) 'explicit-only' - any attribute accessed in mass-assignment that is >> not explicitly mentioned in eitherattr_accessible or attr_**protected raises >> a new error - something like MassAssignmentError:** >> AttributeNotExplicitlyDeclared**. Maybe even throw an error if the >> attribute is accessed in*any* way (mything.whatever="boo"; # kerplow! >> throws error?) though that might perform poorly. >> >> Solution #1 is probably fine - accesses to not attr_accessible properties >> will throw a MassAssignment error under these circumstances anyways. >> Solution #2 just makes things really explicit, which some might want for >> some kinds of high-security applications. >> >> I found this bug in my own code during the development cycle; I liked >> putting both attr_accessible andattr_**protected in for symmetry and to >> remind me of my DB schema at the top. Stupid reason, I know. I found that a >> belongs_to relation was unprotected in that circumstance. >> >> -B. >> > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/rubyonrails-core/-/aqdzTPrnZTgJ. > > 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. > -- 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.
