views:

36

answers:

4

I'm just starting to sketch up the base of a web-based system, and I would like the admin to have the possibility to limit access either by Controller or by Model. My problem is, I can't decide which one (or both?) of them I should go with. Any ideas? Pros/Cons?

First I was leaning towards doing it in the Controllers, seeing as they "control" the flow of the system. But then, thinking that the access should probably be limited by the data it accesses, not the logical part of the system, I felt like I really should go with the Model.

Now I just can't decide.. I've been bouncing back and forth for a couple of days now without actually moving forward at all, so now I turn to You, oh Great Internet, in hope for answers!

My implementation is in C# / ASP.NET / MVC2, but I'm still working "theoretically" so it's not really framework specific..

A: 

Typically, I would expect your users to have roles that have access to a a range of functions they can perform on a range of models. This access/no access lookup would be made in the controller.

marr75
A: 

In the current project I'm working on, we limit access at the controller level via action filters.

The action filters can be defined for a specific action if we want to limit access just to that specifically (ex. a certain page the user shouldn't see) or defined on the controller if that entire area is limited.

The action filter itself is pretty simple, and uses the HttpContext to find the user's identity, but in our case we're using form's authentication so this may differ based on what type of authentication mechanism you're using.

Lester
+2  A: 

Although there could be exceptions to this, access control should be done by the controller.

The models should not be holding any procedural functionality, just business logic. Business logic on itself should not need to be access-controlled.

The controller, which contains actions that 'interact' with this business logic and models, should be the place to have access control in. Some frameworks already provide functionality for access control, that can evaluate the state of an application to decide whether a certain action can be performed.

Example: On a web application, Model "Person" holds "persons", and has a function 'createNew (name)' Controller 'PersonsController' has action 'addNewPerson()', which reads the name from HTTP Post and calls the function mentioned above. It also has an access rule that says that action 'addNewPerson' may not be called if the current state of the application indicates that the user requesting the action is not logged in.

Pelle ten Cate
A: 

User authorization is a strictly session-based concern, so that is best dealt with in the Controller. Making Models session-aware is possible, but is a violation of concerns and definitely not easy in my experience. You also have to worry about the requests being thread-safe depending on your technology stack.

The way Rails apps typically deal with this is by adding authorization functions to the Controller base class, and letting you define a before_filter to either the entire controller or the specific actions which need to authorize the request.

Adam Lassek