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

12
IL
На сайте с 20.04.2007
Offline
418
#11
Sitealert:
Список объектов - это и есть список ролей, фактически.

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

... :) Облачные серверы от RegRu - промокод 3F85-3D10-806D-7224 ( http://levik.info/regru )
S
На сайте с 30.09.2016
Offline
469
#12
ivan-lev:
логика сводится к разрешению отдельных прав (на редактирование?) доступа к конкретным объектам

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

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

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

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

Отпилю лишнее, прикручу нужное, выправлю кривое. Вытравлю вредителей.
Solmyr
На сайте с 10.09.2007
Offline
501
#13
Sitealert:
1) добавлять массив доступных объектов каждому юзеру
2) добавлять массив допущенных юзеров каждому объекту.

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

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

Gerga:
Что именно?

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

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

IL
На сайте с 20.04.2007
Offline
418
#14
Solmyr:
метод, который отвечает надо или нет добавлять элемент интерфейса, именно у самого объекта. Это логично.

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

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

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

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

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

Solmyr:
добавлять элемент интерфейса, именно у самого объекта

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

Gerga
На сайте с 02.08.2015
Offline
94
#15
Solmyr:
В такой ситуации хочется иметь метод, который отвечает надо или нет добавлять элемент интерфейса, именно у самого объекта.

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

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


class User {
// .....

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

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

S
На сайте с 30.09.2016
Offline
469
#16
Solmyr:
На самом деле, когда проверка прав происходит только при попытке выполнить действие над объектом, все просто.
...........
Но вот есть ситуация: рисуем страничку приложения с объектами, объектов несколько или много. В том случае если у пользователя которому показываем страничку есть право сделать что-то с объектом (редактировать, комментировать, удалить, голосовать, скрыть) к объекту добавляется элемент интерфейса соответствующий.

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

SeVlad
На сайте с 03.11.2008
Offline
1531
#17
Solmyr:
Потому что фактически один юзер - одна роль. Для каждого юзверя список объектов к которым есть доступ - разный. Причем даже не только просто юзер имеет доступ к своим объектам, а к своим "плюс" - где плюс просто разный список для разных юзеров

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

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

Solmyr:
сделать что-то с объектом (редактировать, комментировать, удалить, голосовать, скрыть)

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

Делаю хорошие сайты хорошим людям. Предпочтение коммерческим направлениям. Связь со мной через http://wp.me/P3YHjQ-3.
12

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий