Использование предварительно подписанных URL-адресов в (например, Angular) SPA приводит к увеличению кеша браузера.

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

Урезанная наша установка включает в себя

  • сервер хранения
  • API-сервер
  • клиент (угловой SPA, работающий в браузере)

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

Процесс загрузки (упрощенный):

  • клиент отправляет API: эй, я хочу загрузить это
  • API выполняет авторизацию и проверку, выполняет некоторые действия с базой данных и возвращает предварительно подписанный URL-адрес.
  • клиент загружает напрямую на сервер хранения

Все идет нормально. Большой проблемой является поток «загрузки».

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

Это прекрасно работает, но увеличивает кеш браузера до нескольких ГБ ОЗУ.

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


Пока это кажется правильным поведением на стороне браузера (другой URL-адрес равен другому изображению).

Пока это кажется правильным поведением на стороне API (новый вызов вернет новое время жизни).


Есть ли какие-либо предполагаемые способы, как справиться с этим?

Сами потоки неверны?

Любые способы решить эту проблему, кроме реализации централизованного предварительно подписанного кэша URL-адресов при запуске нескольких экземпляров API?


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


person monty    schedule 15.02.2019    source источник
comment
Не могли бы вы дать каждому изображению статический идентификатор и использовать идентификатор изображения, а не URL-адрес, для отслеживания его в кеше браузера? Если все работает правильно — как кажется — вам нужно будет найти способ «обмануть» кеш браузера, чтобы он игнорировал уникальные URL-адреса в пользу какого-то другого идентификатора.   -  person Josh Harkema    schedule 15.02.2019
comment
Хм. Мы используем предварительно подписанный URL-адрес для получения в качестве src в стандартном html-теге img (насколько я знаю, я являюсь бэкэнд-парнем). Кэширование осуществляется самими браузерами. Не знаю, как и можно ли повлиять на поведение кэширования Chrome, Firefox или любого другого браузера.   -  person monty    schedule 15.02.2019


Ответы (2)


При каждом запросе предварительно подписанного ресурса в вашем текущем потоке браузер/клиент делает новый запрос к S3.

Следовательно, преимущество кэша браузера не используется, и его можно сделать без указания дополнительных заголовков ответов для управления политикой кэширования в клиенте при создании предварительно подписанных URL-адресов. Заголовок ответа Cache-Control можно установить в заголовках ответа для предварительно подписанного запроса на no-cache. 1

Я предлагаю лучший вариант: предварительно подписанные URL-адреса должны иметь срок действия от 5 до 15 минут и установить Cache-Control в заголовках ответа предварительно подписанного URL-адреса на max-age:<expire-time-in-secs>.

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

person Oluwafemi Sule    schedule 24.02.2019
comment
Как я вижу сейчас, я мог бы установить управление кешем только для ответа API (возвращая список объектов в формате json, каждый из которых содержит несколько предварительно подписанных URL-адресов). Но не для предварительно подписанных URL-адресов каждый. - person monty; 26.02.2019

Другим решением является использование presignedurl API из minio-js https://docs.minio.io/docs/javascript-client-api-reference.html#presignedUrl

Пожалуйста, посмотрите на https://github.com/minio/minio-js/issues/724 и https://github.com/minio/minio-js/pull/728 для получения дополнительной информации.

person r1j1m1n1    schedule 25.02.2019
comment
X-Amz-Date из указанной проблемы может быть решением, но я не понимаю, как использовать его в мини-клиенте С#. - person monty; 26.02.2019
comment
Вы можете отправить запрос функции на github.com/minio/minio-dotnet/issues/new. - person r1j1m1n1; 27.02.2019