ASP.Net MVC elegant UI and ModelBinder authorization

Question

We know that authorization's stuff is a cross cutting concern, and we do anything we could to avoid merge business logic in our views.

But I still not find an elegant way to filter UI components (e.g. widgets, form elements, tables, etc) using the current user roles without contaminate the view with business logic. same applies for model binding.

---

Example

Form: Product Creation

Fields:

• Name
• Price
• Discount

Roles:

• Role Administrator

  • Is allowed to see and modify the Name field
  • Is allowed to see and modify the Price field
  • Is allowed to see and modify the Discount

• Role Administrator assistant

  • Is allowed to see and modify the Name
  • Is allowed to see and modify the Price

---

Fields shown in each role are different, also model binding needs to ignore the discount field for 'Administrator assistant' role.

How would you do it?

Answer 1

On way I could think to do this is create your own versions of the input extension methods. For example instead of TextBox you could create TextBoxRoles and define it like this:

public static MvcHtmlString TextBoxRoles(
    this HtmlHelper htmlHelper,
    string name,
    string RolesEdit,
    string RolesView
)

Then in code it would look like this:

<%= Html.TextBoxRoles("Price", "Administrator","Administrator,Assistant") %>

Then your implementation of TextBoxRoles would check the roles of the current user via User.IsInRole() to determine what should appear on the page.

Of course you would have to do this for every input extension method you use.

Answer 2

What about something like LinFu, an AOP framework? If it's crosscutting, then declare it is so and treat it as such.

Answer 3

Since you already have both the current user and access to the authorization provider in your controllers this is an ideal responsibility for them. Using a naive implementation you might pass a collection of widgets to your view after you filtered which widgets the current user has access to. In the case of your form field, things might get hairy when you consider client side validation.

The binding part would be the most straight forward of all, having a custom binder for these special cases will do the trick specially well since it will have access to the controller context and you can grab the current user from there and bind the values according to your role definitions.