это просто строка и судя по доке симфони, юзер хранит роли в массиве строк.
У меня есть необходимость отображать роли пользователей на фронте в виде иерархии, также нужно, чтобы названия ролей были читаемы для пользователей.
То есть мне уже нужно создавать сущность Роль и тут уже возникает сложность, тк встроенные проверки доступа работают лишь со строковыми ролями.
Я думаю, что в моём случае хранение ролей нужно реализовать в виде сущностей.
А контроль доступа уже выстраивать с помощью voters, котырые будут
Хорошая ли идея?
А в чем сложность? UserInterface это интерфейс, как вы там реализуете getRoles() ваше дело. Чоб не orm-сущность отдельная?
Да, это возможно, меня беспокоило что встроенные механизм ролей в симфони это строки, то есть сущность ролей не будет контролировать методами isGranted и тд
__toString(): string
Вроде должно работать, дергается как раз метод getRoles а в нем что угодно делайте.
Я понял, об этом не подумал, спасибо!
вообще мне нравится описывать роли в security.yml и там проводить все комбинации. После пользователю дать через UserGroup (сущность) из названием одной роли из security.yml ` UserGroup id title roles 1 EDITOR: "ROLE_EDITOR" 2 ADMIN: "ROLE_ADMIN" security.yml security: role_hierarchy: SET_FOR_EDITOR_1: - ROLE_EDIT_ARTICLE - ROLE_SHOW_ARTICLE SET_FOR_PUBLISHER_ARTICLE - ROLE_DELETE_ARTICLE - ROLE_PUBLISH_ARTICLE ROLE_EDITOR: - SET_FOR_EDITOR_1 ROLE_ADMIN - SET_FOR_EDITOR_1 - SET_FOR_PUBLISHER_ARTICLE ` и в коде юзать ->can('ROLE_SHOW_ARTICLE')
не совсем понял один момент, вроде как иерархия ролей в секьюрити файле прописывается несколько по другому, что это за опции?
``` role_hierarchy: ROLE_ADMIN: ROLE_USER ROLE_SUPER_ADMIN: [ ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH ] ```
писал от руки подформатировал
Обсуждают сегодня