Я довольно новичок в AWS и сейчас прохожу несколько различных учебных курсов, и одна из интересных вещей, на которые я наткнулся, — это возможность добавлять пользовательские заголовки в Cloudfront. Тем не менее, я не могу понять (или найти простую для понимания документацию) о том, как использовать / использовать возможности, которые предлагает эта функция.
Может кто-нибудь, пожалуйста, дайте мне знать, как:
Если это имеет значение, я программирую на PHP. Будем весьма благодарны за любые объяснения, примеры кода или ссылки на полезную документацию. Спасибо за помощь.
Как получить доступ к заголовкам, которые я установил?
«Вы» пользователь браузера / скручивания не может их видеть. Они являются частными между CloudFront и исходным сервером, отправленным с запросом.
Вы можете получить к ним доступ с вашего PHP-кода сервера с помощью getallheaders()
.
Я запутался, как использовать эти заголовки
То, что они позволяют вам делать, это одна из двух вещей:
если в запрос приходит соответствующий заголовок, и он будет отправлен источнику, но вы не хотите, чтобы он отправлялся как полученный, замените его новым значением
если в запросе не найден соответствующий заголовок, добавьте его перед отправкой на исходный сервер.
Но если вы не знаете, что с ними делать, они могут вам не понадобиться.
Некоторые потенциальные приложения:
Если вы хотите использовать подписанные URL-адреса CloudFront или подписанные куки-файлы, вы можете добавить заголовок с секретным значением, которое подтверждает ваш веб-сервер, что запрос поступил от CloudFront, а именно от ваш Распределение CloudFront, потому что значение совпадает. Ранее ваш исходный сервер должен был быть общедоступным, потому что не было никакого способа проверить, что запросы поступили (и были авторизованы) CloudFront — стандартные заголовки могут быть подделаны кем угодно, даже если вы проверили IP-адрес входящего запрос, вы можете доказать, что это был «какой-то» дистрибутив CloudFront, но не ваш Распределение CloudFront. (Злоумышленник может настроить дистрибутив CloudFront и получить доступ к вашему контенту, если вы реализовали наивный сценарий доверия, подобный этому). Поскольку заголовки и их значения неизвестны / не видны браузеру, вы можете проверить наличие заголовка с ожидаемым значением, используя те же механизмы в вашем коде, которые вы использовали бы для чтения любого другого заголовка входящего запроса. Это также может быть использовано, если вы хотите отклонить запросы, которые не поступили через CloudFront по какой-либо другой причине, кроме проверки подлинности и контроля доступа к защищенному контенту. Увидеть http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/forward-custom-headers.html#forward-custom-headers-restrict-access.
Вы можете использовать их для изменения заголовков CORS на пути к источнику. Увидеть http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/header-caching.html#header-caching-web-cors
Вы можете использовать их для отслеживания того, через какой дистрибутив CloudFront поступил запрос, для целей выставления счетов, если у вас было несколько дистрибутивов CloudFront, направленных на один и тот же исходный сервер.
Вы можете использовать их, чтобы компенсировать какое-то ограничение на сервере-источнике, где необходимо по какой-то причине видеть определенный заголовок, но вы не хотите на самом деле пересылать этот заголовок, так как это повредит коэффициенту попадания в кэш. — CloudFront кэширует ответы против все запрос отправляется источнику, включая путь, перенаправленные заголовки (если включено), строку запроса (если включена) и / или файлы cookie (если включена). Он будет обслуживать запрос из кэша, только если запрос, который он направит источнику, точно совпадает с запросом, который он отправил, чтобы получить ответ, который он кэшировал (и, таким образом, CloudFront может кэшировать несколько вариантов одного и того же ресурса на основе параметров запроса что вы позволяете быть переданы через). Причина этого заключается в том, что кэш-память обязана не делать предположений о том, как сервер может изменять ответ в зависимости от различных параметров запроса. Если два запроса не являются семантически эквивалентными, их нельзя считать эквивалентными для целей кэширования.
Других решений пока нет …