@sashocheck

Здравствуйте, друзья!
В приложении реализована авторизация на основе Identity. Имеется 3 вида ролей пользователей: user, manager и admin.
У роли admin, естественно, полные права, в т.ч. редактирование записей и доступ к разделу меню "Администрирование".
У manager имеется право редактирования записей, но нет доступа к разделу "Администрирование" (этот раздел не должен отображаться).
Пользователи с ролью user имеют право только просматривать записи, т.е. у них нет доступа и не отображается раздел меню "Администрирование", а так же нет доступа к редактированию записей и не отображаются ссылки перехода на страницы редактирования.
Доступ ограничивается с помощью атрибута Authorize к методам действия.
Подскажите, как наиболее удачно организовать разграничения прав доступа к элементам представления, именно чтобы не отображались не нужные пункты меню и html элементы.
Есть идеи: для каждой роли создавать отдельные представления; одно представление для каждой роли и уже в представлении организовать логику отображения элементов в зависимости от роли.
А может есть какие-то другие, более интересные, методы?

0

Eugene22

sashocheck, в представлении пишите

2

@sashocheck

Eugene22, а как логику перенести из представления в контроллер, но чтобы не создавать представление для каждой роли?

0

@off

Лучше мне кажется создать отдельные представления

1

@XIST

А зачем отдельные? Вам же уже подсказали
И в этом представлении формируете представление под каждую роль

0

@sau

Роли , строго говоря , вообще могут быть какие угодно , и как правило создаются в админке , т.е привязку нужно делать не к ролям , а к полномочиям , которые уже обьединяются той или иной ролью/группой.
Да чего далеко ходить , возьмите вон за пример систему безопасности windows.
Сначала нужно выделить сущности к которым применимы атрибуты полномочий , выделить общие атрибуты доступа , например: чтение, запись , редактирование и т.п , и вынести их в базисную security логику приложения , обеспечить возможность их администрирования. Ну и потом уже просто работа в плане сравнения полномочий у роли текущего юзера с атрибутами безопасности той ил иной сущности. Все это конечно потребует реализации определенной security инфраструктуры.

Просто для наглядности, что такое , например , отображение элемента в приведенном контексте ? - это по сути проверка для роли значения атрибута на чтение , притом если элемент отображает результат вызова бизнес.метода , то атрибуты безопасности можно сделать сквозными - т.е проверка на чтение будет уже не на уровне интерфейса , а на уровне бизнес.логики (или еще ниже , на уровне БД и средствами БД) - что обеспечит нам более универсальное решение . не привязанное к какому либо UI движку. , ну а элемент интерфейса уже в зависимости от результата вызова "засекьюренного" метода может и не отображаться - если например получит AccessReadException/SecurityException и т.п , т.е решение в лоб , на уровне вьюхи аля IsUser("admin") , это самый такой низкобюджетный одноразовый вариант ).

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

1

Eugene22

sashocheck, для контроллера применяется атрибут Authorize с указанием допустимых ролей, например, [Authorize(Roles="admin")] и все

0