Страница 1 из 1

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

Добавлено: 2020.06.18, 12:12
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.

Заранее спасибо

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

Добавлено: 2020.06.18, 14:07
samdark
А точно нужна такая детализация? Не ограничивается ли всё проверкой что админ может всё, а владелец всё, но со своим?

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

Добавлено: 2020.06.19, 07:02
maleks
1)-ый вариант нормальный и целостный, соответственно дальше начнут меняться требования но костыли не потребуются.
Что надо? Иметь разрешение на редактирование поста X? Вот оно в базе.

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

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

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

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

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

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