Использование авторизации для предотвращения доступа пользователей к несвязанным данным в API REST

Question

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

Проблема, с которой я столкнулся, связана с авторизацией. Я использую JWT для обработки большинства материалов на уровне пользователя и компании (т. Е. Пользователь является частью этой компании, поэтому он может вносить изменения в эту компанию в зависимости от уровня доступа). Однако, как только мы дойдем до более глубоких таблиц в базе данных, таких как добавление и редактирование строк таблицы, мне придется пройти весь путь по цепочке таблиц, чтобы определить, к какой компании принадлежит эта строка. Это кажется мне действительно неэффективным, особенно когда дело касается отношений «многие ко многим», и внесение любых изменений в структуру данных было бы кошмаром. Другая идея заключается в добавлении столбца для идентификатора компании в каждую таблицу, но это, на мой взгляд, противоречит цели реляционных данных.

Есть ли лучшая практика для решения этого типа проблемы? Я смотрел в Интернете, но не очень успешно нашел решение, возможно, отчасти потому, что я сосал, говоря о проблеме несколькими простыми словами, но в любом случае я был бы очень признателен за любые советы, которые вы, ребята, смогли бы найти. предложить!

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

Answer 1

Я не знаю, является ли это «лучшей практикой», но вот как я к ней подхожу:

1. Мои конечные точки REST API позволяют мне точно знать, что пытается сделать вызывающая сторона.
2. Мое управление сеансом (например, JWT и связанные пользовательские данные) управляется на уровне REST API. Когда приходит запрос, я загружаю данные пользователя и компании для этого пользователя. Это предполагает, что JWT не сохраняет права доступа - только идентификаторы пользователей. Это позволяет изменять права доступа в течение всего срока службы JWT. Полезно для долгоживущих токенов, используемых в некоторых приложениях.
3. Учитывая (1) и (2), код может определить, есть ли у пользователя права на выполнение запроса.

Как только код проходит этап (3), он больше не беспокоится о правах доступа. На самом деле, нижние уровни кода не нуждаются в логике прав доступа.

Да, в некоторых случаях код должен пройти вверх по дереву из целевой таблицы / строки, чтобы узнать, кому он принадлежал. Для этого я рекомендую настраиваемые запросы, поэтому вам нужно всего лишь один раз обратиться к базе данных, чтобы определить владельца. "Есть ли у компании / пользователя собственная запись X?" И если приложение обрабатывает базу данных вокруг этого запроса, вы всегда можете кэшировать ответ локально. Или добавьте столбец компании / идентификатора пользователя.

Обратите внимание, что добавление столбца id компании не нарушает реляционные свойства базы данных. Это может «нормализовать» это, конечно. Но это только один из компромиссов, которые мы делаем как разработчики, чтобы получить требуемую производительность. Я бы не стал париться, если бы это было лучшее решение, учитывая вашу модель данных.

Что касается отношений «многие ко многим», я бы предположил, что если бы у пользователя был доступ к одному элементу, остальные ссылки, на которые он ссылается, принадлежали одному и тому же пользователю / компании, или это не те вещи, которые этот код изменил бы в данном случае. вызов. Конечно, я не знаю ваше заявление, но по моему опыту это имеет тенденцию быть правдой. Таким образом, должна применяться одна проверка доступа.