Hacker News Reader

Comment by skimbrel | Hacker News Reader

But when the model is accessed from four different controllers representing different privilege levels (e.g. public profile page, user settings page, internal admin page) and user experiences, is it really still the model's job to figure out which incoming updates are allowed to update which fields?

This is "thin controllers" gone too far -- the model shouldn't have to figure out where it's being updated from and what to allow.

View on HN

Yes it is. But even ignoring that, Rails 3.2 added a feature to do something similar: roles. You can do things like this in the model:

    attr_accessible :user_id, :on => :admin

And in controllers (or anywhere, really):

    @something.update_attributes(params[:something], :as => :admin)

It's naive and it's not exactly an ACL or anything but it's a way to indicate the context at a basic level.

Sadly, people seem to be running around like headless chickens trying to scotch tape trash bags over a broken window instead of learning how to replace the glass.

I'm somewhat of two minds about this one.

1) The model could be used everywhere so it may be best to negate the issue by locking down the attributes at one source.

2) As you pointed out, the model is in different contexts depending on the privilege of the current user session. It's almost as if I want a thin layer between my model and controller that takes into account session info and informs the model about what can and can't be done.

Another option is to have the model take more a DDD approach. Part of the input params could be a user object. That same user object would know its current privileges and that could be done within the large model that is actually trying to do something.

What I don't know is if RoR allows for this sort of modeling. I have no experience with the framework. It might want something that is similar to getters/setters in Java. If this is the case, such a modeling is problem not going to work since the multiple params will break the spec.

As an integral convention of Rails, it does not (to my best knowledge). As something you could add yourself or package up into a plugin, sure. It just wouldn't be the conventional approach (which, as we're discovering, is stupidly insecure and patching things over while targeting the wrong problem).

With regarding your second point, django middleware would be beneficial and does exactly that.

Precisely because there can be so many places (controllers) that can access the model, usually you use declarative access control rules on the model to control access in one place. It can be done with role. Then whoever user having the role can access the model.

I agree with you, I imagine your parent's reply was could have been sarcastic that got lost in text.

It's really an authorisation issue as to who/what can update which parts of a model - generally this is handled in the controller.

Reply on news.ycombinator.com