Конфликты между кэшированием и SignedURL (делая контент закрытым) - PullRequest
0 голосов
/ 06 октября 2019

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

Сначала я подумал о подписанной функции S3 SUR. Но затем я понял, что не могу сделать работу кэширования, которая выполняется моим поставщиком CDN и моей клиентской стороной, потому что кэширование выполняется на основе URL-адресов.

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

Я перешел на CloudFlare и обнаружил сообщение о том, что им разрешено использовать специальные ключи кэша вместо кэширования на основе URL. (https://blog.bigbinary.com/2019/01/29/how-to-cache-all-files-using-cloudflare-worker-along-with-hmac-authentication.html) Я не знаю, сколько стоит корпоративный план, но бизнес-план на один уровень ниже составляет 200 долларов в месяц.

Бизнес-план позволяет пользователям CloudFlare использовать аутентификацию токена. (https://blog.cloudflare.com/token-authentication-for-cached-private-content-and-apis/) (https://support.cloudflare.com/hc/en-us/articles/115001376488-How-to-setup-Token-Authentication-) Я мог бы использовать эту аутентификацию токена, сделав мои изображения, включая токены, следующим образом:

<Image source={{
          uri: 'https:image_url.jpeg',
          method: 'GET',
          headers: {
            Authorization: token
          },
     }}
     style={{width: width, height: height}}
/>

Еще одна вещь, которую я мог бы сделать, это получить подписанные URL-адреса из CloudFrontне на уровне S3. Таким образом, я могу настроить свой CDN (в данном случае CloudFront) для правильного кэширования моих изображений S3, а затем создавать уникальные URL-адреса для каждой фотографии. Но мне все равно приходится иметь дело с кэшированием на стороне клиента в качестве клиентов URL-адресов. См. всегда разные. Я должен сохранить URL-адреса в Localstorage, как это предложено (https://stackoverflow.com/a/37817503) ответ. Или я могу использовать библиотеку кэширования React Native. Однако я разверну это приложение в Интернете, а также в мобильной среде,поэтому я не уверен, будет ли для меня целесообразным использование таких библиотек кэширования.

Подводя итог, подписанные URL-адреса вызывают двухуровневые проблемы. не работает с кешированием CDN. Это не работает с кэшированием клиента. Я должен использовать подписанные URL-адреса CloudFront и иметь дело с кэшированием на стороне клиента (что не идеально), или я должен использовать токен-метод CloudFlare. Пропускная способность бесплатна для CloudFlare, хотя бизнес-план стоит 200 долларов. Так будет ли это того стоить, если я предположу, что мое приложение хорошо масштабируется?

Что мешает мне использовать CloudFlare, это то, что оно плохо документировано. Мне приходится иметь дело с работниками в CloudFlare, но единственный документ, который я нашел о том, как использовать подписанный URL на уровне CDN, - это (https://developers.cloudflare.com/workers/about/tips/signing-requests/#verifying-signed-requests) И единственный, который я нашел о том, как получить доступ к частному ведру S3 из CloudFlareэто (https://help.backblaze.com/hc/en-us/articles/360010017893-How-to-allow-Cloudflare-to-fetch-content-from-a-Backblaze-B2-private-bucket)

Является ли CloudFlare с методом проверки токенов правильным способом для меня? Есть ли другой способ, который я могу попробовать?

...