Я использую статический веб-хостинг AWS S3 для своего приложения VueJs SPA. У меня есть правила маршрутизации в S3, и они отлично работают, когда я обращаюсь к нему с помощью статического URL-адреса хостинга S3. Но я также настроил CloudFront для использования с моим личным доменом. Поскольку одностраничные приложения необходимо маршрутизировать через index.html, я настроил пользовательскую страницу ошибок в облачном интерфейсе для перенаправления ошибок 404 в index.html. Итак, теперь правила маршрутизации, которые я установил в S3, больше не работают.
Как лучше всего заставить правила маршрутизации S3 работать вместе с настройкой настраиваемой страницы ошибок CloudFront для SPA?
Если он отлично работает с конечной точкой корзины, зачем вам включать пользовательский взлом, отменяющий ошибку, в CloudFront? Также убедитесь, что вы не сделали неверно указать конечную точку сегмента.
Я думаю, что немного опаздываю, но все равно здесь,
По-видимому, вы не можете этого сделать, если вы используете конечные точки S3 REST_API (example-bucket.s3.amazonaws.com) в качестве источника для вашего распространения CloudFront, вы должны использовать URL-адрес веб-сайта S3, предоставленный S3, в качестве источника (пример- bucket.s3-website- [регион] .amazonaws.com). Кроме того, объекты должны быть общедоступными, вы не можете заблокировать ведро для распространения по политике происхождения.
Так,
Обновлено:
Я ошибался, на самом деле вы можете сделать это и с конечной точкой REST_API, вам нужно только создать Пользовательский ответ при ошибке внутри вашего дистрибутива CloudFront, вероятно, только для кодов ошибок 404 и 403, установите для параметра «Настроить ответ на ошибку» значение «да», Путь к странице ответа в «/index.html» и Код ответа HTTP на «200». Вы можете найти эту опцию внутри своего дистрибутива и на вкладке страниц ошибок, если вы используете консоль.
Это также работает для приложения Blazor Webassembly. У меня был аналогичный случай, когда меня перенаправляли обратно на URL-адрес облачного интерфейса от провайдера openidconnect. Получал общий доступ запрещен от s3, потому что он искал полный URL-адрес в качестве пути, а не позволял SPA анализировать его как маршрут. Как только я добавил правило, как описано здесь, оно перенаправляло обратный вызов в SPA для анализа, и все работало отлично.
Вы этого не сделаете. Вы просто настраиваете
404
и403
в CloudFront для перехода кindex.html
с200
, чтобы все маршруты отправлялись туда, и вы обрабатывали это. Игнорировать маршрутизацию S3.