1

We have an MVC application that has very granular and configurable authorization. We currently have been using the authorize attribute against our controllers and controller functions.

The next project that we will be working on will require us to support a 3 state control. The 3 states are NoAccess, ReadAccess and FullAccess. NoAccess will require no control to be rendered, ReadAccess requires to render a label and FullAccess will render a control (textbox, dropdown, etc.)

Our first working approach was to add a dictionary to the model that contains a key identitfying the property and the value of what access the user has to said property.

["FirstName", enumAccess.FullAccess]

This item would then be passed into an html extension.

@html.TextboxFor(m => m.FirstName, Model.AccessDictionary["FirstName"])

The extension would then render according to the access level. NoAccess would render a hidden, ReadAccess would render a label and a hidden, FullAccess would render a Textbox.

The second approach would be to decorate the model property with an attribute that would have the specify the key and in the textboxfor extension we would check the attributes and verify the access against the httpContext of the logged in user. This second approach would not work for our create or save buttons as these are not tied into the model.

I have searched online for some examples of complex configuration of views and models but have not come across anything as of yet. As mentioned above the first approach is currently working but it does not feel very elegant as each developer requires to populate a dictionary on every model and the view has lots of hiddens on that could lead to malicious updates. Any advice or direction would be much appreciated.

  • 2
    the view has lots of hiddens on that could lead to malicious updates -- Your Model on the server side should already have validations that prevent this from happening. Always assume that the data you receive from a client could be malicious. – Robert Harvey Sep 14 '18 at 18:35
  • it does not feel very elegant as each developer requires to populate a dictionary on every model -- If you want this level of control in the View, you have to provide the necessary information to the view somehow. – Robert Harvey Sep 14 '18 at 18:36
  • Related: stackoverflow.com/q/16814119 – Robert Harvey Sep 14 '18 at 18:44
  • is the requirement that the user can configure the access levels of fields themselves? ie the access level is not known at compile time – Ewan Sep 15 '18 at 9:25
  • @Erwan Yes excatly! – Leonardo Sep 17 '18 at 7:17
1

The first rule of field level permissions is DON’T. If it is for just a few fields on a few small views, then duplicate the views for the different user roles you have.

If your requirement goes beyond this, field level templates (Editor and View templates) will be a good solution as you could group multiple fields in the same template and have your access control data in a separate field on your view model or a callback to the server.

However, ultimately field level permissions becomes a nightmare in a large application with many complex views. Make sure your product owner understands the cost and complexities involved with field level permissions and that the value it brings justifies the cost.

  • Our core application is 30years old and we are required to move an area from a VB6 application into the web app. I wish they didn't need an infinite amount of combinations. We know that this is a nightmare, our tests can only cover so much. Thankfully our customer base really like this bespoke feel and they actually do utilize it. Cheers for the confirmation as what you said is what I told the product owner, thankfully new areas dont require this level configuration. – Leonardo Sep 14 '18 at 19:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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