Security and access control in MVC application

I just started working with the MVC approach, so I guess this is the guru for you:

Where can I set access control?

  • In view? I don't want to have any logic other than the switches and flags in my templates, so this sounds like the least viable option
  • In the model? Should each business object decide what data it will disclose about itself, based on the one who asks?
  • In the controller? What I have now, but it makes it difficult to agree on business rules.

Or is there another option?

+4
source share
2 answers

This will depend on what infrastructure you use as such, and the language will determine the many tools available to you.

From a high level, you must have access security configured at entry points. And you must double-check access security at all levels that can be considered stand-alone or reused from several parts of your application (who knows if the security check was your partner using your logical level, etc.). Another thing to worry about is data protection, and it is as close to your data as possible (so, yes, to your No. 2 above, but understand that this is separate).

This is similar to the difference between the application logic and the domain logic that I like to talk about. If there is any logic specific to one particular application (a web application compared to a Windows service or something else), then this logic should be defined only in that application. If some logic crosses the border between applications (can be reused between applications), then it qualifies as domain logic and must be defined in your model. Your applications can use domain logic, but they should not own it.

+4
source

To ensure the security of the model (aka data), the model will "control" access, and the controller will "facilitate" access. This ensures reuse of the Model independently of the controller and minimizes, if it does not deny the general replication of the code, necessary for different controllers that use the model.

For example, a car, driver and key. (Model, controller, API, respectively). Due to the very small interface (key == API), the model allows or denies access to the controller for each API (key fob). Different types of access are allowed (Valet key, owner key, FOB owner). Using the Valet key interface, the controller will not have access to some data / functions of the Model, such as the glove compartment, trunk and gas bottle. This is essentially role-based access, implemented by the model by identifying and classifying a controller with a very small API / command surface area.

This means that the Model can be used by other controllers (a car with different drivers) that need only basic authentication to access the model data (functions and compartments of the car).

0
source

All Articles