Как добавить простое лицензирование в API при использовании AWS Cloudfront для кэширования запросов - PullRequest
0 голосов
/ 13 июня 2018

У меня есть приложение, развернутое на AWS Elastic Beanstalk , я добавил несколько простых лицензий, чтобы остановить злоупотребление API, пользователь должен передать лицензионный ключ как поле

, т. Е.

search.myapi.com/?license=4ca53b04&query=fred

Если это недопустимо, запрос отклоняется.

Однако до ежемесячных обновлений вышеуказанный запрос всегда будет возвращать одни и те же данные, поэтому я теперь указываю search.myapi.com на AWS CloudFront , тогда, только если запрос не кэшируется, он отправляется на фактический сервер как

direct.myapi.com/?license=4ca53b04&query=fred

Однако проблема в том, что если два пользователя делают один и тот же запрос, они не будут считатьсяТо же самое для Cloudfront, потому что параметр лицензии отличается.Таким образом, кэширование Cloudfront работает только на уровне пользователя, который бесполезен.

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

Возможно, мне нужно что-то перед CloudFront, которое проверяет лицензию, а затем удаляет параметр лицензии, но я не знаю, что это будет?

1 Ответ

0 голосов
/ 14 июня 2018

На ум приходят два возможных.

Первое решение выглядит как хак, но помешает нелицензированным пользователям успешно получать некэшированные ответы на запросы.Если ответ кэшируется, он будет просочиться, но бесплатно с точки зрения ресурсов сервера источника.

Если содержимое не является конфиденциальным , и вы только пытаетесь избежать мелкихкража / раздражение, это может быть жизнеспособным.

Для параметров запроса CloudFront позволяет переслать все, кэшировать в белый список .

Итак, белый список query (и любые другие необходимые поля), но не license.

Результаты для данного запроса:

  • действующая лицензия, кэшМисс: запрос отправляется на источник, источник возвращает ответ, ответ хранится в кеше
  • действительная лицензия, попадание в кэш: ответ отправлен из кэша
  • недействительная лицензия, попадание в кэш: ответ отправлен из кэша
  • недействительная лицензия, отсутствует кэш: ответ отправляется на источник, источник возвращает ошибку, ошибка сохраняется в кэше.

Упс.Последнее условие проблематично, потому что авторизованные пользователи получат кэшированную ошибку, если сделают тот же запрос.

Но мы можем это исправить, если источник возвращает ошибку HTTP для неверного запроса, например 403 Forbidden.

Как я объяснил в Amazon CloudFront Latency CloudFront кэширует ответы с ошибками HTTP, используя разные таймеры (не min / default / max-ttl), по умолчанию t минут.Это значение может быть установлено равным 0 (или другим значениям) для каждого из нескольких отдельных кодов состояния HTTP, например 403. Таким образом, для кода ошибки, возвращаемого вашим источником, установите для параметра Минимальное время кэширования ошибок значение 0 секунд.

К этому моменту проблемное условие кэширования ответов об ошибках и их воспроизведения авторизованным клиентам было решено.

Второй вариант в целом выглядит лучше, но требует большей сложностии, вероятно, стоит чуть больше.

CloudFront имеет функцию, которая связывает его с AWS Lambda, которая называется Lambda @ Edge .Это позволяет анализировать запросы и ответы и манипулировать ими с помощью простых сценариев Javascript, которые выполняются в определенных точках запуска в потоке сигналов CloudFront.

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

Из этого вы можете увидеть, как это может быть полезно.

Триггер Viewer Request может проверять каждый запрос надействительный лицензионный ключ, и отклонить без него.Для этого ему потребуется доступ к способу проверки лицензионных ключей.

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

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

Триггеры Lambda @ Edge запускаются в контейнерах Lambda и, в зависимости от загруженности трафика, наблюдения показывают, что весьма вероятно, что последующие запросы, достигшие того же самого краевого местоположения, будут обрабатываться одним и тем же контейнером.Каждый контейнер обрабатывает только один запрос за раз, но контейнер становится доступным для следующего запроса, как только элемент управления возвращается в CloudFront.Как следствие этого, вы можете кэшировать результаты в памяти в глобальной структуре данных внутри каждого контейнера, значительно сокращая количество раз, когда вам нужно выяснить, действителен ли лицензионный ключ.Функция либо позволяет CloudFront продолжить обработку в обычном режиме, либо активно отклоняет недействительный ключ, генерируя собственный ответ.Один триггер обойдется вам чуть менее $ 1 на миллион запросов, которые он обрабатывает.

Это решение предотвращает фактическую проверку кеша отсутствующими или неавторизованными лицензионными ключами или отправку запросов к источнику.Как и раньше, вы можете настроить белый список строк запроса в настройках поведения кэша CloudFront, чтобы исключить license из белого списка, и изменить минимальный TTL кэширования ошибок, чтобы гарантировать, что ошибки не будут кэшироваться, даже если эти ошибки никогда не возникнут.

...