symfony роли

  • Автор темы Автор темы stalxed
  • Дата начала Дата начала

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 отлавливать теги, но это множество объектов и множество сервисов, здесь уже откровенно боюсь за распухший конфиг и производительность.

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

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

те. в концепте групп достаточно сказать что он админ (и у него все ключи власти). в концепте ролей нужно все перечислять чтоб все ключи дать
 
Последнее редактирование:
WMix, я бы сказал что роли - это то, к чему может иметь доступ юзер, в обход групп.
А группа - это набор правил, которые позволяют пользователю делать что-то на сайте.
 
это в моем понимании роли 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 концепта но было это на много раньше моей первой встречи с зендом. но поню как я роли делал на первом зенде ))
 
Последнее редактирование:
Интересно, в зендовском описании ACL присутствует термино "Role", это сбивает с толку. Но по смыслу примеров видно, что это — Субъект обладающий правами на Объекты ("Resource") — т.е. пользователь либо группа. ЭТО ВАЖНО: субьект, а не "совокупность прав доступа на объекты" в как это описывает модель RBAC!

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

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