Лучшие практики моделирования пользовательских ограничений в веб-приложении?

StackOverflow https://stackoverflow.com/questions/1623865

Вопрос

Я создаю веб-приложение с управлением доступом на основе ролей, используя безопасность Acegi (Spring).Итак, у меня есть разные пользователи с ролями: ROLE_ADMIN, ROLE_USER и т.д.
Однако мне нужно реализовать различные пользовательские ограничения.

Давайте рассмотрим пример:

Предположим, есть сайт, где пользователи могут смотреть фильмы онлайн.Есть пользователи с ролями ROLE_STANDARD_USER и ROLE_VIP_USER.Обычные пользователи могут смотреть 3 фильма в неделю, а vip-пользователи могут смотреть 10 фильмов в неделю плюс иметь некоторые другие привилегии.И в стандартной группе пользователей есть один пользователь, которому я хочу предоставлять дополнительные 2 фильма в неделю.Количество разрешенных фильмов иногда может меняться.
Кроме того, существуют различные категории фильмов:фэнтези, комедии, классика, новые фильмы и т.д.И я хочу, чтобы некоторые пользователи, независимо от их роли, имели доступ только к определенным категориям.Категории могут создаваться и удаляться динамически.

Существуют ли какие-либо стандартные практики для реализации такого типа пользовательских ограничений?
Можно / должно ли это быть сделано с использованием ролей и разрешений Spring Security?
Или мне нужно подумать о добавлении движка, основанного на правилах, в мое приложение?

Спасибо.

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

Правка 2

В настоящее время основные пользовательские ограничения жестко запрограммированы (остались от системы прототипирования).Думаю, сначала я попробую реорганизовать его в какие-нибудь параметризованные объекты бизнес-сервисов, а затем подумаю, что я могу сделать дальше.Я также рассмотрю возможность использования менеджеров принятия решений по авторизации Spring Security.

Спасибо вам за все предложения!

Это было полезно?

Решение

Я бы не ожидал, что декларативная система безопасности, основанная на ролях, обеспечит мелкозернистый контроль, который вы ищете.Вы уже описали довольно много элементов управления доступом на основе "бизнес-правил", которые вы хотите внедрить, и мы могли бы ожидать, что со временем эти правила станут более сложными.Итак, вам нужна комбинация информации из подсистемы безопасности (кто является пользователем этого запроса?какие роли у них есть?) но затем программно объедините это с бизнес-данными и правилами (этот пользователь получает право на 2 бесплатных фильма, если сегодняшняя дата находится в этом диапазоне).

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

Другие советы

Прежде чем спросить себя, является ли Acegi (или движок правил и т.д.) Правильным местом для этого, я думаю, вам нужно
точно и полностью проанализируйте свои потребности.

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

Пример того, как Модель для ваших нужд:

  • Ограничьте количество обычных фильмов в неделю в соответствии с сумма:
    • роль (3 или 10)
    • бонус для каждого пользователя (по умолчанию 0, если не указано иное)
  • Обновляйте эти номера по мере необходимости
  • Ограничьте просмотр фильмов списком категорий:
    • если для пользователя указан список, используйте его
    • в противном случае используйте список, предоставленный для данной роли

Этот пример имеет много последствий, которые могут быть правильными или неприемлемыми в вашем случае.
Последствия:

  • после обновления номера лимит немедленно изменяется.
  • нет памяти о недельных лимитах, вы не можете запросить это для прошлого (например, для составления статистики).
  • ...

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

Если вы рассматриваете Spring Security, то, на мой взгляд, это один из способов реализации вашего решения.Внедрить AccessDecisionVoter чтобы принять решение о доступе пользователя.Взгляните на справочный источник здесь

Также посмотрите на [javadoc][2] для AccessDecisionVoter.Вы можете реализовать свои правила, внедрив vote способ. 

int vote(Authentication authentication,
         Object object,
         ConfigAttributeDefinition config)

Позвольте Spring обрабатывать доступ (аутентификацию и авторизацию).Если процесс принятия решений становится сложным, возможно, было бы разумно использовать механизм правил.Позвольте методу vote обратиться к механизму разработки правил.Это обеспечивает четкое разделение обязанностей.Позвольте Spring Security обрабатывать доступ, и пусть механизм создания правил вычисляет правила.

[2]: http://static.springsource.org/spring-security/site/apidocs/org/springframework/security/vote/AccessDecisionVoter.html#vote(org.springframework.security.Аутентификация, java.lang.Объект, org.springframework.security.Определение атрибута конфигурации)

Похоже, у вас есть потребности в аутентификации и авторизации - часто люди путают эти два понятия и / или объединяют их.К счастью, Spring Security очень хорошо разграничивает эти два понятия.Ваш пользователь пройдет аутентификацию через цепочку безопасности (будь то форма logj, OpenID, SSL X509), а затем, после завершения, будет авторизован вашими бизнес-избирателями (в вашем AccessDecisionManagers) относительно того, видели ли они уже отведенное им количество фильмов.Если позже потребуется добавить новую бизнес-логику, это просто вопрос написания новых / дополнительных избирателей и внедрения их в вашего менеджера.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top