@runprogr

Как задать глобальные ограничения доступа к моделям при запросах?

Есть сущность организация.
Каждый юзер принадлежит к одной или нескольким.

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

Необходимо сделать так, чтбы юзер при запросе Model::all() или Model::paginate() и тд получал в ответе только те модели, которые принадлежат той же организации что и он сам.
Как внедрить эти ограничения в каждый запрос каждой модели ? Особенно интересует как ограничить товар по организаии, (связь товар -категория-организация) если понять к какой организации он относится можно только через джойны других таблиц.
Например логика scope подразумевает что ограничения будут задаваться только по полям этой модели, но не ее связей
  • Вопрос задан
  • 88 просмотров
Пригласить эксперта
Ответы на вопрос 2
gzhegow
@gzhegow
aka "ОбнимиБизнесмена"
Недавно делал похожую задачу, долго возился и в конце пришел к выводу, что если "все" или "большинство" имеет общую связь - то это две базы данных (разные заказчики, разные бд, устанавливаете отдельно, платят отдельно, бизнес очень любит такое, когда дважды платят за одну работу)

Или одна таблица с морфом, где есть имя модели, имя родителя и айди, как с картинками. То есть доступ определяется по наличию морфа, а не проверке через связь. Один раз грузанул с моделями их морфы, а потом чекаешь isset(). По факту в логике вы все равно вытянете модель из БД, и проверив потом морф бросите 403 исключение, вместо того чтобы "Не тянуть совсем".

Другой вопрос методы работающие с пачкой, нечто вроде "дай мне все документы, которые принадлежат мне в рамках такой-то компании". Там я думаю можно в одной функции написать whereHas() и не тянуть все записи, так же как вы бы писали вместо LEFT JOIN - обычный JOIN чтобы в выборку не попало то, что не должно там быть.

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы