Как лучше всего реализовать разные представления для веб-сайта в зависимости от роли?
В ASP.NET как лучше всего сделать следующее:
- Показать определенные элементы управления, основанные на ваших правах?
- Для элемента управления gridview, как вы показываете определенные столбцы в зависимости от вашей роли?
Я думаю о номере 2, должны ли данные поступать из определенного для роли представления в базе данных.
Ответы 2
Вместо того, чтобы фактически использовать роли для скрытия / отображения определенных элементов управления, я бы предложил создать другой уровень разрешений для каждой роли и вместо этого показывать / скрывать на их основе.
Таким образом, вы можете переопределить, какие разрешения есть у роли, и вам не придется менять свой код.
Кроме того, это позволяет вам создавать новые роли в будущем и просто назначать для роли набор разрешений.
Что касается элементов управления, да ... Я бы просто установил свойство Visible для элемента управления на основе значения user.IsInRole ("имя-разрешения").
Для сеток я бы сделал то же самое ... установил для видимости столбцов логическое значение IsInRole.
//Delete Icon Column
gridViewContacts.Columns[0].Visible = user.IsInRole("DeleteAnyContact");
Я бы сделал ваши разрешения очень детализированными .. например,
- ViewAnyContact
- ViewOwnContact
- EditOwnContact
- EditAnyContact
- AddAnyContact
- DeleteOwnContact
- DeleteAnyContact
- Так далее...
Если вы идете по ролевому маршруту, в ASP.NET (начиная с версии 2.0) есть множество доступных элементов управления членством, которые могут помочь в этом сценарии. Предполагая (и это вполне может быть ошибочным предположением), что вы используете встроенного поставщика членства, вы действительно можете использовать элемент управления LoginView для обработки # 1.
Принцип работы заключается в том, что LoginView может использовать RoleGroups и связанный с ним ContentTemplates для настройки представления пользователя в зависимости от роли. Это легко работает с поставщиком членства в коробке; Я считаю, что если вы создадите своего собственного поставщика услуг членства на основе технологий Microsoft, он также будет работать. (Я не делал этого последнего шага.)
Возможно, вы мог используете его для №2, но это приведет к дублированию кода и усилий, что не является моим личным предпочтением. Я думаю, что ваш выбор использования представлений SQL для конкретных ролей для управления этой таблицей может быть лучше, чем этот вариант. (Конечно, есть и другие варианты, которые могут быть лучше.)
Я поддержу рекомендацию Элайджи Мэнора использовать разрешения вместо ролей. В общем, я тоже так предпочитаю. (И я был удивлен, обнаружив, что технология поставщиков услуг членства не достигла такого уровня.) Однако в любом сценарии, ориентированном на разрешения, вам, по сути, придется все свернуть самостоятельно. (Я сделал это, и, хотя он очень гибкий, код для защиты любой данной страницы может стать непростым.)
Обновлено: прошу прощения; Я хотел включить ссылку на элемент управления LoginView. На DotNetJunkies есть руководство.