Often what's displayed to a user (e.g. on a web page) will be based partly on security checks. I usually consider user-level / ACL security to be part of the business logic of a system. If a view explicitly checks security to conditionally display UI elements, is it violating MVC by containing business logic?
|
|
There can be two types of security conditionals, one on the model and another on the view. The view controls the display of relevant elements depending on permissions of the current user, but the model controls access to the underlying data. As long as the model has all of the right verifications/validations, then even if the view is lacking, there is still security. Usually you have to have both, since the view needs to change for different levels/roles. The controller sends the relevant data that would change the view, but the view still needs to do something with that data to hide/display content to the right user. That's why most templating frameworks have conditional elements (Handlebars example):
So that means that it's not a violation, as long as the appropriate pieces are in the correct place. |
|||
|
|
|
If it's only about displaying the UI element I think it's ok (how else would you do it anyway?). If there would be any data in those elements the model should have made sure that the containers are empty. And of course the code to get the permission data should have been handled before the view, so there is no active access to the model here. |
|||
|
|
|
I would say no. Usually, this kind of security checks are going to be done by the controller. As from Wikipedia:
And I do not think it should be done directly in the view. If it is done via javascript, for instance, it could be a security issue (one could disable javascript and access privilleged data). Again, from Wikipedia:
|
|||||||||||||||
|
|
I would say no. But for a different reason than @rvcoutinho said (though he cites wikipedia which makes me feel wrong in my thinking) I would say any relevant security concerns should be shared by the Model given to the view (depending on the number of combinations you may wish to use a ViewModel for this reason), in that you could have switches for the security bits. This allows the two layer security validation: at the UI layer so a postback is subverted for the normal case, as well as at the server layer for bad actors where the model maintains the security knowledge inside of itself so the controller hands off the info to the model which immediately tosses it out. Two layer security like this is the standard in industry, and this way allows your security logic only need exist in two places so it's a bonus, as soon as you put security logic in your controller, you're putting it there, and in the UI and in the model (the model needs it as it's the last line of defense and especially important for any uses outside of that MVC web-app like a desktop client or any server management tools) |
|||||||||||||||||||
|
|
Yes and no. If the actual security decision is made by the view, then yes, you are violating MVC. If, however, the view delegates the actual decision to the model, then you're fine. There is nothing wrong with a view making decisions on which elements to show, based on information from the model. For example, if you have an "edit" button that is only visible for users with "editor" permissions, then it is fine for the view to ask the model who the current user is and whether they have the "editor" permission, then using this information to decide whether to show the button or not. If, however, the view were to do the authentication and authorization logic itself, then you'd be violating MVC. |
|||
|
|
|
There are several issues involved in this question.
|
|||
|
|
Yes, it is a violation of MVC. The view is there only to display elements, and the logic should be in the model. By having the view do something (in your case, check the security), you are placing the logic there. |
|||
