0

This is really bugging me but no matter what I read, I cannot seem to understand how to solve this.

I understand that we can assign roles to users. These roles allow certain activities to be done (CRUD operations in controllers).

But how do we restrict what data this applies to? Where can these rules be written down easily so that my controllers don't become super messy?

A super basic example is:

Factory Managers can Update the information about their own Factory, but not those in other Factories. (But they can Read that data)

Of course this can be implemented easily in a NUMBER of ways, but I actually have more a more complex system(FactoryManagers, FactoryWorkers, SupplyManagers, SupplyWorkers), and need a very robust solution. Here are some ideas:

  1. In the repository, write separate querys which restrict the data first. baseRead baseEdit baseUpdate baseDelete. These queries return lists of what can be done for a particular user. They are then combined with the ID specified by the user and will return nothing if it is not in the subset.
  2. Write logic in the controllers to work it out, but this may end up with numerous calls to the database.

Thanks in advance.

Worthy7
  • 1,235
  • 13
  • 26
  • Please add some code examples that you already have that are super messy. – Ahsan Jun 29 '16 at 04:07
  • Sorry I don't have them in my controller. I have written it in the repo instead. It's just lots of joins on several tables, which is then reused. It's embarrassingly ugly, I'm sure it's not the correct way. Are you implying that doing all the authorization in the controllers is the correct way? – Worthy7 Jun 29 '16 at 04:27
  • Let me know if you need further help. – Ahsan Jun 29 '16 at 04:40

1 Answers1

1

Use a custom Authorization filter, This could only be one approach of many available for this scenario

Following is an summarized code snippet from another answer in SO.

public class AuthorizeUserAttribute : AuthorizeAttribute
{
    // Custom property
    public string AccessLevel { get; set; }

    protected override bool AuthorizeCore(HttpContextBase httpContext)
    {
        var isAuthorized = base.AuthorizeCore(httpContext);
        if (!isAuthorized)
        {                
            return false;
        }

        //do your custom checks here 
        //based on your custom security scenarios and return true or false

    }
}

Usage

[AuthorizeUser(AccessLevel = "Create")]
public ActionResult CreateNewItem()
{
    //...
    return View();
}

See the following for further details

ASP.NET MVC 4 Custom Authorize Attribute with Permission Codes (without roles)

http://www.codeproject.com/Articles/577776/Filters-and-Attributes-in-ASPNET-MVC

Community
  • 1
  • 1
Ahsan
  • 2,378
  • 2
  • 18
  • 40
  • So what about a situation where any user can edit their own password. Should I have an "Edit" access level, and then in the AuthorizeAttribute I write something which makes sure that it is either themselves, and if not, that the are a manager of the user etc etc? – Worthy7 Jun 29 '16 at 05:35