ASP.Net MVC элегантный интерфейс и авторизация ModelBinder

Question

Мы знаем, что авторизация является сквозной задачей, и мы делаем все возможное, чтобы избежать слияния бизнес-логики с нашими взглядами.

Но я до сих пор не нашел элегантного способа фильтрации компонентов пользовательского интерфейса (например, виджетов, элементов форм, таблиц и т. Д.) С использованием текущих пользовательских ролей без загрязнения представления бизнес-логикой. То же самое относится к привязке модели.

---

Пример

Форма: Создание продукта

Поля:

• Имя
• Цена
• Скидка

Роли:

• Роль Администратор

  • Разрешено просматривать и изменять поле Имя
  • Разрешено просматривать и изменять поле Цена
  • Разрешено просматривать и изменять Скидку

• Помощник администратора роли

  • Разрешено просматривать и изменять Имя
  • Разрешено просматривать и изменять цену

---

Fields, показанные в каждой роли, различны, также model binding необходимо игнорировать роль discount field для «Помощник администратора».

Как бы вы это сделали?

Answer 1

Я мог бы подумать, что для этого нужно создать собственные версии методов расширения ввода . Например, вместо TextBox вы можете создать TextBoxRoles и определить его так:

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

Тогда в коде это будет выглядеть так:

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

Тогда ваша реализация TextBoxRoles проверит роли текущего пользователя через User.IsInRole(), чтобы определить, что должно появиться на странице.

Конечно, вам придется делать это для каждого используемого вами метода расширения ввода.

Answer 2

Поскольку у вас уже есть текущий пользователь и доступ к поставщику авторизации в ваших контроллерах, это идеальная ответственность для них. Используя наивную реализацию, вы можете передать коллекцию виджетов вашему представлению после того, как вы отфильтровали, к каким виджетам имеет доступ текущий пользователь. В случае с полем формы все может стать проблематичным, если рассмотреть проверку на стороне клиента.

Обязательная часть была бы самой прямой из всех, наличие настраиваемого связующего для этих особых случаев хорошо сработает, поскольку у него будет доступ к контексту контроллера, и вы сможете оттуда получить текущего пользователя и связать значения в соответствии с вашими определениями роли.

Answer 3

А как насчет LinFu, AOP-фреймворка? Если это пересекается, то объявите это так и относитесь к нему как к таковому.