How to create pages with different permissions' views

Question

I need to create different page views for different types of users. I already asked that here: How to create pages with different permissions' views

And even tho

Answer 1

To do what you are looking to do, you shouldn't control your views - you actually have to secure your controllers - not the views. You can do this via controller attributes. Something similar to this:

[Authorize]
public class MyController {
}

By doing this, you secure the entire controller. Every action within that controller will not respond if the user is not authenticated (specifically, they will receive a 401 response). You can extend this by authorizing individual users or individual roles as shown in the examples below:

[Authorize(Users="eestein,JasCav")
public class MyController {
}

[Authorize(Roles="Administrator")]
public class MyController {
}

In your case, you may not want to have an entire controller with authorization on it. Well, excellently enough, ASP.NET MVC provides action-level control of authentication. So, you can do this:

public class MyController {

    public ActionResult Index() { }

    [Authorize(Roles="Administrator")]
    public ActionResult Admin() { }

}

Using this idea, this is where you can control what a user sees on a page. You are going to want to return partial pages from your actions so that you can load various aspects of the page. For example, you may have a view that shows some normal data and some secret data. The normal data can be returned via the normal page. The secret data should be returned as a partial view within the page. However, if a 401 occurs, you can handle it and just not show anything.

It is fairly straightforward to do. The .NET team did a great job of setting this up and you don't have to individually check permissions within your controller. I hope this helps get you started. Do a search online for more information about how to use the Authorization attribute.

Update In the case where you have an administrator of a page who is controlling those permissions, you have to be smart about how you setup your Authorize attribute. This is where "Roles" are very important (per my examples above). For example, if the administrator says, "I'm going to add John Doe to an SpecialUser role," then John Doe user is going to be able to access all the actions in which the role is set to SpecialUser (if that is indeed a role on your system).

Obviously, you're going to have to give administrators some way of being able to do this, and the Authorize attribute does this perfectly. To see who has permissions on a page, you will have to query the database to find out who is part of what role. Here is a way to think about the setup:

• You control the Roles of the actions.
• Your administrators control who gets granted those roles.
• You can always check (via a simple query) to see who is assigned to what role. You can then (via your knowledge of the actions roles) see who sees what part of the site.

I hope this clarifies (and I hope I understood your problem well enough). I think what you are trying to do is possible.

Update 2 Yes, this does assume you have static groups on your controllers and any new group would have to be programmatically added. I'd be curious to know what kind of use case requires different permissions types to created on the fly - that seems like it would be open to abuse. In any case, I don't have a solution for this.

As for how partial views work...it's something like this...

public class ProductController : Controller
{
    //
    // GET: /Index/
    public ActionResult Index()
    {
        return View();
    }

    public ActionResult Partial1()
    {
       return PartialView();
    }

    [Authorize]
    public ActionResult Partial2()
    {
       return PartialView();
    }
}

Inside your Index.aspx file, you'll have something like this:

<%= Html.RenderAction("Partial1") %>
<%= Html.RenderAction("Partial2") %>

If the user is not authorized you can handle the second RenderAction so the view never even shows. (You can check that within your controller.)

Hope that clarifies things! I'm on the run, so I can't expand on it more now.

Answer 2

I would recommend "additive" security; a User's permissions, and that of any of his Groups, total together to give a series of things he is allowed to do. If he doesn't have explicit permission to do something for which permission is required, he is not allowed to do it. In your case, between User U1 and Group G1, there are sufficient permissions granted for the user to see Field A and Field B, and to edit Field A. As the user, either themselves or through their group, was not explicitly granted permission to edit Field B or to view OR edit Fields C and D, he does not have those permissions.

I would implement this type of permission by putting a method in the codebehind that will accept an object representing the user and their permissions, and will interrogate those permissions to determine visibility of fields. All fields should start out as invisible, and this method will make them visible and/or editable.

Things to be aware of:

• Make sure you are using the .NET server-side tools to show/hide fields. If a field's Visible property is set to false at the server side, the rendered page will not even include that field in the HTML. By contrast, adding a style or using JavaScript to obscure properties keeps them in the DOM, and in the HTML, so a person can "view source" to look at fields hidden this way.
• NEVER use client-side code to implement security. JavaScript, ActiveX controls, etc can be refused, disabled and/or manipulated. Client-side code to show data also requires that data to live somewhere in the source of the page, meaning it can be found very easily by viewing the page source.
• By the same token, do not trust that a non-editable field will not have its data changed. HTML, and client-side code, can be changed very easily with tools like FireBug.
• Your code will be more secure if you start with everything invisible/disabled and make them visible/enabled, than if you start with wide open access and hide things. If you forget to hide something new, all of a sudden clients see a new field they shouldn't touch. If you forget to add code to show a new field based on permissions, you still have to fix it but it's much harder or impossible to exploit a field that doesn't exist.