AWS CloudFront — бесценный инструмент для любого приложения, использующего мультимедиа, работающие по всему миру. Это CDN — сеть доставки контента, которая позволит пользователям получать изображения из периферийных местоположений, предоставляемых CloudFront. (например, если я нахожусь в Словении, я буду получать их из периферийного местоположения во Франкфурте).

Мы сосредоточимся на обслуживании частных изображений, размещенных на S3, из CloudFront. Вам, безусловно, также следует использовать CloudFront для статических файлов, таких как HTML и Javascript, но они обычно общедоступны и не требуют аутентификации.

Цель этой статьи — сравнить два варианта обслуживания частных носителей за пределами AWS CloudFront:

  • подписанные URL-адреса
  • подписанные файлы cookie

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

Печенье

С помощью файлов cookie вы будете добавлять следующие три файла cookie к своим запросам изображений при использовании настраиваемых политик (и вам следует использовать настраиваемые политики, поскольку они наиболее универсальны и их действительно несложно создать):

  • CloudFront-Key-Pair-Id — открытый ключ, используемый для пения
  • CloudFront-Signature — подпись
  • CloudFront-Policy — управляет пространством имен, для которого предназначен файл cookie (например, /uploads/test/*).

Пользовательская политика будет выглядеть примерно так:

{
  Statement: [
    {
      Resource: '/uploads/*',
      Condition: {
        DateLessThan: {
          'AWS:EpochTime': 1095292800,
        },
      },
    },
  ],
}

Один набор файлов cookie для пространства имен будет содержать три вышеуказанных файла cookie, которые вам нужно будет добавить к вашим запросам изображений. Как правило, вы должны использовать тот же Путь для файла cookie в заголовке set-cookie, что и Ресурс в политике.

Подписанные URL

С подписанными URL-адресами вы обычно генерируете следующий формат URL-адресов:

В Javascript вы должны использовать пакет @aws-sdk/cloudfront-signer:

для обоих вышеперечисленных вариантов.

Когда использовать тот или иной

В исходной документации AWS говорится:

Используйте подписанные URL-адреса в следующих случаях:

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

- Ваши пользователи используют клиент (например, пользовательский HTTP-клиент), который не поддерживает файлы cookie.

Используйте подписанные файлы cookie в следующих случаях:

- Вы хотите предоставить доступ к нескольким файлам с ограниченным доступом, например, ко всем файлам для видео в формате HLS или ко всем файлам в личном кабинете на сайте.

- Вы не хотите менять свои текущие URL-адреса.

Таким образом, просто прочитав вышеизложенное, становится ясно, что у нас будет гораздо меньше проблем и больше вариантов использования при использовании подписанных файлов cookie.

Так почему же так много приложений в наши дни все еще используют подписанные URL-адреса? Мы не сможем ответить на этот вопрос сегодня, но давайте рассмотрим некоторые из причин, по которым я обнаружил, что использую файлы cookie вместо подписанных URL-адресов для обслуживания мультимедиа за CloudFront.

Причины использования подписанных файлов cookie вместо подписанных URL-адресов

  • Кэш на стороне клиента по умолчанию часто использует URL-адреса для управления кэшированием. Использование чего-либо, кроме URL-адресов, потребуется дополнительно настроить, и в большинстве случаев это окажется хуже, чем использование постоянных URL-адресов.
  • Кэш CloudFront по умолчанию также использует URL-адрес для кэширования мультимедиа. Если бы вместо этого мы использовали подписанные URL-адреса, нам нужно было бы каким-то образом установить фиксированное время, когда мы сбрасываем время подписания (например, только один раз в 30 минут), потому что после изменения URL-адреса кэш уже в CloudFront становится недействительным. . У нас есть несколько вариантов изменения ключа кэша, но на самом деле лучше использовать решение, которое позволит нам кэшировать мультимедиа в течение очень длительного времени с различными сроками действия аутентификации по умолчанию.
  • Как уже указано в оригинальной документации AWS, метод cookie незаменим при использовании видеопотоков (HLS, MPEG-DASH, …). Потоки обычно имеют файл списка воспроизведения, остальной контент будет находиться в других файлах. В этом случае подписанные URL-адреса не подходят.
  • Разрешения в пространстве имен — с помощью одного файла cookie вы можете разрешить доступ к любому конкретному префиксу пути в S3, что дает возможность иметь очень подробные разрешения (например, /uploads/test/*) или вообще не разрешать, а просто разрешить доступ к /, если хотите. Если вы правильно настроите пути для файлов cookie (не только в политике, но и в параметре Path файла cookie, который вы устанавливаете с помощью set-cookie), у вас будет бесшовная опыт в браузере и не нужно будет ничего делать на клиенте.
  • Наличие одних и тех же URL навсегда. В документации AWS это уже указано, но это не просто косметическое средство, это позволяет пользователям, например. добавлять в закладки медиафайлы до тех пор, пока вы установили действительный файл cookie с пространством имен. Если вы создадите файл cookie повторно, изображение снова будет доступно и по-прежнему будет доступно — этого нельзя сказать о восстановлении подписанных URL-адресов — после истечения срока действия подписанного URL-адреса он истекает навсегда. Это также гарантирует, что пользователи не смогут делиться URL-адресами мультимедиа с другими пользователями, не прошедшими проверку подлинности, что делает процесс более безопасным.

Общие вопросы / опасения по поводу использования подписанных файлов cookie

Будут ли у меня проблемы с использованием подписанных файлов cookie в мобильном приложении?

Нисколько. Это будет немного сложнее, чем делать это в Интернете, но у вас не должно возникнуть проблем с добавлением правильных файлов cookie к правильным запросам мультимедиа.

Потенциальные проблемы

Потенциальная проблема, которую я обнаружил, заключается в том, что при использовании очень мелкозернистой аутентификации на основе пространства имен вы можете столкнуться с проблемами размера заголовка, но только если на самом деле вы используете set-cookie для установки файлов cookie на стороне клиента. Но мы говорим только о действительно большом количестве файлов cookie (например, более 30 наборов файлов cookie CloudFront для одного запроса).

Различия в реализации на стороне сервера

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

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