Я работаю над внутренним веб-приложением (войти могут только сотрудники), и мне нужна помощь, чтобы найти хороший подход к обработке прав доступа отдельных пользователей к системе.
Сама система находится в C # / ASP.NET (4.0 / Webforms / Forms Authentication) / SQL Server 2008 и имеет несколько различных областей, которые будут иметь различные наборы разрешений. Вы можете думать об этом в простейшем сценарии (создание, просмотр, обновление, удаление), хотя это применимо к различным аспектам системы.
(Я хочу отметить, что это не тип системы CMS, поэтому я не могу выбрать проект с открытым исходным кодом, такой как DotNetNuke или что-то в этом роде. Он разрабатывается с нуля. Я могу использовать библиотеки с открытым исходным кодом, если они хотя доступно.)
Каков будет хороший подход к проектированию системы разрешений пользователей для сложной системы, возможно, с 5-6 различными разделами, которые содержат 10-15 различных видов просмотра / обновления / удаления, содержащихся в каждом разделе?
Цель состоит в том, чтобы сделать это:
- Понятно для пользователей (администраторов) для использования / настройки.
- Простота поддержки кода.
- Простота адаптации при необходимости новых разрешений (разных типов или в разных местах).
На ум приходят два подхода:
Подход 1:
Попробуйте использовать встроенную систему ролей ASP.NET для определения различных разрешений и управления ими оттуда. Я мог бы создавать собственные страницы для обработки различных областей и назначать пользователям наборы разрешений. Я полагаю, что это также позволило бы мне использовать текущий объект сеанса по умолчанию, чтобы содержать все разрешения в системе для пользователя. (HttpContext.User.IsInRole () и т. Д ...).
Теперь, хотя я думаю, что этот метод будет работать, я не уверен, что его будет легко поддерживать или адаптировать к будущим потребностям. Кажется, что это был бы более быстрый способ поднять его с земли и работать, но не лучший долгосрочный срок.
Подход 2:
Ролл мой. В этом сценарии я бы настроил таблицы базы данных для хранения правдивых / ложных стилей разрешений для каждого раздела приложения. Затем я получал эту информацию и помещал ее в сеанс, и в основном обращался к ней в любое время, когда мне нужно было проверить, есть ли у кого-то разрешения на что-либо. Затем я бы создал пользовательские страницы для управления списками и т. Д.
Кажется, этот подход может быть более приемлемым долгосрочным решением. Это дает мне больше возможностей в настройке и способах обработки. Тем не менее, я в основном все еще выполняю работу, которую система ролей абстрагирует для меня в подходе 1. Однако я все же предпочитаю это, чем подход 1.
В конце концов, я не уверен, что любой из этих подходов - лучший способ справиться с этим. Может кто-нибудь помочь объяснить мне, почему любой из вышеперечисленных будет хорошо / плохо? Или даже предложить другую альтернативу относительно «лучшего» способа справиться с этим вообще. Это мое первое крупное начинание в этой области, поэтому у меня нет большого опыта в попытке «защитить» подобное приложение с помощью разрешений. Любая помощь приветствуется!