Der React Router funktioniert nicht im aws s3 Bucket

Ich habe meinen React- build/Websiteordner in einem AWS S3-Bucket bereitgestellt .

Wenn ich zu gehe www.mywebsite.com, funktioniert es und wenn ich auf aTag klicke, um zu den Seiten Projekt und Info zu gelangen, werde ich zur richtigen Seite weitergeleitet. Wenn ich jedoch die Seiten-URL kopiere und sende oder direkt zu dem Link gehe wie : www.mywebsite.com/projects, wird 404 zurückgegeben.

Hier ist mein App.jsCode:

const App = () => (
    <Router>
        <div>
            <NavBar/>
            <Switch>
                <Route exact path="/" component={Home}/>
                <Route exact path="/projects" component={Projects}/>
                <Route exact path="/about" component={About}/>
                <Route component={NoMatch}/>
            </Switch>
        </div>
    </Router>
);

Ich bin mir nicht sicher, ob Sie es bereits gelöst haben. Ich hatte das gleiche Problem.

Dies liegt daran, dass AWS S3 nach dem Ordner (den Projekten) sucht, aus dem Sie dienen können, den Sie nicht haben.

Zeigen Sie einfach auf Fehlerdokument auf index.html.

Das hat bei mir funktioniert. Sie können Fehlerseiten im React-Router behandeln.

Update 1. Mai 2020:

Da dieser Beitrag ziemlich aktiv ist, muss ich die Antwort aktualisieren:

Sie haben also einige Möglichkeiten, um das Problem zu lösen:

1. Sie können setzen index.html im Fehler Dokument Feld (wie Alan Friedman vorgeschlagen).
   • Gehen Sie zu Ihrem Bucket (dem, der tatsächlich den Code enthält - nicht dem, den Sie zum Umleiten verwenden) -> Eigenschaften -> Statisches Website-Hosting :
   • Dies ist nicht "hacky", aber es funktioniert aufgrund der Funktionsweise react-router : Es verarbeitet die Anforderungen vom Front-End und leitet Benutzer zu anderen Routen weiter. Insgesamt ist die React-App jedoch eine einseitige Anwendung.
   • Wenn Sie serverseitig reagieren möchten, sollten Sie Next.js verwenden .

2. Sie können eine bestimmte Fehlerdatei setzen error.html in den öffentlichen Reaktion App Ordner Ihrer und in der statischen Website - Hosting : Fehler Dokument Feld setzte in: error.html . Das funktioniert auch. Ich habe es getestet.

3. Verwenden Sie AWS CloudFront > CloudFront-Verteilungen > Die Verteilung Ihres Buckets> Fehlerseiten und fügen Sie den gewünschten Fehlercode hinzu. Wenn Sie nicht verwenden react-router(wie im folgenden Beispiel), antwortet der Bucket mit Fehler 403, sodass Sie mit Ihrer error.html antworten können .

4. Wird TypeScriptderzeit react-routernicht unterstützt, daher sollten Sie Option 2 und 3 in Betracht ziehen . Sie werden die Bibliothek in einer zukünftigen Version 6.*gemäß diesem Thread aktualisieren .

Falls dieser S3-Bucket von einer CloudFront-Distribution bereitgestellt wird :

Erstellen Sie eine benutzerdefinierte Fehlerseite (AWS Docs) in der CloudFront-Distribution, die 404-Fehler an index.html weiterleitet und 200 Antwortcode zurückgibt. Auf diese Weise übernimmt Ihre Anwendung das Routing.

Benutzerdefinierte Fehlerseiten

Das Umleiten von 4xx zu index.html würde funktionieren, aber diese Lösung würde dazu führen, dass Sie auf viele andere Probleme stoßen, z. B. dass Google diese Seiten nicht crawlen kann. Bitte überprüfen Sie diesen Link . Dieses Problem wurde mithilfe von Umleitungsregeln für den S3-Bucket behoben.

Fall verwenden Cloudfront zu S3:

https://hackernoon.com/hosting-static-react-websites-on-aws-s3-cloudfront-with-ssl-924e5c134455

3b) AWS CloudFront - Fehlerseiten Fahren Sie nach dem Erstellen der CloudFront-Distribution mit dem Status "In Bearbeitung" mit der Registerkarte "Fehlerseiten" fort. Behandeln Sie die Antwortcodes 404 und 403 mit "Fehlerantwort anpassen".

Google empfiehlt 1 Woche oder 604800 Sekunden Caching. Wir richten hier CloudFront so ein, dass fehlende HTML-Seiten behandelt werden. Dies tritt normalerweise auf, wenn ein Benutzer einen ungültigen Pfad eingibt oder insbesondere einen anderen Pfad als den Stammpfad aktualisiert.

Wenn das passiert:

CloudFront sucht nach einer Datei, die im S3-Bucket nicht vorhanden ist. Es befindet sich nur 1 HTML-Datei im Bucket. Dies ist die index.html für den Fall einer Einzelseitenanwendung wie dieses Projektbeispiel. Eine 404-Antwort wird zurückgegeben und von unserem benutzerdefinierten Fehlerantwort-Setup entführt. Wir werden stattdessen einen 200-Antwortcode und die index.html-Seite zurückgeben. Der React-Router, der zusammen mit der Datei index.html geladen wird, überprüft die URL und rendert die richtige Seite anstelle des Stammpfads. Diese Seite wird für die Dauer der TTL für alle Anforderungen an den abgefragten Pfad zwischengespeichert. Warum müssen wir auch mit 403 umgehen? Dies liegt daran, dass dieser Antwortcode anstelle von 404 von Amazon S3 für nicht vorhandene Assets zurückgegeben wird. Zum Beispiel eine URL von https://yourdomain.com/somewhere wird nach einer Datei suchen, die irgendwo (ohne Erweiterung) aufgerufen wird und nicht existiert.

PS. Früher gab es 404 zurück, aber jetzt scheint es 403 zurückzugeben; In beiden Fällen ist es am besten, beide Antwortcodes zu verarbeiten.

Diese Frage hat bereits mehrere gute Antworten. Obwohl die Frage jetzt alt ist, habe ich mich heute diesem Problem gestellt, daher habe ich das Gefühl, dass diese Antwort vielleicht helfen kann.

S3 verfügt über zwei Arten von Endpunkten. Wenn dieser Fehler auftritt, haben Sie wahrscheinlich den S3-Bucket direkt als Endpunkt im Feld Ursprungsdomänenname für Ihre CloudFront-Verteilung ausgewählt.

Das würde ungefähr so ​​aussehen: bucket-name.s3.amazonaws.com und ist ein vollkommen gültiger Endpunkt. Tatsächlich scheint AWS dies als Standardverhalten zu erwarten. Dieser Eintrag befindet sich in der Dropdown-Liste, die Sie beim Erstellen Ihrer CloudFront-Distribution haben.

Wenn Sie dies jedoch tun und dann Fehlerseiten einstellen, kann dies Ihr Problem möglicherweise lösen oder nicht.

S3 verfügt jedoch über einen dedizierten Website-Endpunkt. Sie können über Ihren S3-Bucket> Eigenschaften> Statisches Website-Hosting darauf zugreifen. (Sie sehen den Link oben).

Sie sollten diesen Link anstelle des ursprünglichen automatisch ausgefüllten Links verwenden, der in CloudFront angezeigt wird. Sie können dies beim Erstellen Ihrer Distribution eingeben oder nach der Erstellung über die Registerkarte Ursprünge und Ursprungsgruppen bearbeiten und anschließend die Caches ungültig machen.

Dieser Link sieht folgendermaßen aus : bucket-name.s3-website.region-name.amazonaws.com.

Sobald sich dies verbreitet und ändert, sollte dies Ihr Problem beheben.

tl; dr: Verwenden Sie nicht den Standard-S3-Endpunkt in CloudFront. Verwenden Sie stattdessen den S3-Website-Endpunkt. Ihre Ursprungsdomäne sollte so aussehen: my-application.s3-website.us-east-1.amazonaws.comund nicht so my-application.s3.amazonaws.com.

Weitere Informationen zu Website-Endpunkten finden Sie in der AWS-Dokumentation hier .

Warum es passiert

Ihr Problem ist, dass Sie die Verantwortung für das Routing an Ihre Reaktions-App / Ihr Javascript übertragen möchten. Der Link funktioniert, da reagieren den Linkklick abhören und einfach die Route in der Browser-URL-Leiste aktualisieren kann. Wenn Sie jedoch an einen Ort gehen, an dem Ihr Skript (index.html und bundle.js oder wo sich Ihr App-Code befindet) nicht geladen ist, wird das JavaScript nie geladen und hat keine Chance, die Anforderung zu bearbeiten. Unabhängig davon, was auf Ihrem Server ausgeführt wird, wird die Anforderung bearbeitet. Überprüfen Sie, ob sich an dieser Stelle eine Ressource befindet, und geben Sie einen 404-Fehler oder einen anderen gefundenen Fehler zurück.

Die Lösung

Wie in den Kommentaren erwähnt, ist dies der Grund, warum Sie 404-Fehler an den genauen Ort umleiten müssen, an dem Ihre App platziert ist. Dies ist nichts Besonderes für Amazon. Es ist eine allgemeine Voraussetzung, um Ihre Reaktions-App einzurichten.

Um das Problem zu lösen, müssen Sie herausfinden, wie das Routing auf Ihrem Server funktioniert und wie es konfiguriert wird. Wenn Sie beispielsweise einen Apache-Server haben, kann sich eine .htaccess-Datei wie folgt um Folgendes kümmern:

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.html$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.html [L]
 </IfModule>

Mit dieser Datei kann der Server nicht gefundene Fehler in die Datei index.html umleiten. Beachten Sie, dass dies möglicherweise Auswirkungen auf andere Routing-Regeln auf Ihrem Server hat. Daher ist diese Konfiguration am einfachsten, wenn Ihre Reaktions-App einen eigenen Platz hat und andere Dinge nicht beeinträchtigt.

Ich bin auf dieses Problem gestoßen, obwohl ich die in der akzeptierten Antwort beschriebene Konfiguration verwendet habe. Wenn jedoch immer noch 403 Fehler angezeigt werden und Sie AWS Cloudflare Manager verwenden, können Sie auf der Registerkarte "Fehlerseiten" der Verteilungseinstellungen eine Fehlerseite erstellen , mit folgender Konfiguration:

Error Code: 404,
Customize Error Response: Yes, 
Response Page Path: /index.html, 
HTTP Response Code: 200

Bild der Fehlerseite Konfigurieren Sie, um die Routenbehandlung an den Browser-Router zu übergeben

Dies hat bei mir funktioniert, obwohl ich keineswegs über den richtigen Serveradministrator Bescheid weiß. Hoffentlich wird mir jemand sagen, ob dies ein großes Problem ist, wenn es zufällig ist.

Update Konfiguration von S3 mit Hosting Static und Standard mit Index.html Geben Sie hier die Bildbeschreibung ein

Fügen Sie CloudFront mit Fehlerseite hinzu

404 error-> index.html->status 200

Geben Sie hier die Bildbeschreibung ein

Ich habe es behoben, indem ich HashRouteranstelle von verwendet habeRouter

import { Switch, Route, HashRouter } from 'react-router-dom';

const App = () => (
    <HashRouter>
        <div>
            <NavBar/>
            <Switch>
                <Route exact path="/" component={Home}/>
                <Route exact path="/projects" component={Projects}/>
                <Route exact path="/about" component={About}/>
                <Route component={NoMatch}/>
            </Switch>
        </div>
    </HashRouter>
);

Die App ist von so etwas wie zugänglich https://your-domain.s3.amazonaws.com/index.html?someParam=foo&otherPram=bar/#/projects

auf localhost wie https://localhost:3000/?someParam=foo&otherPram=bar/#/projects

Es waren keine Änderungen in S3 erforderlich.

Ich benutze NextJS und hatte das gleiche Problem. Meine Lösung bestand darin, die Routing-Informationen zu überprüfen und zu pushen, wenn sie nicht passen.

const router = useRouter();
useEffect(() => {
    if (!router.pathname.startsWith(router.asPath)) {
      router.push(router.asPath);
    }
  });

Auf der S3-Seite musste nichts geändert werden, außer dass die Fehlerseite an index.html weitergeleitet wurde

Wie in den vorherigen Antworten angegeben, ist der beste Weg, um das Problem zu lösen: Definieren Sie die Fallback-Strategie neu. Wenn Sie mehr über clientseitiges Routing und serverseitiges Routing und insbesondere über verschiedene Routing-Ansätze in React JS erfahren möchten, lesen Sie diesen Artikel .