Обойти определенный URL-адрес от Akamai, если существуют определенные куки
Я бы хотел, чтобы Akamai не кэшировал определенные URL-адреса, если существует указанный файл cookie (т. Е.), Если пользователь вошел на определенные страницы. Есть ли в любом случае мы можем сделать с Akamai?
3 ответа
Edge Server не проверяет наличие cookie-файлов, прежде чем отправляет запрос на ваш исходный сервер, и я никогда не видел ничего подобного ни в одном из их меню, экранов настроек или документации.
Однако есть несколько способов, которыми я могу придумать, что вы можете получить тот эффект, который, я думаю, вы ищете.
Вы можете указать в настройках конфигурации для соответствующего цифрового свойства, какие пути или URL-адреса вы не хотите кешировать. Если вы говорите о вошедшем в систему пользователе, у вас может быть путь, по которому смогут добраться только они, или вы можете настроить такую вещь на стороне сервера. Например, для онлайн-курса у вас будет
www.course.com/php.htmlчто кто-нибудь может получить в то время как вы могли бы использоватьwww.course.com/student/php-lesson-1.htmlдля актуального вошедшего на содержание уроков. Указывая, что/student/*не будет кэшироваться, это решит.Если вы обслуживаете одни и те же страницы как вошедшим в систему, так и не вошедшим в систему пользователям, и не можете сделать это таким образом, вы можете проверить на стороне сервера, если они вошли в систему, и, если это так, добавить к ссылкам прерыватель кэша, чтобы когда они переходят по ссылке, автоматически добавляется кэш-прерыватель. Вы также можете сделать это на стороне клиента, если хотите, но было бы более безопасно и быстрее сделать это на стороне сервера. Как примечание, это может быть userid-random #. Это позволило бы сохранить его уникальность в сочетании со страницей, чтобы никто другой не запросил его и не получил более раннюю страницу с поврежденным кэшем.
Если ни одно из вышеперечисленного не работает, есть еще один способ, который я могу придумать, который немного нетрадиционен, если не сказать больше, но он сработает. Создайте символически связанный каталог в корневом каталоге вашего документа с другим именем, чтобы вы могли применить первый параметр и освободить его от кэширования. Затем вы проверяете, вошел ли парень в систему, и если да, добавьте дополнительный каталог к ссылкам. С точки зрения акамаев
www.mysite.com/logged-on/page.htmlможет быть освобожден из кэша, гдеwww.mysite.com/content/page.htmlкэшируется На вашем сервере, если/logged-on/символически ссылки на/content/тогда все готово.Когда они входят в систему, вы можете отправить их на поддомен, который настроен как ServerAlias, так что на вашей стороне это то же самое, но на Akamai действуют другие правила обработки кэша.
Хорошей новостью является то, что я делал именно это в прошлом для сайта Top Gear (www.topgear.com/uk). Логика заключается в том, что если присутствует cookie (в данном случае "TGCACHEKEY"), то кеш Akamai должен быть обойден для определенных путей URL. Это в основном отключает кэширование html-страниц Akamai при входе в систему.
Плохая новость заключается в том, что вам нужно, чтобы консультант Akamai внес эти изменения для вас.
Если это не вариант для вас, то предложения Питера все хорошие. Я рассмотрел все это до реализации подхода Top Gear на основе файлов cookie, но, в конце концов, ни один из них не был осуществим.
Помните также, что Akamai по умолчанию удаляет файлы cookie для кэшируемых ресурсов. Это может или не может повлиять на вас в вашей ситуации.
Следуя тому же ответу, что и @llevera, вы можете использовать файлы cookie на CloudFlare без вмешательства инженеров, чтобы внести изменения для вас.
Наличие такого рода файлов cookie для обхода контента - это метод, который со временем становится все более популярным, и даже такие компании, как Magento, используют его для платформы Magento 2.
Но решения сверху остаются в силе, возможно Akamai поддерживает это уже сейчас, мы в 2017 году!