Облачный CDN подписанный URL VS Cloud Storage подписанный URL? - PullRequest
Новая
       12

Облачный CDN подписанный URL VS Cloud Storage подписанный URL?

1 голос
/ 08 июля 2019

Облачное хранилище с подписанным URL-адресом: https://cloud.google.com/storage/docs/access-control/signed-urls

Облачный CDN, подписанный URL-документ: https://cloud.google.com/cdn/docs/using-signed-urls

Какая разница между ними? Я запутался, какой из них я должен использовать.

Вот мой случай:

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

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

Я не уверен, что подписанный URL-адрес облачного хранилища является правильным способом. И есть еще одна проблема: я уже сохранил много URL-адресов в своей базе данных с общедоступным URL-адресом объекта облачного хранилища:

https://storage.googleapis.com/ez2on/1536250853638-NN.jpg

Когда клиент (Front-End) пытается получить доступ к этим данным, как мне следует создать подписанный URL для этих старых данных в моем бэкэнде?

Спасибо за ваш совет.

1 Ответ

2 голосов
/ 09 июля 2019

О подписанных URL-адресах, внутри они работают примерно одинаково и генерируют URL более или менее одинаково.Облачное хранилище имеет встроенный CDN, поэтому достаточно использовать подписанный URL-адрес облачного хранилища.

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

Для вашего варианта использования подписанные URL-адреса могут быть не лучшим вариантом, поскольку они имеют ограниченный срок службы, поэтому я предлагаю сделать так, чтобы ваши пользователи входили в ваше приложение с использованием собственной логики приложения, а не IAMили просто получить доступ к приложению без входа в систему (если в нем нет необходимости), а затем заставить приложение обрабатывать запросы пользователей к объектам облачного хранилища через служебную учетную запись (IAM):

  1. user (не Google / Google) входит в систему app (вход в приложение, а не IAM)

  2. user запрашивает объект, представленный app без внутренних данных (путь сегмента и т. д.)

  3. app использует собственную служебную учетную запись (IAM) для запроса объекта на Cloud Storage

  4. Cloud Storage передает объект приложению, приложение пользователю

UЕсли вы воспользуетесь этим обходным путем, вы все равно можете использовать URL-адреса, сохраненные в вашей базе данных.Если вы хотите использовать подписанный URL, вы должны постоянно изменять базу данных, что не является оптимальным.

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

...