I've chimed in previously regarding my preference to see the equivalent of attr_accessible [] be the default for AR::Base...in other words, you have to explicitly define those attributes that you want to expose to mass assignment.
As such, by placing this logic in the model, I think you're polluting the model in such a way that the model now only has relevance to the business rules of your specific application. The model is no longer a generic object abstraction of a database table but now also encapsulates business rules. I firmly believe this logic should be applied at the controller level. In fact, what I think we're really looking at here is the other side of the MVPC layer (where P = presenter). Basically, we're looking for the inverse of a presenter, something that sits between the controller layer and the model lay to properly apply the business rules for this application. Really, I do not want my models to know anything about session or authorization (unless I'm implementing an ACL, in which case authorization is stored in the database). -John On Tue, May 26, 2009 at 8:57 PM, cainlevy <cainl...@gmail.com> 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. > > On May 26, 1:47 pm, Xavier Noria <f...@hashref.com> wrote: > > On Tue, May 26, 2009 at 10:30 PM, Matt Jones <al2o...@gmail.com> wrote: > > > One other thought - going back to the original example (admin user can > > > mass-assign fields that are normally protected), what about an extra > > > parameter to update_attributes (and possibly create)? ie: > > > > > @model.update_attributes(params[:whatever], > > > [:stuff_non_admins_cant_change]) > > > > > So essentially a, "no, really, you can mass-assign these attributes > > > just this once" parameter. That would still allow regular code to work > > > correctly while permitting the context-sensitive stuff you're looking > > > for. > > > > Certainly the Hash#except idiom requires you whitelist (or > > not-blacklist) sensitive data, because attr_(accessible|protected) are > > of course applied to whatever sanitized hash you pass. So in > > particular you can only narrow accessible aattributes (or extend > > protected attributes) > > > > Going the other way around sounds better to me, not sure about the API > > though. I think it requires the same amount of configuration and > > exceptions, but looks like a safer default. > > > -- John Trupiano President SmartLogic Solutions http://www.smartlogicsolutions.com @jtrupiano --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
