Доступ пользователя, прошедшего аутентификацию AWS S3, с использованием предварительно назначенных URL-адресов?

Я хотел бы разместить файлы в закрытом хранилище AWS S3, к которому могут обращаться только пользователи, прошедшие проверку подлинности в моем веб-приложении. Ссылки на эти загрузки файлов должны быть статическими.

Простой метод прокси:

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

Метод предопределенного URL-адреса прокси:

Однако вместо того, чтобы реализовывать прокси для доступа к файлам, мне было интересно, могу ли я использовать вместо этого заранее назначенные URL-адреса?

https://docs.aws.amazon.com/AmazonS3/latest/dev/ShareObjectPreSignedURL.html

В этом случае роль прокси-сервера заключается в том, чтобы просто вернуть предварительно назначенный URL-адрес пользователю, а не фактическую полезную нагрузку файла из S3. Затем конечный пользователь может использовать этот заранее заданный URL-адрес для загрузки файла непосредственно из S3. Я не совсем понимаю, как этот поток управляется в браузере, и я предполагаю, что мне нужно написать JavaScript для следующего:

  1. Запрос предварительно назначенного URL-адреса от прокси-службы
  2. Ждать ответа
  3. Используйте предварительно назначенный URL-адрес, указанный в ответе (предварительно назначенный URL-адрес), чтобы загрузить фактический файл.

Я на правильном пути здесь?

Источник

2 ответа

Решение

Просто верните перенаправление 307 с вашего сервера на предварительно назначенный URL. Например, клиент запрашивает:

GET /the/file HTTP/1.1

И сервер генерирует заданный URL-адрес и отвечает:

HTTP/1.1 307 Temporary Redirect
Location: https://s3.aws..../the/file?...
Источник

Это правильный подход.

Остерегайтесь истекающих учетных данных. Подписанные URL будут полезны в течение меньшего времени, пока не истечет срок действия учетных данных, используемых для их подписания, или истечет время их истечения (которое вы контролируете в определенных пределах). В случае, если вы уже используете временные учетные данные (что очень хорошо!), Вы можете явно использовать AssumeRole для контроля времени истечения (вы можете взять роль от роли, чтобы получить новые временные учетные данные с новым ограничением времени),

Есть и другой вариант: Amazon Cognito. Это может сократить разрыв между учетными записями пользователей, а затем напрямую выдавать краткосрочные учетные данные для каждого пользователя в браузерные среды ваших пользователей. Затем они могут делать вызовы API для S3 со своими собственными учетными данными. Это имеет некоторое преимущество (вы можете лучше выразить права пользователей в их профиле, а не проверять их самостоятельно, прежде чем они сгенерируют URL-адреса) и некоторую сложность (могу ли я сделать вашу учетную запись с помощью своих пользовательских кредитов, или вы контролируете, какие API я могу назвать? Привилегия действительно имеет значение, когда IAM - ваш единственный уровень авторизации.) С другой стороны, вызовы IAM бесплатны, и вы не платите за серверы для их размещения, так что это звучит экономически выгодно, если вы используете федеративную идентификацию - пулы пользователей, а не так много.

Источник
Другие вопросы по тегам