symfony роли

stalxed

Новичок
Есть два бандла(задачу намеренно упрощаю для форума).
AcmeUserBundle
AcmeBlogBundle
В AcmeUserBundle есть сервис RoleManager, у класса этого сервиса есть метод addRole, который принимает класс с интерфейсом Symfony\Component\Security\Core\Role\RoleInterface или обычный string.
Задача заключается в том, как этому сервису сообщить роли(вызвать несколько раз addRole сервиса RoleManager), которые есть в AcmeBlogBundle, т.е. сделать зависимость AcmeBlogBundle от AcmeUserBundle, но избежать двухстороннюю зависимость.
Сам вижу лишь два решения, которые меня не удовлетворяют:
1) указать все роли в главном конфиге, но это будет что-то вроде
acme_user:
roles:
one
two
но хотелось бы всё таки отдать эту задачу конкретным бандлам(в случае выше AcmeBlogBundle)
2) использовать теги в контейнере зависимости, т.е. сделать класс роль, сделать множество сервисов(1 сервис - 1 роль) из этого класса, и в каждом сервисе тег, а дальше в бандле AcmeUserBundle отлавливать теги, но это множество объектов и множество сервисов, здесь уже откровенно боюсь за распухший конфиг и производительность.

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

hell0w0rd

Продвинутый новичок
Зачем все используют роли, вместо одной роли? Есть же группы!
 

stalxed

Новичок
Не заметил изменения на форуме и нового раздела symfony - просьба модераторов перенести тему туда.
Остальных просьба помочь - куда копать :)
 

hell0w0rd

Продвинутый новичок
WMix, а я понял, в нормальном мире (а не извращенном мире бандла FOSUser) это называется правами)
Мне на самом деле не встречалась задача разделения серьезнее, чем юзер-админ-суперадмин, но меня дико бесит реализация ролей в этом бандле, потому что они используют тип - массив. То есть чтобы найти всех простых пользователей я должен написать так LIKE 'ROLE_USER', ну почему?? Почему не сделать отдельную сущность и мержить с ней? Почему не сделать ENUM? Константы? Но нет, они выбрали самый идиотский способ.
Ну и я никогда не понимал по поводу ролей потому как на мой взгляд роли - иерархическая структура. А если так - нет смысла делать пользователя и модератором и администратором - администратор и так умеет все, что умеет модератор.
Вообще вся эта тема с группами/ролями мне кажется достойна большого обсуждения на этом форуме. Потому что в симфони например невозможно посмотреть все правила для конкретной роли, потому что многие используют hasRole в контроллерах, шаблонах - везде. На мой взгляд должна быть сущность группы, с кучей is*методов, по которым сразу можно понять, что можно, а что нельзя группе.
 

WMix

герр M:)ller
Партнер клуба
роль (можно представлять как много групп) я представляю как набор permissions (редактировать, читать, добавлять, публиковать, удалять контент). каждый пользователь может иметь несколько ролей, он к примеру и контентом и картинками и статистикой работает. а вот как раз администрактору я не давал бы управлять контентом, не его это дело. да он может себе эту роль дать но это другой вопрос.
иерархия не удобна когда к примеру это все можно кроме этого. и создавать новую группу не очень хочется. лучше надробить на по 8-10 разрешений на роль, и дать пользователю по 8-10 ролей. так это легко понимается. нужно исключение, это будет новая роль но это легче чем иметь группу с 80ю правами рядом другую с еще 80ю но разницей в одном разрешении

для ролей в ACL нужно пихать не пользователей а роли вся разница
 
Последнее редактирование:

hell0w0rd

Продвинутый новичок
WMix, а почему бы не сделать также, как мы это делаем в программировании? Разделить группы на четкие составляющие. Если группа отличается в n разрешений - надо вынести эти разрешения в отдельную группу и не париться.
 

WMix

герр M:)ller
Партнер клуба
ну это и будут роли (или я не понял), концепт групп просто мне представляется иначе, как админ он и продавец, продавец он и пользователь, пользователь он и гость. (иерархия). пользователь всегда пренадлежит одной группе или будет путаница (одна группа запрещает другая разрешает).

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

hell0w0rd

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

WMix

герр M:)ller
Партнер клуба
это в моем понимании роли http://framework.zend.com/manual/2.0/en/modules/zend.permissions.rbac.intro.html
это группы http://framework.zend.com/manual/2.0/en/modules/zend.permissions.acl.intro.html

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

artoodetoo

великий и ужасный
Интересно, в зендовском описании ACL присутствует термино "Role", это сбивает с толку. Но по смыслу примеров видно, что это — Субъект обладающий правами на Объекты ("Resource") — т.е. пользователь либо группа. ЭТО ВАЖНО: субьект, а не "совокупность прав доступа на объекты" в как это описывает модель RBAC!

Кажется FOSUser (а точнее Symfony Security) использует слово "Role" в том же смысле и также реализует ACL, а не RBAC.

Надеюсь с правильной трактовкой терминов работа у топикстартера будет продвигаться быстрее.
 

WMix

герр M:)ller
Партнер клуба
на первом зенде не было rbac и я на acl писал роли. там разница малюсенькая, так и не понял зачем они интерфейсов налепили.
 
Сверху