8

I want to know if all the logic related to permissions and access control belongs to controllers (Application logic) or models (Business logic).

Currently I have a controller that does something like that:

function delete (resource) {
   if (resource.belongsTo (currentUser) {
       resource.delete ();
   }
   else {
       throw Exception ("you can't do this");
   }
}

Is this kind of logic application logic or business logic?

PS. I already read Where to put business logic in MVC design?, but I still have doubts

Community
  • 1
IAmJulianAcosta
  • 537
  • 1
  • 5
  • 11

3 Answers3

9

It is perfectly acceptable to put security/permissions logic in the controller method.

The purpose of the controller method is to coordinate service calls to the service layer or business logic layer or repository. Technically, security is an orthogonal, but very important concern to the business logic methods. It is orthogonal because it essentially boils down to a "gate" that you must pass through: either the resulting business logic method gets executed, or it does not. But the essential logic itself does not change: assuming you have permissions, the outcome will always be the same.

The permissions function may be provided by another library or service, but that further underscores the role of the controller method as a coordinator, since now the controller method won't even be providing security functionality (it defers that functionality to some other mechanism).

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
6

It is helpful to distinguish two types of access control:

  • Vertical - functions that some users can access and some users cannot. For example, anyone can view the home page, but only admin can ban a user.
  • Horizonal - functions that multiple users can access, but the data is segregated. For example, everyone can access "inbox" - but they see only their own messages, not other people's.

Vertical access control is almost always enforced at the controller layer.

Most applications also enforce horizontal access control at the controller layer. This works, but there is a disadvantage: access checks need to be repeated in multiple places, which invites mistakes. Complex applications need a lot of checks to properly enforce horizontal access control.

But there is an alternative: perform horizontal access control in the model. This tends to reduce the number of checks needed - e.g. you have an access control check on the Email object, rather that 15 separate checks in controller methods that access the object. One criticism of this approach is that is requires the model to be identity-aware, which could be unwanted coupling between model and controller. However, I think it's worth it. I've written more about this topic on my website.

paj28
  • 1,663
  • 1
  • 13
  • 13
  • 1
    Good explanation. Another reason why vertical access is best left to the controllers is that some internal operations may not want to be subjected to such identity checks, like side effect operations or cron jobs that run unattended and have system level access but are different from the target identity being operated on. – SimoAmi Feb 10 '20 at 01:24
1

absolutely awesome practice. also try having some sort of base controller that have all other of your controller extended to it to avoid repetitive access control check. let's say i want to limit people from visiting the profile controller, i can have a parent controller called user and right in the constructor i would do a check to see if user has access else i will redirect. if you decide developing with java, you should probably try the spring security (http://docs.spring.io/spring-security/site/docs/3.0.x/reference/springsecurity.html) which is awesome and eliminates much need for the struggle for access controls from the controllers.

Kevin Constantine
  • 29
  • 3