Статический хостинг AWS S3: правила маршрутизации не работают с облачным интерфейсом

Я использую статический веб-хостинг AWS S3 для своего приложения VueJs SPA. У меня есть правила маршрутизации в S3, и они отлично работают, когда я обращаюсь к нему с помощью статического URL-адреса хостинга S3. Но я также настроил CloudFront для использования с моим личным доменом. Поскольку одностраничные приложения необходимо маршрутизировать через index.html, я настроил пользовательскую страницу ошибок в облачном интерфейсе для перенаправления ошибок 404 в index.html. Итак, теперь правила маршрутизации, которые я установил в S3, больше не работают.

Как лучше всего заставить правила маршрутизации S3 работать вместе с настройкой настраиваемой страницы ошибок CloudFront для SPA?

Вы этого не сделаете. Вы просто настраиваете 404 и 403 в CloudFront для перехода к index.html с 200, чтобы все маршруты отправлялись туда, и вы обрабатывали это. Игнорировать маршрутизацию S3.

Ohgodwhy 31.10.2018 02:36

Если он отлично работает с конечной точкой корзины, зачем вам включать пользовательский взлом, отменяющий ошибку, в CloudFront? Также убедитесь, что вы не сделали неверно указать конечную точку сегмента.

Michael - sqlbot 31.10.2018 09:12
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
1
2
2 288
1

Ответы 1

Я думаю, что немного опаздываю, но все равно здесь,

По-видимому, вы не можете этого сделать, если вы используете конечные точки S3 REST_API (example-bucket.s3.amazonaws.com) в качестве источника для вашего распространения CloudFront, вы должны использовать URL-адрес веб-сайта S3, предоставленный S3, в качестве источника (пример- bucket.s3-website- [регион] .amazonaws.com). Кроме того, объекты должны быть общедоступными, вы не можете заблокировать ведро для распространения по политике происхождения.

Так,

  • Объекты должны быть общедоступными.
  • Должна быть включена опция веб-сайта корзины S3.
  • Источник распространения должен исходить от URL-адреса веб-сайта S3, а не с конечной точки остальных API.

Обновлено:

Я ошибался, на самом деле вы можете сделать это и с конечной точкой REST_API, вам нужно только создать Пользовательский ответ при ошибке внутри вашего дистрибутива CloudFront, вероятно, только для кодов ошибок 404 и 403, установите для параметра «Настроить ответ на ошибку» значение «да», Путь к странице ответа в «/index.html» и Код ответа HTTP на «200». Вы можете найти эту опцию внутри своего дистрибутива и на вкладке страниц ошибок, если вы используете консоль.

Это также работает для приложения Blazor Webassembly. У меня был аналогичный случай, когда меня перенаправляли обратно на URL-адрес облачного интерфейса от провайдера openidconnect. Получал общий доступ запрещен от s3, потому что он искал полный URL-адрес в качестве пути, а не позволял SPA анализировать его как маршрут. Как только я добавил правило, как описано здесь, оно перенаправляло обратный вызов в SPA для анализа, и все работало отлично.

Derek 19.02.2021 19:29

Другие вопросы по теме