Блог

Мы разработали приложение Laravel, которое работает нормально. Как только мы включили CDN (Amazon Cloudfront), он перестал работать со всеми формами. Везде, где есть отправленные формы, такие как Login, Contact us и т.д. Это вообще не работает.

Мы определили, что для приложений Laravel нам необходимо внести некоторые изменения, мы ищем помощи у некоторых экспертов, которые успешно настроили приложение Laravel с CDN.

Мы используем версии PHP 7.1.20 и Laravel 5.4.

Я думаю, вы неправильно понимаете использование CloudFront в качестве CDN или любого другого CDN, если уж на то пошло.

Вы не размещаете его перед всем своим сайтом — он не обслуживает ваш сайт. Он служит кешем для ваших статических ресурсов: ваших медиа, таблиц стилей и скриптов. Все остальное по-прежнему подается непосредственно из вашего PHP-приложения.

Вы можете установить ASSET_URL переменную среды для своего приложения, и Laravel будет использовать ее, чтобы указывать на ваши ресурсы, когда вы используете помощники asset() или mix() .

Вопреки общепринятому ответу, вы можете, и часто вам следует, поместить CloudFront перед вашим приложением, а не только перед статическими файлами.

Чтобы уточнить, это настройка, о которой я говорю:

 example.com -> CDN -> origin  (ALB, API Gateway, S3 ...)
  

Зачем вам это делать?

1. Причины производительности

1.1 Завершение работы TLS

Вы можете использовать CloudFront для завершения работы TLS, что означает, что ваши пользователи установят безопасное соединение с CloudFront, а затем CloudFront будет взаимодействовать с источником по обычному HTTP.

Как это может помочь? Вместо того, чтобы ваши австралийские пользователи выполняли 3-стороннее рукопожатие с вашим сервером в Германии, они будут делать это с Cloudfront closes PoP, вероятно, в Мелберне. Вы можете видеть, как это снижает задержку. Вам может быть интересно, можно ли передавать данные по обычному HTTP из CloudFront в origin. AWS по-прежнему будет шифровать ваши данные:

Все данные, передаваемые через регионы AWS по глобальной сети AWS, автоматически шифруются на физическом уровне, прежде чем покинуть защищенные объекты AWS.

Они просто делают это на первом уровне OSI, вместо 4, где происходит TLS. Этого достаточно для вас? Если вы не имеете дело с регуляторами или высокочувствительными данными, вероятно, да. Если меры безопасности AWS не срабатывают и кто-то может подделать трафик внутри центра обработки данных AWS — вы, вероятно, не являетесь целью злоумышленника.

1.2 Повторное использование соединения из PoP в Origin

Цитата из Cloudfront FAQ:

Для файлов, не кэшированных в периферийных расположениях и региональных пограничных кэшах, Amazon CloudFront поддерживает постоянные соединения с вашими исходными серверами, чтобы эти файлы можно было извлекать с исходных серверов как можно быстрее.

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

1.3 Использование AWS Backbone

Используйте оптимизированную глобальную сеть AWS для связи от PoP к origin вместо того, чтобы использовать медленный Интернет. Документы AWS

2. Соображения безопасности

Cloudfront (или другие поставщики CDN, такие как Cloudflare) может помочь вам обработать некоторые запросы на DDOS-атаки и защитить вас, особенно если вы включите AWS WAF и AWS Shield Advanced.

Краткие сведения

Вы можете воспользоваться Cloudfront даже для маршрутов / файлов, которые нельзя кэшировать. Моя настройка кеширования заключается в следующем. Я кэширую /img/* , /css/* и /js/* маршруты, а все остальные я просто проксирую к источнику через HTTP.

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

Пожалуйста, обратите внимание на уменьшение задержки SSL / TLS. Время отклика — это всего лишь среднее значение по всему миру. Увеличение производительности выше в более удаленных местах. Например, мы снизили задержку из Sydney с 1,3 секунды до 0,6 с для того же запроса, просто установив Cloudfront перед ним!

Чтобы ответить на ваш вопрос, ASSET_URL и APP_URL это одно и то же, мы указываем на домен для распространения CDN и немного играем с политиками кэширования.

Вы можете настроить свой дистрибутив Cloudfront на обслуживание 2 origins. Один из них — это ваши статические ресурсы внутри корзины S3, а другой источник — ваш ELB или EC2, который обрабатывает ваше приложение Laravel. Для того, чтобы это сработало, вы должны переслать соответствующие файлы cookie, заголовки и разрешить требуемые методы вашему Laravel origin.

Это выглядит следующим образом https://aws.amazon.com/blogs/aws/amazon-cloudfront-support-for-custom-origins /

После повторного прочтения вашего вопроса кажется, что вы уже настроили пользовательский источник и, возможно, вы просто не пересылаете XSRF-ТОКЕН. Если Laravel отвечает 419, это, скорее всего, так. Попробуйте также внести этот токен в белый список и токен сеанса.