Расширение поставщиков роли ASP.NET

Question

Поскольку интерфейс RoleProvider, по-видимому, рассматривает роли не что иное, как простые строки, мне интересно, существует ли какой-либо неаккуратный способ применения необязательного значения для роли для каждого пользователя ,

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

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

Я видел в другом месте предложение просто создавать дополнительные разделенные роли, такие как «editor.raptors» или somesuch. Это не идеальный вариант, потому что это сильно раздует число ролей, и я могу сказать, что это будет очень трудная продажа, чтобы заменить нашу текущую реализацию (которая также очень не идеальна, но имеет то преимущество, сделанный для работы с нашей пользовательской базой данных).

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

Есть ли лучший способ?

EDIT: Моя первоначальная цель состояла в использовании более встроенных функций ASP.NET. Например, контролируйте доступ через <authorization/> элементов в Web.config. Выполнение этого, насколько я вижу, требует выполнения самих ролей. Концепция наших современных систем auths, похоже, очень хорошо отличалась от этого ограничения.

Отвечая на вопросы mnemosyn в

1. Да. У нас есть центральная база данных для пользователей, приложений и их полномочий. Это основная система, и вокруг нее не обойтись.
2. В настоящее время наша система не является иерархической, и на самом деле она требует больших усилий для поддержания. Когда приложение создается, определяется набор полномочий (например, «admin», «пользователь», «poweruser», «gatekeeper», «keymaster» и т. Д.). Затем пользователи связываются с этими полномочиями с необязательным значением для уникальной комбинации полномочий пользователя и (приложения).
3. Можете ли вы рассказать об этих «категориях», о которых вы говорите?

Answer 1

Это действительно звучит как архитектурная проблема для меня.

Во-первых, вам нужно точно определить, что вам нужно. На втором этапе сопоставьте это с конкретной реализацией. Чтобы продвинуться вперед в этом вопросе: я бы не использовал встроенных поставщиков ни для чего, кроме самых простых случаев. Кроме того, эта проблема быстро становится очень сложной, поэтому я постараюсь сделать ее максимально простой.

Разрабатывать свои потребности, попытайтесь определить:

• вам действительно нужно сопоставить концепцию роли в базу данных, как если бы в CMS делать? Или изменения в вашей системе ролей подразумевают изменение системы. В этом случае вы можете пойти на гораздо более простое решение и поместить enum в пользователя. Это позволит сэкономить много запросов на доступ к базе данных, упрощает выбор соединений и т. Д.
• Что вы пытаетесь достичь благодаря понятию многопользовательской роли, которое вы объяснили? Это действительно роли, которые вам нужны? Как насчет индивидуальных разрешений? Вы, например, имеете иерархическую структуру, чтобы каждый узел мог иметь определенный набор разрешений, связанных с ним, подобно концепции безопасности файлов Windows?
• Если это только категории, почему бы не показывать категории категорий пользователям, то есть предоставлять каждому пользователю определенную роль в каждой категории. Для этого потребуются некоторые настройки для категории по умолчанию и т. Д.

Несколько советов: Не беритесь за белыми списками, всегда используйте черные списки. Управление «белыми списками» - это боль, особенно. когда множество правил объединяются. Например, в drupal я считаю, что это один из главных недостатков (именно поэтому они перестраивают его для использования черных списков в версии 7). Предоставление пользователю возможности делать что-то, что им не нужно, обычно является гораздо более серьезной проблемой, чем наоборот.

Концепция доступа к файлам Windows очень сложна, поскольку она имеет как черный, так и белый список, которые дополнительно могут быть унаследованы, поэтому старайтесь держать свое решение намного проще, чем это.

Строка конкатенации thingie звучит довольно опасно для меня, я бы выбрал более чистое решение в любом случае. Этот тип мета-логики дает головную боль.