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

Думаю, речь о том, что на текущий момент ТС не видит смысла вводить дополнительный слой абстракции "лишнюю" сущность "роль". Т.к. в итоге всё завязано на user-а.. (по сути - у всех одна роль "авторизованный пользователь", а логика сводится к разрешению отдельных прав (на редактирование?) доступа к конкретным объектам)..

В предельном случае я вижу это как наличие неопределённого массива юзеров и неопределённого массива объектов доступа. И есть альтернатива:

1) добавлять массив доступных объектов каждому юзеру

2) добавлять массив допущенных юзеров каждому объекту.

В общем случае это абсолютно симметричные решения. Сделать выбор можно лишь из конкретики, то есть нужно смотреть, что оптимально. Например, есть 10 юзеров и 1000 объектов - тогда вариант 2. Или 1000 юзеров и 10 объектов - тогда вариант 1. Или же смотреть, исходя из каких-то ещё данных - наличие категорий юзеров, наличие категорий объектов, и т.п.

Как организовать с точки зрения структуры данных вопросов нет. Вопрос как с точки зрения программного кода.

---------- Добавлено 14.10.2019 в 08:13 ----------

На самом деле, когда проверка прав происходит только при попытке выполнить действие над объектом, все просто. Любой из трех методов сгодится. Третий мне понравился с той точки зрения, что не инициализируем лишний код когда не надо.

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

Так "может"-то (редактировать/удалять) пользователь.. а не объект =) И да, пользователь один "на страничку" (отображаемую в браузере).. а объектов - много..

Если очень хоцца.. можно, конечно добавить для объекта некое isEditable (by)

if ($post->is('editable', $user))

При этом реализацию опять же убрать в

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

кхм.. если тут объект - это не экземпляр класса, а кусок HTML-кода, то в любом случае он выводится (на страничку) для текущего пользователя..

Вы можете добавить метод, который пользуется услугами Security.

Пример такого отношения для сущности User:

class User {
    // .....
    
    public function hasPermission($action, $object) {
        return Serurity::isGranted($action, $object, $this);
    }
}

Такое отношение называется "Ассоциация" (частный случай композиции). Скорее всего это имел ввиду ivan-lev под словом "комбинировать".

Не вижу принципиальной разницы. Всё аналогично. В первом случае кнопка "Редактировать" выводится для одного объекта, во втором - то же самое для нескольких.

Понятно. Тогда возможно и правда не стоит городить лишний уровень (хотя это гибче и на перспективу).

НО! Когда надо

то это уже речь о возможностях (capabilities) ролей/юзеров. И тут опять же зависит от того, нужно ли их разделать по уровню доступа. Если да, то надо бы их вводить. ИМХО.