Когда я перехожу на web.mysite.com, статический SPA, размещенный на S3, он имеет iframe с src, равным mysite.com/some/path, который является приложением Spring Boot MVC в Elastic Beanstalk. Оба находятся за дистрибутивами Cloudfront для HTTPS. Этот путь обрабатывается в приложении с помощью специального распознавателя ресурсов. Он успешно загружается, но внутри содержимого iframe есть тег сценария для поиска mysite.com/some/path/thatsdifferent, обработанный тем же распознавателем.
Этот второй запрос завершается неудачно с 403, и я не могу определить, почему. Навигация к неудачному mysite.com/some/path/thatsdifferent непосредственно в моем браузере или использование почтальона завершается успешно со статусом 200. Сервер настроен на разрешение запросов от web.mysite.com через конфигурацию CORS (и нет сообщений об ошибках, связанных с CORS), а Spring Security настроен на permitAll любые запросы на /some/** независимо от аутентификации. За заголовком x-cache: Error from cloudfront нет тела ответа или сообщения об ошибке.
Если перейти к the-beanstalk-env-url.com/some/path, он загружает html, а затем успешно загружает содержимое из the-beanstalk-env-url.com/some/path/thatsdifferent.
Запросы на несколько разных, но похожих путей выполняются успешно. Переход к пути, который определенно не существует на 100%, возвращает 404.
Журналы сервера показывают, что запрос успешно обрабатывается, и Cloudfront возвращает разумные ответы клиенту. Просмотр журналов Cloudfront просто сообщает отчет 403. Без какой-либо дополнительной информации.
Почти 100% статей об ошибках Cloudfront 403 и вопросы касаются S3, который не относится к той части, которая дает сбой.
Изменение разрешенных методов распределения Cloudfront с GET, HEAD на GET, HEAD, OPTIONS приводит к тому, что запросы непосредственно к mysite.com/some/path/thatsdifferent начинают сбой с invalid CORS request, это было исправлено путем внесения в белый список заголовков Accept, Authorization, Host, Origin и Referer. Это не исправило основную ошибку.
Настройка ведения журнала для org.springframework.security не регистрирует дополнительную информацию при возникновении сбойного запроса, моя конфигурация безопасности приложения не является причиной ошибки.
После замены Cloudfront балансировщиком нагрузки в моей среде в Route 53 сценарий работает как положено, поэтому проблема определенно в Cloudfront.