In the case of nested_attributes, it’s very good to explicitly allow them so that you can allow setting the preferences of a user through user but disallow the reverse.

class User
attr_accessible :preferences_attributes
end

class Preference
# nested disallowed from here
end

That said, the question turns back to whether or not we think that this mass assignment vulnerability is worth addressing. Out of curiosity, what did you think of my suggestion on the rails-core list? Specifically turning off mass assignment by default, and requiring developers to open it up with attr_accessible declarations (I also suggested that the generators could be updated to include this attr_accessible declaration, bringing more visibility to the vulernability). Do you think there’s value in this, and if not, why?

In zena, access to users is controlled with a before filter in the controller since it’s a very simple grant/refuse authorization scheme.

On the contrary, Node access (pages,notes,contacts,etc) is done with groups (like in UNIX). This means that when we follow links between nodes (children, other relations), we need to move with the visitor along and the authorization is then moved into the model.

I did not decide to go off the tracks and have an explicit visitor available in models just for fun. It makes testing harder and everyone says it’s wrong. Apart from all these negative aspects, it’s a very elegant solution when you have complexe workflows (publication/proposition/redaction) in a multiversion, group based authorisation scheme.

Another advantage is that you can write very clean authorization rules (http://tinyurl.com/bfvpks) that produce nice error messages in the forms (ajax) where the user tries to post forbidden data.

You could move such rules in the controller, but then it would need to know so much of the node’s internals that it makes things worse.

As a rule of thumb, I would say that we need to move authorization to the part that knows the most about the necessary context. Sometimes it might be the controller because the session is the important part. Sometimes it should be the model because that’s where the complexity lies.

I’ve long held the belief that models should be entirely session-independent. In other words, they should not know who is logged in, or really that they (the models) are being consumed by a rails application. I wrote my code such that controllers would orchestrate the permissions/authorization, and that the models were malleable pieces, unaware of roles/permissions/etc.

That said, the more I think about this, the more I’m convinced that there isn’t a golden rule for all of these cases. Still, in the majority of my apps, authorization is best (and more appropriately I’d argue) handled at the controller level. However, in extreme cases where ACL’s and the likes need to be implemented, there’s no way around pushing authorization down to the model level.

As I noted earlier, perhaps we can take a few ideas from how roles/authorization are handled in my Michael Berkowitz’s fork of the AASM gem: http://github.com/mikowitz/aasm

Though his implementation only deals with state transitions, it’s easy to consider this idea being applied to the concept of editing a single field.

@Gaspard, I’m also curious as to your approach for passing the “current logged in user or access level” to the model….this always felt very dirty to me (hence why I always advocated applying authorization at the controller level).

Also @Mina, I started a discussion on the core group about perhaps tweaking rails to protect against mass assignment by default. Feel free to chime in there as well: http://groups.google.com/group/rubyonrails-core/browse_thread/thread/4e312a3de4c3579f

@Gaspard
I agree regarding doing the authorization in the model, though not entirely with the approach you suggest.

I’d feel more comfortable if the setter method is never called in the first place, as opposed to having it called and then try to do authorization later when .valid? is invoked – this is in case the setter has any side effects (hand-rolled setters, or nested mass assignment helpers for instance).

If we agree on the above, and if my understanding is correct, all mass-assignment methods (new/update_attributes) end up delegating to #attributes= at one point. Therefore, this is the place to inject the authorization logic to not invoke setters the visitor doesn’t have access to invoke.

Regarding your exact suggested approach though, which already does a decent job attacking the problem: do you hand-roll the notion of “visitor” in your example in every rails app ? or are you aware of plugins to do this ? Also, how do you communicate the visitor from the controller to the model ?

This simple assertion means that models know who is doing what to them when they are saved.

For example, you would have a validation that verifies that only admins can change the “credit”:

validate :only_admins_can_change_credit

def only_admins_can_change_credit
errors.add(’credit’, ‘cannot be changed’) if credit_changed? && !visitor.is_admin?
end

Mina, it’s possible you may have more to contribute, so check it out if you have an opportunity.

It’s clear at this point that we do have suitable workarounds. My two primary concerns at this point are: (1) can we make this safer out of the box? (2) regardless of (1), let’s make sure we’re making this information available.

I think Mina captured the shortcomings very well in his responses farther up. A/R’s attr_accessible and attr_protected are fantastic for the simple cases, but don’t scale very well when you want finer access control.

A colleague of mine has been working on an AASM fork (http://github.com/mikowitz/aasm) that includes (among other things) the ability to restrict a transition to a specific set of “roles.” While still early in development, I wonder if some of the ideas from that project might apply here….seems to share several similarities to this discussion, particularly as it relates to fine-grained access control.

@Ryan I’m hoping to submit a doc patch this weekend for that guide.

+1 for a good write-up in the rails guides