Ограничение для конкретной роли/ролей

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

Ограничение для конкретной роли/ролей

Сообщение Brainfuck » 2018.07.12, 09:53

У меня настроен RBAC в проекте. Есть роль user, ее наследует editor. Как мне сделать чтобы какое-то действие было доступно только юзеру, но недоступно редактору? Хотя он и является по сути тоже юзером, т.к. наследует эту роль. Или например есть еще одна роль webmaster (который тоже наследует юзера) и мне нужно чтобы действие было доступно юзеру и редактору, но недоступно вебмастеру?

k2rick
Сообщения: 3
Зарегистрирован: 2018.04.14, 19:36

Re: Ограничение для конкретной роли/ролей

Сообщение k2rick » 2018.07.12, 10:47

Создать отдельный пермишн и назначит его editor`у? А проверку делать не по роли, а по пермишну. Сложнее будет, когда от роли editor будет наследник, то он получит и этот пермишн.
Вообще, RBAC не очень гибкий, для более-менее среднего проекта уже нужно свое решение под конкретный проект.

Brainfuck
Сообщения: 189
Зарегистрирован: 2018.02.19, 14:20

Re: Ограничение для конкретной роли/ролей

Сообщение Brainfuck » 2018.07.12, 10:58

k2rick писал(а):
2018.07.12, 10:47
Создать отдельный пермишн и назначит его editor`у? А проверку делать не по роли, а по пермишну. Сложнее будет, когда от роли editor будет наследник, то он получит и этот пермишн.
Вообще, RBAC не очень гибкий, для более-менее среднего проекта уже нужно свое решение под конкретный проект.
Да вот и мне этот RBAC как-то не нравится. В одном проекте я его уже использовал - измучился. Сплошные велосипеды приходится придумывать чтобы его обойти. Ей богу проще было бы хранить роль одним полем в модели юзера. Я бы пожалуй так и сделал, но как быть с AccessControl в методах? Т.е. если во вьюхах еще можно без проблем написать что-то вроде

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

if (Yii::$app->user->identity->role == 'editor') {
echo 'Это можно видеть только редактору';
}
То в методах ведь надо еще кинуть 403 ошибку при запрете доступа. И вручную ее везде кидать - не комильфо. В этом смысле AccessControl был удобен. Хотя создание своих rules - это отдельный геморой...

urichalex
Сообщения: 857
Зарегистрирован: 2015.08.07, 11:03

Re: Ограничение для конкретной роли/ролей

Сообщение urichalex » 2018.07.12, 11:10

Brainfuck писал(а):
2018.07.12, 10:58
Ей богу проще было бы хранить роль одним полем в модели юзера. Я бы пожалуй так и сделал, но как быть с AccessControl в методах? Т.е. если во вьюхах еще можно без проблем написать что-то вроде
Можно хранить роль в базе. Достаточно 1 правило
https://www.yiiframework.com/doc/guide/ ... -umolcaniu

Brainfuck
Сообщения: 189
Зарегистрирован: 2018.02.19, 14:20

Re: Ограничение для конкретной роли/ролей

Сообщение Brainfuck » 2018.07.12, 11:11

urichalex писал(а):
2018.07.12, 11:10
Brainfuck писал(а):
2018.07.12, 10:58
Ей богу проще было бы хранить роль одним полем в модели юзера. Я бы пожалуй так и сделал, но как быть с AccessControl в методах? Т.е. если во вьюхах еще можно без проблем написать что-то вроде
Можно хранить роль в базе. Достаточно 1 правило
https://www.yiiframework.com/doc/guide/ ... -umolcaniu
У меня и так все в базе хранится. Я в курсе

urichalex
Сообщения: 857
Зарегистрирован: 2015.08.07, 11:03

Re: Ограничение для конкретной роли/ролей

Сообщение urichalex » 2018.07.12, 11:12

Brainfuck писал(а):
2018.07.12, 11:11
urichalex писал(а):
2018.07.12, 11:10
Brainfuck писал(а):
2018.07.12, 10:58
Ей богу проще было бы хранить роль одним полем в модели юзера. Я бы пожалуй так и сделал, но как быть с AccessControl в методах? Т.е. если во вьюхах еще можно без проблем написать что-то вроде
Можно хранить роль в базе. Достаточно 1 правило
https://www.yiiframework.com/doc/guide/ ... -umolcaniu
У меня и так все в базе хранится. Я в курсе
Тогда в чем проблема создать роли и не наследовать их? Написать 1 правило, которое сверяет роль из базы с ролью в rbac?

Brainfuck
Сообщения: 189
Зарегистрирован: 2018.02.19, 14:20

Re: Ограничение для конкретной роли/ролей

Сообщение Brainfuck » 2018.07.12, 11:17

urichalex писал(а):
2018.07.12, 11:12
Тогда в чем проблема создать роли и не наследовать их? Написать 1 правило, которое сверяет роль из базы с ролью в rbac?
Раньше я так и делал, но возникла одна неприятность которая заставила меня передумать. Необходимость хранить в базе роль юзера о том что он юзер. Т.е. каждому юзеру при регистрации приходилось присваивать роль user (которая сохранялась в базу). Это не очень красивое решение - т.к. любой юзер по умолчанию и так имеет эту роль. К тому же действительно логично что редактор например наследуется от юзера - ведь он тоже юзер, но с повышенными привилегиями.

Аватара пользователя
Dominus
Сообщения: 778
Зарегистрирован: 2013.03.14, 21:27
Откуда: Россия, Иваново
Контактная информация:

Re: Ограничение для конкретной роли/ролей

Сообщение Dominus » 2018.07.14, 01:11

Brainfuck писал(а):
2018.07.12, 10:58
k2rick писал(а):
2018.07.12, 10:47
Создать отдельный пермишн и назначит его editor`у? А проверку делать не по роли, а по пермишну. Сложнее будет, когда от роли editor будет наследник, то он получит и этот пермишн.
Вообще, RBAC не очень гибкий, для более-менее среднего проекта уже нужно свое решение под конкретный проект.
Да вот и мне этот RBAC как-то не нравится. В одном проекте я его уже использовал - измучился. Сплошные велосипеды приходится придумывать чтобы его обойти. Ей богу проще было бы хранить роль одним полем в модели юзера. Я бы пожалуй так и сделал, но как быть с AccessControl в методах? Т.е. если во вьюхах еще можно без проблем написать что-то вроде

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

if (Yii::$app->user->identity->role == 'editor') {
echo 'Это можно видеть только редактору';
}
То в методах ведь надо еще кинуть 403 ошибку при запрете доступа. И вручную ее везде кидать - не комильфо. В этом смысле AccessControl был удобен. Хотя создание своих rules - это отдельный геморой...
А что мешает использовать AccessControl с RBAC?

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

    /**
     * @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]
                ],
            ],
        ];
    }
Что касается темы, то можно не наследовать роли, а назначать/удалять каждой роли необходимые разрешения. Структура может быть самой разнообразной. Соответственно доступ проверять не по роли а по разрешению.
Не спорь с дураком, иначе окружающие не правильно поймут кто из вас дурак!

Аватара пользователя
maleks
Сообщения: 1656
Зарегистрирован: 2012.12.26, 12:56

Re: Ограничение для конкретной роли/ролей

Сообщение maleks » 2018.07.14, 08:10

Brainfuck писал(а):
2018.07.12, 11:17
Раньше я так и делал, но возникла одна неприятность которая заставила меня передумать. Необходимость хранить в базе роль юзера о том что он юзер. Т.е. каждому юзеру при регистрации приходилось присваивать роль user (которая сохранялась в базу). Это не очень красивое решение - т.к. любой юзер по умолчанию и так имеет эту роль.
Ну так есть же defaultRoles, их не надо присваивать самому.

Аватара пользователя
maleks
Сообщения: 1656
Зарегистрирован: 2012.12.26, 12:56

Re: Ограничение для конкретной роли/ролей

Сообщение maleks » 2018.07.14, 08:15

Brainfuck писал(а):
2018.07.12, 09:53
У меня настроен RBAC в проекте. Есть роль user, ее наследует editor. Как мне сделать чтобы какое-то действие было доступно только юзеру, но недоступно редактору? Хотя он и является по сути тоже юзером, т.к. наследует эту роль. Или например есть еще одна роль webmaster (который тоже наследует юзера) и мне нужно чтобы действие было доступно юзеру и редактору, но недоступно вебмастеру?
Так лучше не делать, ведь это будет противоречить логике всей работы RBAC.
Если роль содержит в себе роль, то и все ее доступы тоже.

С этим вложением элементов друг в друга надо быть поосторожней, много проверок (запросов в БД) оно спровоцирует.
Доку тут воспринимайте чисто как описание возможностей, а не команду.
Для себя сделал все проверки пермишенами, а уже каким ролям они позволены, можно гибко настраивать.

kwasti
Сообщения: 251
Зарегистрирован: 2016.01.28, 16:14

Re: Ограничение для конкретной роли/ролей

Сообщение kwasti » 2018.07.16, 10:03

после плотной раюоты с ролями в yii я для себя сделал вывод, что пример из документации вводит в некоторое заблуждение новичков.
я тоже начинал с ролей: читатель, редактор и т.д...делал наследование...
в итоге права разадавались, и сделать гибкость не получалось.
что в итоге лучше делать:
1. для каждого действия каждого контроллера (где необходим контроль) создавать свой permission
2. наследовать роли и пермишены лишь при 100% их необходимости. (я наследую только пермишены для пермишена администратора и все)
3. создавать луше несколько ролей с привязкой к конкретным перишенам

пример из моей rbac:
в миграции создаю таблицу таблиц, например Page.
понимаю что для нее будет создан станадартный CRUD
сразу в миграции добавляю несколько permission:
indexPage - для Index
viewPage - View
updatePage - Update
createPage - Create
deletePage - Delete

сразу все эти пермишены добавляю в соответствующие пермишены администратора
этого в базе достаточно.
далее в админке создаем роль читателя, и добавляю пермишены: indexPage,viewPage
редактору добавляем другие пермишены и т.д.
в итоге можно читателю разрешить удаление элемента (deletePage), но при этом запретить это делать редактору,

kwasti
Сообщения: 251
Зарегистрирован: 2016.01.28, 16:14

Re: Ограничение для конкретной роли/ролей

Сообщение kwasti » 2018.07.16, 10:11

k2rick писал(а):
2018.07.12, 10:47
Создать отдельный пермишн и назначит его editor`у? А проверку делать не по роли, а по пермишну. Сложнее будет, когда от роли editor будет наследник, то он получит и этот пермишн.
Вообще, RBAC не очень гибкий, для более-менее среднего проекта уже нужно свое решение под конкретный проект.
технология RBAC как раз и считается гибкой реализацией доступов.
другой вопрос как им воспользоваться?
для работы со списками он очень гибок.
если нужно ограничить конкретную запись, то тут нужны некоторые танцы, которые легко решаемы,
правда если нужно исключить ряд записей для множественного запроса, то тут придется повозиться и быстрых способов решения тут нет.
у себя в проекте я для этого ввел дополнительные 4 поля для update, select, read, delete которые использую для контроля доступа к конкретной записи. и в экшене делаю дополнительную проверку:

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

if (Yii::$app->user->can($this->model->roleRead)) {  ... ]

Ответить