So lösen Sie das domänenübergreifende Front-End-Problem mithilfe des Nginx-Proxys

Vorwort

Nginx (ausgesprochen „Engine X“) ist ein asynchroner Framework-Webserver, der auch als Reverse-Proxy, Load Balancer und HTTP-Cache verwendet werden kann.

In diesem Artikel wird beschrieben, wie Sie mit Nginx die Routing-Weiterleitung bei der Entwicklung einer Trennung von Web-Frontend und Backend implementieren.

Bei der Webentwicklung wird normalerweise ein Entwicklungsmodell verwendet, das Front-End und Back-End trennt. Das heißt, Front-End und Back-End werden separat entwickelt und das Front-End fordert die Back-End-Schnittstelle über Ajax an, um Daten abzurufen und die Daten auf der Seite darzustellen. Bei der Front-End-Entwicklung wird ein Scaffolding zum Aufbau einer Front-End-Entwicklungsumgebung verwendet. Die zugrunde liegende Schicht startet normalerweise einen lokalen Server und verwendet normalerweise das Express-Framework von nodejs. Das Backend stellt eine Schnittstelle bereit, die üblicherweise unter einem Domänennamen zur Entwicklung online gestellt wird.

Dies führt während des Entwicklungsprozesses zu domänenübergreifenden Problemen, d. h., eine Webseite unter einem Domänennamen kann nicht über Ajax eine Schnittstellen-API unter einem anderen (anderen Ursprungs-)Domänennamen anfordern. Dies ist die Same-Origin-Policy des Browsers, eine sehr wichtige Sicherheitsrichtlinie des Browsers.

Eine Lösung für dieses Problem ist die Verwendung eines Proxys. Insbesondere wird ein Server lokal gestartet (z. B. localhost:4000) und an den Server gesendete Anforderungen werden gemäß der Anforderungsweiterleitung (z. B. durch Ermitteln, ob die URL das Präfix /api hat) weitergeleitet und an den Front-End-Entwicklungsserver (z. B. localhost:3000) und den Back-End-Server (z. B. dev.yoursite.com) weitergeleitet. Auf diese Weise treten über einen Proxyserver natürlich keine domänenübergreifenden Probleme auf, die zu Anforderungsfehlern führen würden, da sich die angeforderten APIs alle unter demselben Domänennamen befinden.

Als Nächstes erklären wir, wie Sie mit Nginx einen Reverse-Proxy implementieren.

Eine kurze Einführung in Nginx-Konfigurationsdateien

Nach der Installation von Nginx müssen wir den Speicherort der Standardkonfigurationsdatei von Nginx bestimmen. Führen Sie den Befehl nginx -t aus, der erkennt, ob die Syntax der Standardkonfigurationsdatei von nginx korrekt ist, einen Test durchführt und schließlich das Ergebnis ausgibt. Den Speicherort der Standardkonfigurationsdatei können wir der Ausgabe entnehmen.

nginx: die Syntax der Konfigurationsdatei /etc/nginx/nginx.conf ist in Ordnung
nginx: Test der Konfigurationsdatei /etc/nginx/nginx.conf ist erfolgreich

Es gibt eine andere Möglichkeit, den Speicherort der Standardkonfigurationsdatei zu ermitteln, nämlich die Ausführung von nginx -h. Dieser Befehl gibt ein einfaches Hilfedokument für nginx aus, in dem die Konfigurationselementbeschreibung von -c Dateiname auch den Pfad des Standardkonfigurationselements angibt.

-c Dateiname: Konfigurationsdatei festlegen (Standard: /etc/nginx/nginx.conf)

Aus diesem Dokument können wir auch erfahren, dass die Konfigurationsdatei mit dem Konfigurationselement -c angepasst werden kann. Wenn keine Datei angegeben ist, wird die Standardkonfigurationsdatei verwendet.

Als Nächstes ändern wir Nginx in die Standardkonfigurationsdatei nginx.config, um die Proxy-Funktion zu aktivieren.

Im Codeblock nach http in der Datei nginx.config sollte eine Zeile ähnlich der folgenden stehen:

schließen Sie /etc/nginx/conf.d/*.conf ein;

Der Zweck dieser Codezeile besteht darin, den Inhalt von Dateien mit der Endung .conf im Verzeichnis /etc/nginx/conf.d in den Importspeicherort einzubetten und als Teil der Konfiguration auszuführen.

Wenn Sie Nginx auf macOS installiert haben, kann es etwas anders sein. Das von mir mit Brew installierte Nginx enthält „servers/*;“, wodurch alle Dateien im Serververzeichnis eingebunden werden.

Warum wird diese eingebettete Syntax verwendet? Denn auf diese Weise können wir die für verschiedene Projekte benötigten Konfigurationen in unterschiedliche Konfigurationsdateien einfügen. Der Vorteil besteht darin, dass wir schnell die zu ändernde Konfigurationsdatei für das entsprechende Projekt finden können, ohne befürchten zu müssen, versehentlich die Konfiguration anderer Projekte zu ändern. Wenn Sie es außerdem direkt in nginx.conf ändern, wird es aufgebläht. Dies entspricht dem Single-Responsibility-Prinzip des Entwurfsmusters.

Außerdem fragen Sie sich vielleicht, warum dem Namen des Verzeichnisses conf.d die Erweiterung .d hinzugefügt wird? Wenn Sie Linux schon eine Weile verwenden, werden Sie feststellen, dass an das Ende einiger Verzeichnisse oder Dateien ein „d“ angehängt wird, z. B. bei httpd, crond, vsftpd usw. Tatsächlich soll dies veranschaulichen, dass es sich bei diesen Dateien alle um Daemons (Dienste) handelt. Bei den Diensten handelt es sich hierbei um die Systemdienste, die sich im Wesentlichen in vom System selbst benötigte Dienste und für das Netzwerk zuständige Dienste unterteilen. Unser Conf.d gehört zur letzteren Kategorie.

Schreiben von Nginx-Konfigurationsdateien

Wir erstellen eine Datei mit dem Namen demo.conf im Verzeichnis conf.d, schreiben den folgenden Inhalt und starten dann Nginx.

Server {
 höre 5000;
 Servername localhost;

 Standort / {
 Proxy-Passwort http://localhost:3000;
 }
 Standort /api/ {
 Proxy-Passwort http://localhost:4000;
 }
}

Diese Konfiguration aktiviert den Server bei localhost:5000 und leitet URL-Anfragen, die mit /api/ beginnen, von localhost:5000 an localhost:4000 (den Back-End-Schnittstellenserver) weiter. Andere Anfragen werden an localhost:3000 (Frontend) weitergeleitet. Als nächstes werden wir die Funktionen des Inhalts der Konfigurationsdatei im Detail analysieren.

„listen“ legt die Portnummer des Servers fest und „server_name“ legt den Hostnamen fest.

Standort

Standort bedeutet, dass er mit der Route übereinstimmt. Wenn er übereinstimmt, wird die Operation im entsprechenden Codeblock ausgeführt. Der Standort kann Präfixübereinstimmung und reguläre Übereinstimmung verwenden (muss mit ~* oder ~ beginnen). Die hier verwendete Konfiguration nutzt Präfixübereinstimmung.

Hier ist ein Punkt zu beachten. Die Routenanpassung von Nginx unterscheidet sich vom allgemeinen Routenanpassungsschema, das die erste in der Reihenfolge abgleicht (wie das Routenanpassungsschema des Backend-Gins und des Frontend-Vue-Routers). Nginx gleicht Routen folgendermaßen ab:

1. Führen Sie zunächst einen Präfixabgleich durch, durchlaufen Sie alle Präfixübereinstimmungen und wählen Sie diejenige mit der längsten Präfixübereinstimmung aus.
2. Dann wird ein regulärer Abgleich durchgeführt und unter allen regulären Abgleichen der erste von vorne nach hinten ausgewählte, der übereinstimmt.
3. Wenn ein passender regulärer Ausdruck gefunden wird, wird die entsprechende Konfiguration verwendet. Wenn nicht, wird die Konfiguration verwendet, die der längsten zuvor gefundenen Präfixübereinstimmung entspricht.
   

Wenn die Anforderung localhost:5000/api/xx lautet, kann daher sowohl das Präfix / als auch /api/ übereinstimmen. Obwohl gemäß den Regeln das / am Anfang auch die Präfixübereinstimmung erfüllt, ist /api länger, sodass die endgültige Übereinstimmung /api ist.

Proxy-Passwort

Nachdem wir den passenden Standort ermittelt haben, sehen wir uns an, was proxy_pass macht. proxy_pass wird verwendet, um Anforderungsrouten dem angegebenen Protokoll und der angegebenen Adresse zuzuordnen. Das Wesentliche besteht darin, die an Nginx gesendete Anforderung zu verarbeiten und an einen anderen Server zu senden und dann die zurückgegebenen Daten als Rückgabedaten von Nginx zurückzugeben.

Wenn nach proxy_pass eine URI verwendet wird (mit mindestens einem / nach dem Port), ersetzt Nginx die Zeichen, die mit dem Standort übereinstimmen.

höre 5000;
Servername localhost;
Standort /Name/ {
 Proxy-Passwort http://127.0.0.1/remote/; 
}
# localhost:5000/name/fstar
# Die zugeordnete Anfrage lautet # 127.0.0.1/remote/fstar

Wie Sie sehen, wird der Teil /name/ während der Zuordnung entfernt (oder ersetzt).

Wenn auf proxy_pass kein URI folgt (nichts nach dem Port), ordnet Nginx die Quellanforderung vollständig dem Proxy-Dienst zu:

höre 5000;
Servername localhost;
Standort /irgendein/Pfad/ {
 Proxy-Passwort http://127.0.0.1;
}

# localhost:5000/irgendein/Pfad/x/y
# wird abgebildet auf # 127.0.0.1/irgendein/Pfad/x/y

Hier wird /some/path nicht entfernt.

Der Proxy-Pass unserer Datei „demo.conf“ verwendet keine URI und ordnet die Route daher einem vollständig anderen Dienst zu.

Fragen zur Überlegung

Entschuldigung, unten gibt es zwei Konfigurationen (der Unterschied besteht darin, ob am Ende von proxy_pass ein / steht)? Wenn Sie /kite/api/xx anfordern, worauf wird es abgebildet?

Standort /kite/api/ {
 Proxy-Passwort http://localhost:5000;
}

Standort /kite/api/ {
 Proxy-Passwort http://localhost:5000/;
}

Als wir zuvor über proxy_pass sprachen, sagten wir, dass, wenn nach proxy_pass kein URI steht, eine normale Weiterleitung erfolgt; wenn es ein URI ist, wird das mit dem Standort übereinstimmende Präfix vor der Weiterleitung entfernt, was den Effekt des Ersetzens der Route widerspiegelt. Der Unterschied zwischen den beiden obigen Konfigurationen liegt im / am Ende. Die mit / ist eine URI, während die ohne / keine URI ist, was jeweils zu völlig unterschiedlichen Ergebnissen führt:

http://localhost:5000/kite/api/xx
http://localhost:5000/xx

Achten Sie daher beim Schreiben der Nginx-Konfiguration unbedingt darauf, ob das / nach dem Port beibehalten werden muss. Denn seine Anwesenheit bzw. Abwesenheit führt zu zwei völlig unterschiedlichen Effekten.

Verweise

• Offizielle Nginx-Dokumentation
• Wie schreibe ich URLs in einer Proxy-Antwort in NGINX um?

Zusammenfassen

Dies ist das Ende dieses Artikels über die Verwendung des Nginx-Proxys zur Lösung des domänenübergreifenden Front-End-Problems. Weitere relevante Inhalte zur Verwendung des Nginx-Proxys zur Lösung des domänenübergreifenden Front-End-Problems finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!