Какой выбрать CRUD для стандартного db RBAC в YII2?

Question

[Максим Тимофеев]

Есть сайт в котором уже реализован RBAC, но нет CRUD для него. Смена роли реализована конечно, но создание новых ролей, правил и т.д. нет. Делал вручную.
Теперь задумался прикрутить CRUD ко всему этому, но писать как-то лень, полез искать готовые решения, их много, но они все реализуют либо чать возможностей либо допилено, что-то свое, что не подходит.
Знает ли кто-то готовое решение в рамках стандартного использования описанyого в доках YII2.
Делал по докам и по этой замечательной статье, если кому интересно wiki.it-wiki.org.ua/doku.php/yii2:rbac

И доп вопрос. Кто разбирал yii\rbac\DbManager по кусочкам, скажите, кроме как создание записей в бд он же не создает классы и т.д. По сути можно просто с помощью gii сгенерить rbac для его таблиц и примарафетить немного? То есть можно ли работать напрямую с базой, а не через методы yii\rbac\DbManager для добавления и редактирования?

Answer 1

[devian3000]

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

Для управления ролями правилами и т.д. я считаю что данный функционал избыточен ИМХО.
Но если нужно, лучше написать самому под задачу. Будет проще чем кастомизировать те что есть.

Comments

[Максим Тимофеев]

Если просто admin, user, banned - то да, а если есть наследование, есть правила, например проверка авторства?

[devian3000]

Максим Тимофеев: учитывая что в вебе автором является пользователь или группа то rbac можно и не использовать ( проверку на авторство можно реализовать не через rbac). Тут уже вопрос какая задача. Но в принципе можно написать сервис над rbac, там есть интерфейсы по которым можно его расширить или переписать. Или просмотреть логику и изменять таблицы соответственно. Там логика простая. Правила таблица связей правил и групп, + таблица связей правил с пользователями.

[Максим Тимофеев]

devian3000: Не совсем. Наследование помогает. Если Мы предоставляем права редактировать запись автору и админу - это 2 проверки, а с RBAC это if(yii::$app->user->can(updatePost)). Если еще усложнить взаимосвязи, тогда rbac точно необходим.

[devian3000]

Так я не говорю что он не нужен=)
Если подходить так, как описано, то лучше писать сервис над rbac так как он из коробки не даёт функциональность по идентификации автора статьи.
Т.е. тут в любом случае нужен дополнительный слой абстракции. Вопрос только в том на чём её строить.

А если вы будете использовать yii::$app->user->can('updatePost')
То у вас
а) Должны быть разные пермишины для разных авторов - Это неправильное решение.
б) Администратор должен или иметь пермишен из серии 'globalUpdatePost' и всё равно получаются 2-е проверки (пользователь - админ - модератор).
Или же должен быть включен в пермишен всех авторов, что опять же попахивает кривым решением.
Иначе каждый кто считается автором (а если это хабр положим), то авторов много и они не должны редактировать посты друг друга, а таблица соотношений материал -> автор или не существует, или должна использоваться. что даёт ещё одну проверку.

В общем, я тут вижу решение только в расширении rbac дополнительным слоем абстракции.