Как мне обеспечить доступ к данным в моем новом API?

Question

Я занимаюсь разработкой API, и я хотел бы задать несколько вопросов о том, как наилучшим образом защитить доступ к данным.

Предположим, API разрешает доступ артистам. У исполнителей есть альбомы, в которых есть песни.

Пользователи API имеют доступ к подмножеству всех художников. Если пользователь вызывает API с запросом какого-либо исполнителя, легко проверить, разрешено ли ему это делать.

Далее, если пользователь запрашивает альбом, API должен проверить, принадлежит ли альбом исполнителю, к которому ему разрешен доступ. Доступ к песням означает, что API должен проверить альбом, а затем исполнителя, чтобы получить доступ.

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

Чтобы обойти это, я предложил следующий подход.

API предоставляет пользователю ссылку на объект, например объект художника. Затем пользователь может запросить этот объект исполнителя для альбомов, который возвращает объект списка. Объект списка может быть пройден, и из него могут быть получены объекты альбома. Аналогично, из объекта альбома может быть получен объект списка песен, и из этого отдельные объекты песни.

Поскольку API доверяет объекту Artist, он также доверяет любым объектам (в данном случае альбомам), которые пользователь получает от него, без дальнейших проверок. И так далее для всех других объектов. Поэтому я делегирую безопасность / доверие объектам по цепочке.

Я хотел бы спросить вас, что вы об этом думаете, что хорошего или плохого в этом, и, конечно же, как бы вы решили эту «проблему».

Во-вторых, как бы вы подошли к этому, если бы API был RESTful? Мой подход кажется менее применимым в этом случае.

Answer 1

Это реальная программа или, скорее, образец для иллюстрации вопроса? Потому что неясно, почему вы ограничиваете доступ к исполнителям и альбомам, а не только к отдельным медиафайлам или даже трекам.

Я не думаю, что объединения должны стоить вам так дорого, любая полуумная система БД сделает их достаточно дешево, если вы делаете достаточно простые критерии, подходящие для нескольких таблиц.

ИМХО, проблема с использованием столь большого количества логики безопасности в запросах заключается в том, что она ограничивает вашу способность обрабатывать более сложные проблемы DRM, которые обязательно будут связаны. Например, что, если альбом представляет собой коллекцию от нескольких художников? Что, если альбом содержит трек, который является дуэтом, и у меня есть доступ только к одному исполнителю? и т. д. и т. д.

Я считаю, что в таких ситуациях удобная модель программирования с разумным исключением гораздо важнее, чем выполнение отдельных запросов, которые вы всегда можете кэшировать или оптимизировать в будущем. То, что вы пытаетесь сделать с запросами, звучит как преждевременная оптимизация.

Создайте свою модель программирования максимально гибкой. Определите разумный смысл расширений, затем работайте над реализацией базы данных и оптимизируйте запросы после профилирования реальной системы.

Answer 2

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

Такое решение хорошо масштабируется, вы можете добавить больше слоев, не увеличивая время, необходимое для проверки безопасности. Добавление нового ресурса также не требует дополнительного штрафа, кроме вставки еще одного поля (на основе родительского поля ресурса). И, конечно, это решение поддерживает особые ситуации, описанные выше (например, более одного исполнителя и т. Д.).

Такое решение также не нарушает архитектуру RESTful.

И тот факт, что каждый ресурс содержит свой собственный дескриптор безопасности, обобщает права доступа к ресурсу, позволяя в будущем реализовать совершенно другую политику безопасности (например, сделать разрешения доступа более детализированными на основе альбомов, а не только исполнителей). .

Answer 3

Возможно, что объединение выполняется намного быстрее, чем ваш объектный подход (хотя это более элегантно). С объединениями у вас есть только один запрос БД, с объектами у вас много. (Или вы должны извлечь все «возможные» данные в первом запросе, что также может замедлить процесс)

Я рекомендую делать соединения. Если есть проблема с sql, вы можете спросить у stackoverflow: D

Другая идея:

Если вы делаете URL-адреса вроде "/ beatles / whitealbum / happinesisawarmgun"

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