Вопрос по архитектуре приложения. Проверка прав доступа.

Solmyr, сделать 3 вариантом, но правила расписать в других Voter классах, чтобы не раздувать этот глобальный инстанс методами, нап. его можно назвать "Security". Сделав таким образом, вы в любом классе можете добавить метод has_permission, который будет вызывать методы Security.

Почему нет если:

RBAC же как раз и служит для управления возможностями ролей.

Тем более если набор "тех или иных действий над объектом" будет разный для родей/юзеров. Но тогда надо еще этим действиями надо задавать capabilities.

Ну.. только не контроллер =)

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

if ($user->can($permission, $params)) ...

А логику прятать в некий Gate/AuthManager

 checkAccess ( $userId, $permissionName, $params = [] )

А случаи с ownPost и прочими "своё-чужое" реализовывать через правила вроде:

class AuthorRule extends Rule
...
 public function execute($user, $item, $params)
    {
        return isset($params['post']) ? $params['post']->createdBy == $user : false;
    }

Yii2 - https://www.yiiframework.com/doc/guide/2.0/ru/security-authorization#ispolzovanie-pravil

или: (laravel)

Gate::define('update-post', function ($user, $post) {
  return $user->id == $post->user_id;
});

Фильтровать можно как в базовом контроллере, так и непосредственно в action-е.

Значит, надо сделать. И получится – в варианте 2 проверка варианта 1.

На самом деле, они есть.. Даже если явно не обозначены.. Как минимум...

- администратор

- авторизованный пользователь

- гость

Просто перейти от проверки вроде

if (is_admin())

к более абстрактному и расширяемому..

Solmyr, на самом деле, можно любым из вариантов (и их комбинацией) к чему-то интересному прийти.. Главное - начать.. ))

Ну всем же понятно, что роли – это более широкий диапазон. Хотя, конечно, разница только в количестве градаций. И с этой точки зрения - вроде как стандартная ситуация, реализованная 100500 раз.

Начато уже давно и давно работает. По третьему методу. Вот именно так как Gerga, говорит, с вспомогательными классами. Но вот при очередных расширениях функционала, стали меня терзать сомнения что это не совсем верно. Сейчас склоняюсь в пользу второго варианта, но пока еще не склонился окончательно. Продумываю разные сценарии. А комбинации и зоопарки методов - это не хорошо. Потом баги стадами ходить будут.

---------- Добавлено 13.10.2019 в 22:53 ----------

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

Сделав вариантом 2, у вас получатся огромные классы-контроллеры с бизнес-логикой, это плохо. В хорошей архитектуре контроллеры должны быть тонкими и должны использовать методы Services-классов (3 вариант).

---------- Добавлено 13.10.2019 в 23:06 ----------

Что именно?

Под комбинацией имел в виду, что логика

$user->can('update-post',$post)

реализуется путём чего-то похожего на:

Gate::check($user, 'update-post', $post)

Первое более логично.. второе - суть.

Да ладно! Это ничего не меняет, по сути. Список объектов - это и есть список ролей, фактически. Бахаем в БД для каждого юзера сериализованный объект или массив, например, – а при выяснении прав на совершение действий проверяем наличие необходимого элемента.