RBAC и deploy

Всё про контроль доступа пользователей: фильтры, RBAC, проверки
Ответить
satoved
Сообщения: 14
Зарегистрирован: 2015.10.07, 17:51

RBAC и deploy

Сообщение satoved » 2017.02.03, 10:46

Поделитесь жизнеспособным методом для ведения RBAC ролей/разрешений на DEV, и переносе их на PROD.

Если хранить все в БД и менять через админку, придется переносить все руками или делать странные миграции каждый раз.

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

Код: Выделить всё

$authManager->removeAllPermissions();
$authManager->removeAllRoles();
// Назначаем все заново?
Если так, то как сохранить Assignments?

Аватара пользователя
ElisDN
Сообщения: 5428
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: RBAC и deploy

Сообщение ElisDN » 2017.02.03, 10:55

Проще либо руками, либо миграциями.

Аватара пользователя
samdark
Администратор
Сообщения: 9195
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: RBAC и deploy

Сообщение samdark » 2017.02.03, 11:34

Миграциями удобно.

Nex-Otaku
Сообщения: 825
Зарегистрирован: 2016.07.09, 21:07

Re: RBAC и deploy

Сообщение Nex-Otaku » 2017.02.03, 12:03

У меня есть контроллер, который строит дерево ролей, прав доступа "с нуля". В том, чтобы написать такой, ничего сложного нет, если вы уже разобрались, как работает RBAC и продумали дерево ролей. Все примеры и необходимая информация есть в документации и в исходном коде.

Все операции выполняются через компонент Yii::$app->authManager.

Привязка.

Главная проблема, как сохранить привязку ролей и разрешений к пользователям. Тот самый "assignments". Ведь роли могут меняться очень сильно. Пока у меня небольшой проект, и ролей, назначенных "вручную", немного, я могу обойтись конфигом, в котором перечисляю логины пользователей и их привязку к ролям.

Код: Выделить всё

return 	[
    'developer' => [
        'super-developer@developer.ru',
    ],
    'administrator' => [
        'mega-administrator@administrator.ru',
        'gendirektor@mail.ru',
    ],
    'moderator' => [
        'ultra-moderator@moderator.ru',
    ],
];
Но это, конечно, неудобно. Поэтому я решил использовать такую концепцию:

Пользовательские группы.

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

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

Модуль для управления группами я пока ещё не сделал. Поэтому похвастаться нечем )

Расширения.

Есть и другие решения, в нескольких расширениях Yii. Они сводятся к трём подходам:

1. Дополнительное хранение привязки роли к пользователю отдельным полем (аналогично описанным мной группам)

2. Миграции в том или ином виде. ( https://github.com/rmrevin/yii2-rbac-migration )

3. Автоматическое обновление привязки, основываясь на старой информации о привязке и новом дереве ролей. ( https://github.com/rmrevin/yii2-rbac-command )

Миграции я не использую, потому что мне, разработчику, будет очень сложно впоследствии разобрать структуру дерева ролей. Когда дерево строится с нуля, это довольно наглядно отображено прямо в коде. Но с миграциями уже сложнее - нужно смотреть по всем миграциям, что менялось, либо вести описание дерева отдельно, и постоянно обновлять.

Автоматическое обновление заманчиво, но я предпочту группы, потому что с группами я могу упростить администрирование для конечного пользователя. Админу не будет нужно ничего знать о ролях и правах доступа. Он просто будет выбирать группу для пользователя.

satoved
Сообщения: 14
Зарегистрирован: 2015.10.07, 17:51

Re: RBAC и deploy

Сообщение satoved » 2017.02.03, 15:10

Спасибо за варианты, буду пробовать.

Ответить