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 though Aldeel's answer works, it does not seem the best solution for me. I'll explain why.

I'll try to explain what I need very detailed and hopefuly some of you will be able to help me out :D

I need to show different views but it's not only like that. Each user can have access to different parts of the page.

I'll give an example:

Imagine a page 'X' with this structure

Field A
Field B
Field C
Field D

When user U1 from group G1 visit page X the system checks the DB for that group's permission on page X. User U1 can see Field A and Field B, but only edit Field A.

User U2 that is set to no group visits page X. The system checks for his permissions on page X. User U2 can see and edit all fields.

When user U3 from group G2 visit page X the system checks the DB for that group's permission on page X. User U3 can see Field C and Field D, but can not edit any.

I hope it's easy to understand...

I coudn't find a way to do that instead of filling ViewData with lots of data about that specific user's permission. In my example there are only 4 fields, but in my current project I have no screen with less than 20 fields. So I guess you can see how ugly and not productive that is.

The idea is similar to a social network, as I said (facebook example). When a user visiting UserX's page can only see what UserX has allowed him to.

I really appreciate any help.

Best regards.

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.