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?

  • What would be the alternative?
    – user7043
    Jan 15, 2013 at 15:35
  • 1
    You use what gives you the best security even if it's considered an anti-pattern by some.
    – zxcdw
    Jan 15, 2013 at 16:04

7 Answers 7


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):

{{#if isCurrentUserAdmin}}

So that means that it's not a violation, as long as the appropriate pieces are in the correct place.


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.


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)

  • Wikipedia's assertion that "A controller can send commands to its associated view to change the view's presentation of the model" seems more fitting to Model-View-Presenter, as the interactive model the phrase seems to describe is possible there, whereas in MVC, once the View is rendered, no further action takes place between the View and the Controller. Jan 15, 2013 at 16:04
  • 1
    @RobertHarvey I would agree that statement doesn't fit in my definition of MVC, but lucky us we work in an industry where correctness is decided by a plurality of agreement rather than any provability because these definitions just float up as if from the ether with a constantly evolving foundation allowing everyone to make their own takeaways. Or in more plain words, I'm probably just as wrong as everyone else here. Jan 15, 2013 at 16:14
  • 3
    Which is why I think people are far too pedantic about this sort of thing anyway. Jan 15, 2013 at 16:16
  • 1
    @rvcoutinho I wouldn't say that at all, I was being literal; you've got references on your side, all I've got is my opinion, so in my mind that means I'm likely wrong which is why I mentioned it. I feel my opinion is plausible enough to be worth sharing even though I have no references so I did it anyway, regardless of the fact that as I said, I'm likely wrong. Jan 15, 2013 at 16:28
  • 1
    @rvcoutinho: Actually, I was referring to the OP's question. :) There's nothing wrong with rules, unless the rules get in the way of getting something done. Jan 15, 2013 at 16:28

I would say no.

Usually, this kind of security checks are going to be done by the controller.

As from Wikipedia:

A controller can send commands to its associated view to change the view's presentation of the model

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:

A view requests from the model the information that it needs to generate an output representation.

  • 1
    In many software systems, the display of an element depends on the security level of a user. While you can inhibit the display of a data item by setting it to zero or null in the View Model, the name or description of the data item would still be displayed. The only place where you can inhibit the display of the data item description (in a practical way) is in the View. Jan 15, 2013 at 16:00
  • I tend to disagree. I would say the view would request the data, the controller would manipulate the model, and the view would, again, represent it. The view should be responsible for the representation of the output only.
    – rvcoutinho
    Jan 15, 2013 at 16:09
  • Which is why the View needs to hide those visual elements that the user doesn't need to see. The Controller is not responsible for creating the visual representation of the data; the View is. Of course, if what you are displaying is so sensitive that it cannot even be in the View/Source, then what the controller needs to do is return a different view. Jan 15, 2013 at 16:12
  • 1
    That is my point. The view should be different. As far as I understand, looks like the view should only take care of the representation of the data. By representation, I would mean how to show something, not when to show it. Yet your comments are totally relevant.
    – rvcoutinho
    Jan 15, 2013 at 16:21
  • Well, I think we might just be using the same expression for two different things. What is a different view anyway? But I think we agree on the most important matter: if it is security sensitive, it should not be handled by the view.
    – rvcoutinho
    Jan 15, 2013 at 16:40

There are several issues involved in this question.

  1. Authentication (is this user who he says he is) should not be a concern of the View.
  2. Authorization (Is the current user allowed to do this) is a concern of the View, because it can affect what gets presented to the user. Thus, the code for displaying an edit-button can be surrounded with a conditional like if model.userCanEdit() ... endif.
  3. The determination of which authorization attributes a user has, that is business logic and should be placed in the Model. (For example that the 'edit' privilege requires you to have 2000 reputation; or that you must be the author or a moderator)

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.


If a view explicitly checks security to conditionally display UI elements, is it violating MVC by containing business logic?

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.

  • Then how would the view know whether or not to display something like an edit button?
    – Matt S
    Jan 15, 2013 at 19:38
  • @MattS The presenter calls a function in the view to show or hide that button (depending on a state in the model). Jan 16, 2013 at 7:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.