Ограничение для конкретной роли/ролей
Ограничение для конкретной роли/ролей
У меня настроен RBAC в проекте. Есть роль user, ее наследует editor. Как мне сделать чтобы какое-то действие было доступно только юзеру, но недоступно редактору? Хотя он и является по сути тоже юзером, т.к. наследует эту роль. Или например есть еще одна роль webmaster (который тоже наследует юзера) и мне нужно чтобы действие было доступно юзеру и редактору, но недоступно вебмастеру?
Re: Ограничение для конкретной роли/ролей
Создать отдельный пермишн и назначит его editor`у? А проверку делать не по роли, а по пермишну. Сложнее будет, когда от роли editor будет наследник, то он получит и этот пермишн.
Вообще, RBAC не очень гибкий, для более-менее среднего проекта уже нужно свое решение под конкретный проект.
Вообще, RBAC не очень гибкий, для более-менее среднего проекта уже нужно свое решение под конкретный проект.
Re: Ограничение для конкретной роли/ролей
Да вот и мне этот RBAC как-то не нравится. В одном проекте я его уже использовал - измучился. Сплошные велосипеды приходится придумывать чтобы его обойти. Ей богу проще было бы хранить роль одним полем в модели юзера. Я бы пожалуй так и сделал, но как быть с AccessControl в методах? Т.е. если во вьюхах еще можно без проблем написать что-то вродеk2rick писал(а): ↑2018.07.12, 10:47 Создать отдельный пермишн и назначит его editor`у? А проверку делать не по роли, а по пермишну. Сложнее будет, когда от роли editor будет наследник, то он получит и этот пермишн.
Вообще, RBAC не очень гибкий, для более-менее среднего проекта уже нужно свое решение под конкретный проект.
Код: Выделить всё
if (Yii::$app->user->identity->role == 'editor') {
echo 'Это можно видеть только редактору';
}
Re: Ограничение для конкретной роли/ролей
Можно хранить роль в базе. Достаточно 1 правило
https://www.yiiframework.com/doc/guide/ ... -umolcaniu
Re: Ограничение для конкретной роли/ролей
У меня и так все в базе хранится. Я в курсеurichalex писал(а): ↑2018.07.12, 11:10Можно хранить роль в базе. Достаточно 1 правило
https://www.yiiframework.com/doc/guide/ ... -umolcaniu
Re: Ограничение для конкретной роли/ролей
Тогда в чем проблема создать роли и не наследовать их? Написать 1 правило, которое сверяет роль из базы с ролью в rbac?Brainfuck писал(а): ↑2018.07.12, 11:11У меня и так все в базе хранится. Я в курсеurichalex писал(а): ↑2018.07.12, 11:10Можно хранить роль в базе. Достаточно 1 правило
https://www.yiiframework.com/doc/guide/ ... -umolcaniu
Re: Ограничение для конкретной роли/ролей
Раньше я так и делал, но возникла одна неприятность которая заставила меня передумать. Необходимость хранить в базе роль юзера о том что он юзер. Т.е. каждому юзеру при регистрации приходилось присваивать роль user (которая сохранялась в базу). Это не очень красивое решение - т.к. любой юзер по умолчанию и так имеет эту роль. К тому же действительно логично что редактор например наследуется от юзера - ведь он тоже юзер, но с повышенными привилегиями.
- Dominus
- Сообщения: 892
- Зарегистрирован: 2013.03.14, 21:27
- Откуда: Россия, Иваново
- Контактная информация:
Re: Ограничение для конкретной роли/ролей
А что мешает использовать AccessControl с RBAC?Brainfuck писал(а): ↑2018.07.12, 10:58Да вот и мне этот RBAC как-то не нравится. В одном проекте я его уже использовал - измучился. Сплошные велосипеды приходится придумывать чтобы его обойти. Ей богу проще было бы хранить роль одним полем в модели юзера. Я бы пожалуй так и сделал, но как быть с AccessControl в методах? Т.е. если во вьюхах еще можно без проблем написать что-то вродеk2rick писал(а): ↑2018.07.12, 10:47 Создать отдельный пермишн и назначит его editor`у? А проверку делать не по роли, а по пермишну. Сложнее будет, когда от роли editor будет наследник, то он получит и этот пермишн.
Вообще, RBAC не очень гибкий, для более-менее среднего проекта уже нужно свое решение под конкретный проект.
То в методах ведь надо еще кинуть 403 ошибку при запрете доступа. И вручную ее везде кидать - не комильфо. В этом смысле AccessControl был удобен. Хотя создание своих rules - это отдельный геморой...Код: Выделить всё
if (Yii::$app->user->identity->role == 'editor') { echo 'Это можно видеть только редактору'; }
Код: Выделить всё
/**
* @inheritdoc
* @return array
*/
public function behaviors()
{
return [
'access' => $this->getAccess()
];
}
/**
* @return array
*/
private function getAccess()
{
return [
'class' => AccessControl::class,
'rules' => [
[
'actions' => ['login'],
'allow' => true,
'roles' => ['?']
],
[
'actions' => ['logout'],
'allow' => true,
'roles' => ['@']
],
[
'allow' => true,
'roles' => [Permission::PERMISSION_MANAGER_USERS]
],
],
];
}
Не спорь с дураком, иначе окружающие не правильно поймут кто из вас дурак!
Re: Ограничение для конкретной роли/ролей
Ну так есть же defaultRoles, их не надо присваивать самому.Brainfuck писал(а): ↑2018.07.12, 11:17 Раньше я так и делал, но возникла одна неприятность которая заставила меня передумать. Необходимость хранить в базе роль юзера о том что он юзер. Т.е. каждому юзеру при регистрации приходилось присваивать роль user (которая сохранялась в базу). Это не очень красивое решение - т.к. любой юзер по умолчанию и так имеет эту роль.
Re: Ограничение для конкретной роли/ролей
Так лучше не делать, ведь это будет противоречить логике всей работы RBAC.Brainfuck писал(а): ↑2018.07.12, 09:53 У меня настроен RBAC в проекте. Есть роль user, ее наследует editor. Как мне сделать чтобы какое-то действие было доступно только юзеру, но недоступно редактору? Хотя он и является по сути тоже юзером, т.к. наследует эту роль. Или например есть еще одна роль webmaster (который тоже наследует юзера) и мне нужно чтобы действие было доступно юзеру и редактору, но недоступно вебмастеру?
Если роль содержит в себе роль, то и все ее доступы тоже.
С этим вложением элементов друг в друга надо быть поосторожней, много проверок (запросов в БД) оно спровоцирует.
Доку тут воспринимайте чисто как описание возможностей, а не команду.
Для себя сделал все проверки пермишенами, а уже каким ролям они позволены, можно гибко настраивать.
Re: Ограничение для конкретной роли/ролей
после плотной раюоты с ролями в yii я для себя сделал вывод, что пример из документации вводит в некоторое заблуждение новичков.
я тоже начинал с ролей: читатель, редактор и т.д...делал наследование...
в итоге права разадавались, и сделать гибкость не получалось.
что в итоге лучше делать:
1. для каждого действия каждого контроллера (где необходим контроль) создавать свой permission
2. наследовать роли и пермишены лишь при 100% их необходимости. (я наследую только пермишены для пермишена администратора и все)
3. создавать луше несколько ролей с привязкой к конкретным перишенам
пример из моей rbac:
в миграции создаю таблицу таблиц, например Page.
понимаю что для нее будет создан станадартный CRUD
сразу в миграции добавляю несколько permission:
indexPage - для Index
viewPage - View
updatePage - Update
createPage - Create
deletePage - Delete
сразу все эти пермишены добавляю в соответствующие пермишены администратора
этого в базе достаточно.
далее в админке создаем роль читателя, и добавляю пермишены: indexPage,viewPage
редактору добавляем другие пермишены и т.д.
в итоге можно читателю разрешить удаление элемента (deletePage), но при этом запретить это делать редактору,
я тоже начинал с ролей: читатель, редактор и т.д...делал наследование...
в итоге права разадавались, и сделать гибкость не получалось.
что в итоге лучше делать:
1. для каждого действия каждого контроллера (где необходим контроль) создавать свой permission
2. наследовать роли и пермишены лишь при 100% их необходимости. (я наследую только пермишены для пермишена администратора и все)
3. создавать луше несколько ролей с привязкой к конкретным перишенам
пример из моей rbac:
в миграции создаю таблицу таблиц, например Page.
понимаю что для нее будет создан станадартный CRUD
сразу в миграции добавляю несколько permission:
indexPage - для Index
viewPage - View
updatePage - Update
createPage - Create
deletePage - Delete
сразу все эти пермишены добавляю в соответствующие пермишены администратора
этого в базе достаточно.
далее в админке создаем роль читателя, и добавляю пермишены: indexPage,viewPage
редактору добавляем другие пермишены и т.д.
в итоге можно читателю разрешить удаление элемента (deletePage), но при этом запретить это делать редактору,
Re: Ограничение для конкретной роли/ролей
технология RBAC как раз и считается гибкой реализацией доступов.k2rick писал(а): ↑2018.07.12, 10:47 Создать отдельный пермишн и назначит его editor`у? А проверку делать не по роли, а по пермишну. Сложнее будет, когда от роли editor будет наследник, то он получит и этот пермишн.
Вообще, RBAC не очень гибкий, для более-менее среднего проекта уже нужно свое решение под конкретный проект.
другой вопрос как им воспользоваться?
для работы со списками он очень гибок.
если нужно ограничить конкретную запись, то тут нужны некоторые танцы, которые легко решаемы,
правда если нужно исключить ряд записей для множественного запроса, то тут придется повозиться и быстрых способов решения тут нет.
у себя в проекте я для этого ввел дополнительные 4 поля для update, select, read, delete которые использую для контроля доступа к конкретной записи. и в экшене делаю дополнительную проверку:
Код: Выделить всё
if (Yii::$app->user->can($this->model->roleRead)) { ... ]