Как реализовать управление правами для конкретных записей сущности?

Всё про контроль доступа пользователей: фильтры, RBAC, проверки
Ответить
bagos
Сообщения: 1
Зарегистрирован: 2020.06.18, 12:07

Как реализовать управление правами для конкретных записей сущности?

Сообщение bagos »

Добрый день!
В большинстве случаев достаточно простого управления ролями и разрешениями на доступ к action контроллера.
А тут встала задача устанавливать права на конкретные записи сущностей. Например возьмём сущность post (упростим до id, name).
Т.е. дать разрешение на редактирование постов например с id - 1,3,121. и разрешение на удаление постов 1,3, 55,99. Требуется установить для определенной роли допустим 3 разрешения:
1. сreate - создание поста
2. update - редактирование поста
3. delete - удаление поста

Если для 1. Create создаем permission - module.controller.create и вешаем на роль, то для update и delete требуется выставить конкретный посты, которые роль позволит редактировать или удалять.

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

1) На каждый пост создавать свои permission (update, delete), например module.posts.update.3, module.posts.update.121, module.posts.delete.92 . К плюсам отношу простоту создания разрешения, навешивания на роль, и дальнейшая проверка пользователем на наличие разрешения. К минусам: огромное кол-во разрешений для каждой записи, хотя возможно это нормально и минусом не является, но почему то в таблице ролей и разрешений хочется видеть небольшое кол-во записей.

2) Создать два разрешения module.posts.update и module.posts.delete, при установке прав навешивать на роль, а в поле Data разрешения хранить массив ролей с доступными id постов.
Вида data: [firstRole: [1, 4, 191 ] ]
Ну и добавить правило к разрешению, по которому будет происходить проверка. К плюсам, отсутсвует порнуха в таблице authitem от кол-ва разрешений и их наименованиях. К минусам ощущение "масла масленного" в логике, к роли добавляем разрешение, еще и прописываем в Data массив разрешенных данных для этой же роли. Плюс для каждой новой роли либо придется сразу добавлять разрешение, либо при установки разрешения на пост, проверять что в поле дата, и если там роли нет то добавлять туда новую запись.
3) Создать сущность, которая будет содержать информацию о ролях, разрешениях, и доступных записях, но мне кажется это лишнее и вопрос решается более грамотно путем использования имеющейся логики rbac.

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

Re: Как реализовать управление правами для конкретных записей сущности?

Сообщение samdark »

А точно нужна такая детализация? Не ограничивается ли всё проверкой что админ может всё, а владелец всё, но со своим?
Аватара пользователя
maleks
Сообщения: 1985
Зарегистрирован: 2012.12.26, 12:56

Re: Как реализовать управление правами для конкретных записей сущности?

Сообщение maleks »

1)-ый вариант нормальный и целостный, соответственно дальше начнут меняться требования но костыли не потребуются.
Что надо? Иметь разрешение на редактирование поста X? Вот оно в базе.
Yii2 universal module sceleton - for basic and advanced templates
Arhat109
Сообщения: 61
Зарегистрирован: 2016.11.23, 09:06
Откуда: из СССР

Re: Как реализовать управление правами для конкретных записей сущности?

Сообщение Arhat109 »

Ваш вопрос покрывается полностью ABAC моделью, но не помню чтобы она была реализована в каком-либо фреймворке "целостно".
Как вариант, дополнять таблицу данных полем "автор" и выдавать пользователю "только его записи". Но это не всегда "айс", ибо кто-то (Одмин) должен "видеть всё".

Ещё как вариант, сопровождать каждую запись доп. полем "ключик", значение которого навешивается к любому запросу через билдер (допиливать билдер), это "ключевая модель прав" .. соответственно, иметь "табличку ключей", роль расширять "набором ключей" ну и иметь "спец ключ" админу, чтобы отключать в билдере дополнение запроса проверкой ключей.
В общем виде - гемморно, поэтому как понимаю и нет. Так делали на Zend году в 2010 кажись..

Ещё как вариант снабжать Active record методом canAccess(наборРолейЮзверя) и после выборки проверять может ли юзверь это видеть(править, удалять и т.д.) .. кмк, "худший из вариантов", но можно навешивать на уже готовое легаси (делал так в последнем проекте).

Вопрос далеко не праздный, и достаточно емкий, особенно во всяких СРМ-системах, где надо дать одним доступ на свои записи (фирмы, переписка менеджера продаж и т.д.), а другим на его и его тоже (начальник отдела продаж - видит записи только своих менеджеров) и т.д.
Применений - масса в серьезной разработке.

Году в 2013-м начинал делать совмещенный вариант "ключевой модели" и "доменной" с ролевой (параметризованная роль - то что Вы ищете) .. но, забросил всвязи со сменой работы.
Все чаще Историки находят следы древней и очень высокоразвитой Цивилизации, со странными буквами .. СССР
Ответить