Статичний хостинг веб-сайтів S3 прокладе всі шляхи до Index.html


250

Я використовую S3 для розміщення програми javascript, яка буде використовувати HTML5 pushStates. Проблема полягає в тому, що якщо користувач робить закладки будь-якої з URL-адрес, він нічого не вирішить. Що мені потрібно - це можливість приймати всі запити URL та обслуговувати кореневий index.html у своєму відрі S3, а не просто робити повне переспрямування. Тоді мій додаток javascript міг би розібрати URL-адресу та обслуговувати належну сторінку.

Чи є спосіб сказати S3 обслуговувати index.html для всіх запитів URL, а не робити переадресації? Це було б аналогічно налаштуванню apache для обробки всіх вхідних запитів, подаючи єдиний index.html, як у цьому прикладі: https://stackoverflow.com/a/10647521/1762614 . Я дуже хотів би уникати запуску веб-сервера просто для обробки цих маршрутів. Робити все від S3 дуже привабливо.


Ви знайшли рішення для цього?
w2lame

Відповіді:


301

Це дуже легко вирішити без хакерських адрес, за допомогою CloudFront.

  • Створіть відро S3, наприклад: реагуйте
  • Створіть дистрибутив CloudFront за допомогою цих налаштувань:
    • Root Object за замовчуванням : index.html
    • Origin Domain Name : домен ковша S3, наприклад: react.s3.amazonaws.com
  • Перейдіть на вкладку Сторінки помилок , натисніть кнопку Створити власну відповідь про помилку :
    • Код помилки HTTP : 403: заборонено (404: не знайдено, якщо статичний веб-сайт S3)
    • Налаштувати відповідь про помилки : так
    • Шлях сторінки відповідей : /index.html
    • Код відповіді HTTP : 200: Гаразд
    • Клацніть на Створити

8
Дякую. Найкраща відповідь поки що.
jgb

і що не так очевидно, ви зберігаєте розташування, щоб ви могли робити "природну" маршрутизацію.
Лукаш Марек Сільський

5
це працювало як шарм для мене, лише потрібний мені користувацький код помилки 404, а не 403
Jeremy S.

4
Трохи хак, але працює чудово :) Було б добре, якби CloudFront просто дав нам накреслити діапазон шляхів до файлу S3 (без перенаправлення).
Боб

3
Це не працює для мене. Це рішення завжди переспрямовує на домашню сторінку, а не на правильні сторінки ...
Джим

201

Спосіб, який мені вдалося змусити це працювати, полягає в наступному:

У розділі Редагування правил перенаправлення консолі S3 для вашого домену додайте такі правила:

<RoutingRules>
  <RoutingRule>
    <Condition>
      <HttpErrorCodeReturnedEquals>404</HttpErrorCodeReturnedEquals>
    </Condition>
    <Redirect>
      <HostName>yourdomainname.com</HostName>
      <ReplaceKeyPrefixWith>#!/</ReplaceKeyPrefixWith>
    </Redirect>
  </RoutingRule>
</RoutingRules>

Це дозволить перенаправити всі шляхи, в результаті яких 404, не знайдений у вашому кореневому домені, має хеш-баг-версію шляху. Тож http://yourdomainname.com/posts буде переспрямовано на http://yourdomainname.com/#!/posts за умови, що немає файлу в / posts.

Щоб використовувати HTML5 pushStates, нам потрібно взяти цей запит і вручну встановити належний pushState на основі шляху хеш-бангу. Тож додайте це у верхню частину файлу index.html:

<script>
  history.pushState({}, "entry page", location.hash.substring(1));
</script>

Це захоплює хеш і перетворює його в HTML5 pushState. З цього моменту ви можете використовувати pushStates для того, щоб у вашій програмі були шляхи без хеш-бангу.


4
Це рішення чудово працює! Насправді angularjs автоматично виконає pushState історії, якщо налаштовано режим html.
wcandillon

1
Це не вдасться зі старшою версією IE, якщо у ваших URL-адресах включені параметри GET, чи не так? Як ви вирішите це питання?
Клексмонд

3
Дякую! Це добре спрацювало у мене на хребті з невеликим натягом. Я додав у чек для старих браузерів: <script language="javascript"> if (typeof(window.history.pushState) == 'function') { window.history.pushState(null, "Site Name", window.location.hash.substring(2)); } else { window.location.hash = window.location.hash.substring(2); } </script>
AE Grey

10
Успіх із react-routerцим рішенням, використовуючи HTML5 pushStates і<ReplaceKeyPrefixWith>#/</ReplaceKeyPrefixWith>
Фелікс Д.

5
Він не працює в сафарі і є великою проблемою зі стратегією розгортання. Написання невеликого js для переадресації - це свого роду пошарпаний підхід. Також проблема перенаправлення також є проблемою. Я намагаюся зрозуміти, чи є спосіб, щоб усі URL-адреси S3 завжди вказували на index.html.
moha297

129

Існує мало проблем із підходом, заснованим на S3 / Перенаправлення, згаданим іншими.

  1. Перенаправлення Mutliple відбувається, коли шляхи вашого додатка вирішені. Наприклад: www.myapp.com/path/for/test переспрямовується як www.myapp.com/#/path/for/test
  2. У смужці URL з’являється мерехтіння, коли надпис «#» відбувається і зменшується завдяки дії вашої системи SPA.
  3. Сео впливає, тому що: "Ей! Її google змушує руку переспрямувати "
  4. Підтримка Safari для вашої програми - це жеребкування.

Рішення таке:

  1. Переконайтеся, що для вашого веб-сайту налаштовано маршрут індексу. Переважно це index.html
  2. Видаліть правила маршрутизації з конфігурацій S3
  3. Покладіть Cloudfront перед вашим відром S3.
  4. Налаштуйте правила сторінки помилок для екземпляра Cloudfront. У правилах помилок вкажіть:

    • Код помилки HTTP: 404 (і 403 або інші помилки за потребою)
    • Помилка кешування мінімуму TTL (секунд): 0
    • Налаштувати відповідь: Так
    • Шлях сторінки відповідей: /index.html
    • Код відповіді HTTP: 200

      1. Для потреб в SEO + переконайтесь, що ваш index.html не кешує, виконайте наступне:
    • Налаштуйте екземпляр EC2 та встановіть сервер nginx.

    • Призначте публічний ip для свого екземпляра EC2.
    • Створіть ELB, який містить екземпляр EC2, який ви створили як екземпляр
    • Ви повинні мати можливість призначити ELB вашій DNS.
    • Тепер налаштуйте ваш сервер nginx на такі дії: Proxy_pass всі запити до вашого CDN (лише для index.html, обслуговуйте інші активи безпосередньо з хмарного фронту) та пошукові боти, перенаправляйте трафік відповідно до служб, таких як Prerender.io

Я можу допомогти більш детально щодо налаштування nginx, просто залиште записку. Вивчили це важким шляхом.

Після оновлення розповсюдження хмарного фронту. Вимкніть кеш хмарного переходу один раз, щоб перейти в незайманий режим. Натисніть на URL у браузері, і все повинно бути добре.


6
оскільки S3 відповідає 403 Заборонено, коли файл не існує, я думаю, що крок 4 вище повинен бути дубльований і для коду помилки Http 403
Андреас

4
Для мене це єдина відповідь, яка призводить до очікуваної (прийнятої) поведінки
mabe.berlin

1
@ moha297 у пункті 5, ви в основному налаштовуєте свій сайт для отримання з nginx, який потім проксі від CDN (за винятком index.html та запитів сканерів)? Якщо так, чи не втратили б ви переваги крайових серверів CDN?
Рахул Патель

2
@ moha297 чи можете ви поясніть цей коментар: "Ви ніколи не повинні обслуговувати index.html з CDN"? Я не бачу проблеми з обслуговуванням index.html від S3 з CloudFront.
Карл Г

1
Дивіться stackoverflow.com/a/10622078/4185989 для отримання додаткової інформації про те, як TTL 0 отримує обробку (коротка версія: він отримує кешування Cloudfront, але If-Modified-SinceGET-запит надсилається на вихід ) - може бути корисним питанням для людей, які не хочуть налаштувати сервер, як на кроці 5.
jmq

18

Це дотично, але ось поради для тих, хто використовує бібліотеку React Router Rackt з історією браузера (HTML5), які хочуть розміститись на S3.

Припустимо, відвідувач відвідує /foo/bearстатичний веб-сайт, розміщений на S3. Зважаючи на попередню пропозицію Девіда , правила переспрямування надсилатимуть їх /#/foo/bear. Якщо ваша програма побудована за допомогою історії браузера, це не принесе багато користі. Однак ваша програма завантажується в цей момент, і тепер вона може маніпулювати історією.

Включивши історію Rackt в наш проект (див. Також Використання користувацьких історій проекту React Router), ви можете додати слухача, який знає шляхи історії хешу, і замінити шлях, як це показано в цьому прикладі:

import ReactDOM from 'react-dom';

/* Application-specific details. */
const route = {};

import { Router, useRouterHistory } from 'react-router';
import { createHistory } from 'history';

const history = useRouterHistory(createHistory)();

history.listen(function (location) {
  const path = (/#(\/.*)$/.exec(location.hash) || [])[1];
  if (path) history.replace(path);
});

ReactDOM.render(
  <Router history={history} routes={route}/>,
  document.body.appendChild(document.createElement('div'))
);

Для резюме:

  1. Правило перенаправлення Девіда S3 буде спрямоване /foo/bearна /#/foo/bear.
  2. Ваша програма завантажиться.
  3. Слухач історії виявить #/foo/bearпозначення історії.
  4. І замініть історію правильним шляхом.

Linkтеги працюватимуть як очікується, як і всі інші функції історії браузера. Єдиний недолік, який я помітив, - це проміжне переспрямування, яке виникає при первинному запиті.

Це надихнуло рішення для AngularJS , і я підозрюю, що його можна легко адаптувати до будь-якої програми.


2
У цьому мені допоміг Майкл, спасибі! Ви можете змінити свою посилання з історії та просто скористатися BrowserHistory. тобтоbrowserHistory.listen
Маршалл Мутено

Ласкаво просимо! Радий допомогти. Крім того, погодився, і для цього конкретного випадку використання я оновив фрагмент, щоб вирішити попередження про анулювання від React Router.
Майкл Алерс

З випуском react-router v3.0.0 це не працює, тому що react-router v3.0.0 використовує History v3.0.0
Varand Pezeshkian

Будь-яка ідея, як запобігти history.listen нескінченного циклу викликів? Викликана заміною шляху, який я думаю.
Mirko Flyktman

14

Я бачу 4 рішення цієї проблеми. Перші 3 були вже висвітлені у відповідях, а останній - мій внесок.

  1. Встановіть документ про помилку на index.html.
    Проблема : орган відповіді буде правильним, але код статусу буде 404, що шкодить SEO.

  2. Встановіть правила перенаправлення.
    Проблема : Забруднена URL-адреса #!та сторінка блимає при завантаженні.

  3. Налаштування CloudFront.
    Проблема : всі сторінки повернуть 404 з оригіналу, тому вам потрібно вибрати, якщо ви нічого не будете кешувати (TTL 0, як було запропоновано) або якщо ви будете кешувати і мати проблеми під час оновлення сайту.

  4. Попередньо відтворити всі сторінки.
    Проблема : додаткова робота з попереднього відображення сторінок, особливо коли сторінки часто змінюються. Наприклад, веб-сайт новин.

Моя пропозиція - скористатися варіантом 4. Якщо ви будете попередньо відредагувати всі сторінки, на очікуваних сторінках не буде 404 помилок. Сторінка буде добре завантажена, і рамки візьмуть на себе контроль і діятимуть як SPA. Ви також можете встановити документ про помилку для відображення загальної сторінки error.html і правила перенаправлення для перенаправлення 404 помилок на сторінку 404.html (без хешбангу).

Щодо 403 заборонених помилок, я взагалі не допускаю їх. У моєму додатку, я вважаю , що все файли в приймаючому відрі є відкритими , і я встановити це з кожним варіантом з читанням дозволу. Якщо на вашому веб-сайті є приватні сторінки, дозволяти користувачеві бачити HTML- макет не повинно бути проблемою. Що потрібно захистити - це дані, і це робиться в бекенді.

Крім того, якщо у вас є приватні активи, наприклад фотографії користувачів, їх можна зберегти в іншому відрі. Оскільки приватні активи потребують такого ж догляду, як дані, і їх не можна порівнювати з файлами активів, які використовуються для розміщення програми.


1
і на вашому веб-сайті є прекрасний приклад використання для попереднього відображення всіх сторінок. zanon.io/posts/… .- Дякую
frekele

Чи стосується цього четвертого підходу користувач, який перезавантажує URL pushState? Він керує простою навігацією, але при перезавантаженні все одно дістанеться до сервера.
Альфа

@Alpha, я не впевнений, чи правильно я зрозумів ваше запитання, але при перезавантаженні це буде діяти як новий запит. S3 отримає запит і знову поверне попередньо надану сторінку. У цьому випадку немає сервера.
Занон

@Zanon Ах, я думаю, я розумію. Я думав, що це було призначено для кешування попередньо відредагованих сторінок і уникати потрапляння на неіснуючі ресурси S3. Це не залишить маршрутів, які мають динамічні елементи, правда?
Альфа

1
@Zanon я нарешті розумію - дякую! Так, це я мав на увазі. :)
Альфа

13

Я зіткнувся з тією ж проблемою сьогодні, але рішення @ Mark-Nutter було неповним, щоб видалити хешбанг з мого додатка angularjs.

Насправді вам потрібно перейти до редагування дозволів , натиснути Додати більше дозволів, а потім додати правильний список у своєму відрі для всіх. При такій конфігурації AWS S3 тепер зможе повернути помилку 404, і тоді правило перенаправлення належним чином сприйме справу.

Просто так: введіть тут опис зображення

Після цього можна перейти до редагування правил перенаправлення та додати це правило:

<RoutingRules>
    <RoutingRule>
        <Condition>
            <HttpErrorCodeReturnedEquals>404</HttpErrorCodeReturnedEquals>
        </Condition>
        <Redirect>
            <HostName>subdomain.domain.fr</HostName>
            <ReplaceKeyPrefixWith>#!/</ReplaceKeyPrefixWith>
        </Redirect>
    </RoutingRule>
</RoutingRules>

Тут ви можете замінити HostName subdomain.domain.fr на ваш домен та KeyPrefix #! /, Якщо ви не використовуєте метод хешбангу для цілей SEO.

Звичайно, все це буде працювати лише в тому випадку, якщо у вас вже є html5mode установки у вашому кутовому застосуванні.

$locationProvider.html5Mode(true).hashPrefix('!');

моя єдина проблема з цим полягає в тому, що у вас є спалах хешбангу, якого у вас немає з чимось на зразок правила nginx. Користувач знаходиться на сторінці та оновлює: / products / 1 -> #! /
Products

1
Я думаю, ви повинні додати правило для помилки 403, а не дозволу списку грантів для всіх.
Hamish Moffatt

11

Найпростіше рішення зробити так, щоб програма Angular 2+ обслуговувалася з Amazon S3 та працювали прямі URL-адреси - це вказати index.html як документи Index, так і помилки в конфігурації відра S3.

введіть тут опис зображення


11
Це та сама відповідь цієї важко відповіді . Це добре працює, але лише для bodyвідповіді. Код статусу буде 404, і це зашкодить SEO.
Занон

Тому що це працює лише в тому bodyвипадку, якщо у вас є якісь сценарії, які ви імпортуєте в програмі, headвони не працюватимуть, коли ви безпосередньо потрапляєте на будь-який із під-маршрутів на своєму веб-сайті
Мохамед

4

оскільки проблема все ще існує, я хоч і кидаю інше рішення. Моя справа полягала в тому, що я хотів автоматично розгорнути всі запити на тягу до s3 для тестування перед об'єднанням, зробивши їх доступними на [mydomain] / pull-request / [pr номер] /
(наприклад, www.example.com/pull-requests/822/ )

Наскільки мені відомо, сценарії з правилами s3 не дозволяють мати декілька проектів в одному відрі, використовуючи маршрутизацію html5, тому, хоча більшість голосованих пропозицій працює для проекту в кореневій папці, це не для декількох проектів у власних папках.

Тому я вказав свій домен на свій сервер, де виконував цю роботу наступний конфігурація nginx

location /pull-requests/ {
    try_files $uri @get_files;
}
location @get_files {
    rewrite ^\/pull-requests\/(.*) /$1 break;
    proxy_pass http://<your-amazon-bucket-url>;
    proxy_intercept_errors on;
    recursive_error_pages on;
    error_page 404 = @get_routes;
}

location @get_routes {
    rewrite ^\/(\w+)\/(.+) /$1/ break;
    proxy_pass http://<your-amazon-bucket-url>;
    proxy_intercept_errors on;
    recursive_error_pages on;
    error_page 404 = @not_found;
}

location @not_found {
    return 404;
}

він намагається отримати файл, і якщо його не знайти, припускає, що це html5 route і намагається це. Якщо у вас є кутова сторінка 404 для не знайдених маршрутів, ви ніколи не дістанетесь до @not_found і повернете вам кутову сторінку 404 замість не знайдених файлів, які можна виправити деякими, якщо правило в @get_routes чи щось таке.

Я мушу сказати, що я не відчуваю себе занадто комфортно в області конфігурації nginx і використовую rgex для цього питання, я отримав це з деякими пробами та помилками, тому, хоча це працює, я впевнений, що є місце для вдосконалення, і будь ласка, поділіться своїми думками .

Примітка : видаліть правила перенаправлення s3, якщо вони були у вас в конфігурації S3.

і btw працює в Safari


привіт .. дякую за рішення ... куди ти помістиш цей файл nginx conf для розгортання s3. це те саме, що еластична підставка, де мені потрібно створити папку .exextensions і помістити її у файл proxy.config?
користувач3124360

@ user3124360 Не впевнений у еластичній підставці, але в моєму випадку я вказую своє доменне ім'я на екземпляр ec2 і маю там налаштування nginx. Тому запит надходить КЛІЄНТ -> DNS -> EC2 -> S3 -> КЛІЄНТ.
Андрій Арнаутов

так, я роблю щось дуже схоже ... з nginx config тут github.com/davezuko/react-redux-starter-kit/isissue/1099 ... дякую за розміщення вашого конф-файлу .. я бачу, як розвивати цей EC2 -> Підключення S3 зараз
користувач3124360

3

Шукав таку ж проблему. Я в кінцевому підсумку використовував суміш запропонованих вище рішень.

По-перше, у мене є відро s3 з декількома папками, кожна папка представляє веб-сайт, що реагує / скорочує. Я також використовую Cloudfront для вимкнення кешу.

Тому мені довелося використовувати Правила маршрутизації для підтримки 404 та перенаправлення їх на хеш-конфігурацію:

<RoutingRules>
    <RoutingRule>
        <Condition>
            <KeyPrefixEquals>website1/</KeyPrefixEquals>
            <HttpErrorCodeReturnedEquals>404</HttpErrorCodeReturnedEquals>
        </Condition>
        <Redirect>
            <Protocol>https</Protocol>
            <HostName>my.host.com</HostName>
            <ReplaceKeyPrefixWith>website1#</ReplaceKeyPrefixWith>
        </Redirect>
    </RoutingRule>
    <RoutingRule>
        <Condition>
            <KeyPrefixEquals>website2/</KeyPrefixEquals>
            <HttpErrorCodeReturnedEquals>404</HttpErrorCodeReturnedEquals>
        </Condition>
        <Redirect>
            <Protocol>https</Protocol>
            <HostName>my.host.com</HostName>
            <ReplaceKeyPrefixWith>website2#</ReplaceKeyPrefixWith>
        </Redirect>
    </RoutingRule>
    <RoutingRule>
        <Condition>
            <KeyPrefixEquals>website3/</KeyPrefixEquals>
            <HttpErrorCodeReturnedEquals>404</HttpErrorCodeReturnedEquals>
        </Condition>
        <Redirect>
            <Protocol>https</Protocol>
            <HostName>my.host.com</HostName>
            <ReplaceKeyPrefixWith>website3#</ReplaceKeyPrefixWith>
        </Redirect>
    </RoutingRule>
</RoutingRules>

У своєму js-коді мені потрібно було обробити його baseNameконфігурацією для реактивного маршрутизатора. Перш за все, переконайтесь, що ваші залежності є сумісними, я встановив, з якими history==4.0.0не сумісний react-router==3.0.1.

Мої залежності:

  • "історія": "3.2.0",
  • "реагувати": "15.4.1",
  • "реагувати-скорочувати": "4.4.6",
  • "react-router": "3.0.1",
  • "react-router-redux": "4.0.7",

Я створив history.jsфайл для історії завантаження:

import {useRouterHistory} from 'react-router';
import createBrowserHistory from 'history/lib/createBrowserHistory';

export const browserHistory = useRouterHistory(createBrowserHistory)({
    basename: '/website1/',
});

browserHistory.listen((location) => {
    const path = (/#(.*)$/.exec(location.hash) || [])[1];
    if (path) {
        browserHistory.replace(path);
    }
});

export default browserHistory;

Цей фрагмент коду дозволяє обробляти 404, надісланий севером, хешем, і замінювати їх в історії для завантаження наших маршрутів.

Тепер ви можете використовувати цей файл для налаштування магазину та вашого кореневого файлу.

import {routerMiddleware} from 'react-router-redux';
import {applyMiddleware, compose} from 'redux';

import rootSaga from '../sagas';
import rootReducer from '../reducers';

import {createInjectSagasStore, sagaMiddleware} from './redux-sagas-injector';

import {browserHistory} from '../history';

export default function configureStore(initialState) {
    const enhancers = [
        applyMiddleware(
            sagaMiddleware,
            routerMiddleware(browserHistory),
        )];

    return createInjectSagasStore(rootReducer, rootSaga, initialState, compose(...enhancers));
}
import React, {PropTypes} from 'react';
import {Provider} from 'react-redux';
import {Router} from 'react-router';
import {syncHistoryWithStore} from 'react-router-redux';
import MuiThemeProvider from 'material-ui/styles/MuiThemeProvider';
import getMuiTheme from 'material-ui/styles/getMuiTheme';
import variables from '!!sass-variable-loader!../../../css/variables/variables.prod.scss';
import routesFactory from '../routes';
import {browserHistory} from '../history';

const muiTheme = getMuiTheme({
    palette: {
        primary1Color: variables.baseColor,
    },
});

const Root = ({store}) => {
    const history = syncHistoryWithStore(browserHistory, store);
    const routes = routesFactory(store);

    return (
        <Provider {...{store}}>
            <MuiThemeProvider muiTheme={muiTheme}>
                <Router {...{history, routes}} />
            </MuiThemeProvider>
        </Provider>
    );
};

Root.propTypes = {
    store: PropTypes.shape({}).isRequired,
};

export default Root;

Сподіваюся, це допомагає. Ви помітите в цій конфігурації, що я використовую інжектор-редуктор та інжектор сага домівки для асинхронного завантаження JavaScript через маршрутизацію. Не заперечуйте з тезами рядків.


3

Тепер ви можете це зробити за допомогою Lambda @ Edge, щоб переписати шляхи

Ось робоча функція лямбда @ Edge:

  1. Створіть нову функцію лямбда, але використовуйте один із попередніх креслень замість порожньої функції.
  2. Знайдіть "cloudfront" та виберіть генерацію cloudfront-response з результатів пошуку.
  3. Після створення функції замініть вміст нижче. Я також повинен був змінити час виконання вузла на 10.x, оскільки cloudfront не підтримував вузол 12 під час написання.
'use strict';
exports.handler = (event, context, callback) => {

    // Extract the request from the CloudFront event that is sent to Lambda@Edge 
    var request = event.Records[0].cf.request;

    // Extract the URI from the request
    var olduri = request.uri;

    // Match any '/' that occurs at the end of a URI. Replace it with a default index
    var newuri = olduri.replace(/\/$/, '\/index.html');

    // Log the URI as received by CloudFront and the new URI to be used to fetch from origin
    console.log("Old URI: " + olduri);
    console.log("New URI: " + newuri);

    // Replace the received URI with the URI that includes the index page
    request.uri = newuri;

    return callback(null, request);
};

У поведінці на передовій ви будете редагувати їх, щоб додати дзвінок до цієї лямбда-функції в "Запит на перегляд" введіть тут опис зображення

Повний підручник: https://aws.amazon.com/blogs/compute/implementing-default-directory-indexes-in-amazon-s3-backed-amazon-cloudfront-origins-using-lambdaedge/


1
У вашому прикладі коду return callback(null, request);
відсутній

2

Якщо ви приземлилися тут, шукаючи рішення, яке працює з маршрутизатором React та консоллю AWS Amplify - ви вже знаєте, що ви не можете використовувати правила перенаправлення CloudFront безпосередньо, оскільки консоль Amplify не виставляє CloudFront дистрибутива для програми.

Однак рішення дуже просте - вам просто потрібно додати правило переадресації / переписання в консоль Amplify так:

Ампліфікуйте правило перезапису консолі для маршрутизатора React

Щоб отримати докладнішу інформацію (та правило, сприятливе до копіювання, зі знімка екрана), перегляньте наступні посилання:


0

Я сама шукала відповідь на це. Здається, S3 підтримує лише переадресації, ви не можете просто переписати URL-адресу і мовчки повернути інший ресурс. Я розглядаю можливість використовувати свій сценарій збірки, щоб просто зробити копії мого index.html у всіх необхідних місцях шляху. Можливо, це теж спрацює і для вас.


2
Генерування індексних файлів для кожного шляху також перехрестило мою думку, але важко було б мати такі динамічні шляхи, як example.com/groups/5/show . Якщо ви бачите мою відповідь на це питання, я вважаю, що проблема вирішує здебільшого. Це трохи хак, але принаймні це працює.
Марк Наттер

Краще розгорнути за nginx-сервер і повернути index.html для всіх вхідних URL-адрес. Я успішно зробив це з розгортанням додатків з янтар.
moha297

-3

Просто, щоб поставити надзвичайно просту відповідь. Просто використовуйте стратегію розташування хешу для маршрутизатора, якщо ви хостите на S3.

export const AppRoutingModule: ModuleWithProviders = RouterModule.forRoot (маршрути, {useHash: true, scrollPositionRestoration: 'включено'});

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.