Более 32 ролей / разрешений Symfony2 Security System?

Question

Все в Symfony2 выглядит довольно хорошо, однако есть одна проблема, которую я тоже не могу найти решение. Проблема в том, что компонент безопасности Symfony2 ограничен 30-32 ролями / разрешениями. Для одного из моих проектов, системы управления проектами / отслеживания проблем, потребуется более 32 разрешений. Существует ряд различных компонентов системы, которые должны иметь собственный набор разрешений. То, что у кого-то есть разрешения на создание, чтение, обновление или удаление проблем, не означает, что у них есть эти разрешения для проектов, этапов и т. Д. Каждому компоненту потребуются собственные разрешения на создание, чтение, обновление и удаление, чтобы не Упомяните разрешения для отдельных компонентов, и нет никаких сомнений, что я достигну 30-32 ролей / разрешений.

Я задал вопрос в IRC и в списке рассылки без указания направления, куда идти. Я бы предпочел иметь возможность просто добавить эту функциональность поверх существующего компонента безопасности (предпочтительно через пакет). Я не уверен, как мне добиться более 30-32 ролей / разрешений с помощью компонента безопасности symfony2.

Я бы предпочел не разрабатывать собственную систему безопасности с ACL.

Answer 1

Я думаю, вы неправильно поняли систему acl, вы можете создать только 32 вида ролей, но по объектам домена.Это делается с помощью операций с битовыми масками над целыми числами (это объясняет ограничение '32' как целое число ... ну, вы знаете ответ).

Так, например, разрешение на удаление одного объекта будет таким же - 'MASK_DELETE '- для проекта этап или билет.Поэтому, если вы использовали ProblematicAclManagerBundle , вам просто нужно сделать:

$aclManager->addPermission($ticket, $userEntity, MaskBuilder::MASK_DELETE);

или

$aclManager->addPermission($projet, $userEntity, MaskBuilder::MASK_DELETE);

чтобы дать пользователю разрешение на удаление, например, $ project или $ ticket.Он также создает запись acl для объекта домена и запись для пользователя, если их там еще нет.Что мне нужно знать, так это то, что вы можете создать разные имена масок для класса или для каждого класса пакета?

Более подробное объяснение для acls здесь

Answer 2

как указано выше в комментариях к вопросу от gilden:

Но это именно тот случай использования ACL. Вы можете начать использовать встроенную систему ACL уже сегодня! Его также легко модифицировать / расширять в соответствии с вашими потребностями.

Для начинающих, я думаю, что лучше прочитать эти статьи из официальной книги Symfony2 в следующем порядке:

1. Безопасность - Включая информацию о: аутентификации и авторизации, пользователях и ролях, управлении доступом в шаблонах и контроллерах
2. Списки контроля доступа (ACL) - Включая информацию о: начальной загрузке и настройке, создании ACL, ACE, проверке доступа и совокупных разрешений
3. Расширенные понятия ACL - Включая информацию о: Концепциях проектирования, Структуре таблицы базы данных, Области применения, Решениях до и после авторизации, Процессе получения решений об авторизации

Здесь, на SO.com, также есть интересный вопрос о ACL-файлах Symfony2

Удачи!

Answer 3

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

Ключ к решению проблемы находится в следующем предложении вашего вопроса:

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

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

• Создать класс, который расширяет AclVoter.
• Переопределите метод supportsClass(), чтобы убедиться, что избиратель будет голосовать только за классы компонента, для которого он предназначен.
• Создайте свой собственный PermissionMap, содержащий набор разрешений, необходимых компоненту.
• Передайте PermissionMap в AclVoter в конфигурации ваших услуг.
• Отметьте избирателя как security.voter, чтобы AccessDecisionManager начал его использовать.

Это должно пройти долгий путь.

Я также рекомендую подумать о коде ACL Component , есть много функций, которые, к сожалению, не документированы.