Als ich anfing, JavaScript zu lernen, wusste ich nicht, was Ajax-Cross-Domain ist, aber ich hörte oft einige große Leute über domänenübergreifende Ajax-Cross-Domain-Probleme reden. Es muss einige Klassenkameraden geben Ich mag es, also werfen wir heute einen Blick darauf, was genau Ajax-Cross-Domain ist und welche Methoden es gibt, um Ajax-Cross-Domain zu lösen!
Vorwort
In Bezug auf domänenübergreifend gibt es N-Typen, die sich nur auf domänenübergreifende Ajax-Anfragen konzentrieren. Die Domäne gehört nur zum Durchsuchen. Teil der „Same-Origin-Richtlinie“ des Servers, andere umfassen domänenübergreifende Cookies, domänenübergreifende Iframes, domänenübergreifende LocalStorage usw. (hier nicht vorgestellt). Der Inhalt lautet ungefähr wie folgt:
1. Was ist Ajax Cross-Domain
Prinzip
Leistung (organisiert einige Begegnungen, Probleme und Lösungen)
2. So lösen Sie Ajax domänenübergreifend
JSONP-Methode
CORS-Methode
Proxy-Anfragemethode
3. So analysieren Sie Ajax domänenübergreifend
Analyse der HTTP-Paketerfassung
Einige Beispiele
Was ist domänenübergreifendes Ajax? 🎜>Ajax hat ein domänenübergreifendes Fehlerproblem. Der Hauptgrund liegt im Surfen. Sie können sich auf
Browser Same Origin Policy und seine Umgehungsmethoden beziehen 🎜>
CORS-Anfrageprinzip
CORS ist ein W3C-Standard, der vollständige Name lautet „Cross-Origin-Ressource“. Teilen". Es ermöglicht dem Browser, XMLHttpRequest-Anfragen an Cross-Origin-Server zu stellen und überwindet so die Einschränkung, dass AJAX nur vom gleichen Ursprung aus verwendet werden kann.
Grundsätzlich haben alle aktuellen Browser den CORS-Standard implementiert. Tatsächlich basieren fast alle Browser-Ajax-Anfragen auf dem CORS-Mechanismus, aber Front-End-Entwickler kümmern sich möglicherweise nicht darum (also eigentlich hauptsächlich um die aktuelle CORS-Lösung). überlegt, wie das Backend implementiert werden soll). Bezüglich CORS wird dringend empfohlen,
Ausführliche Erklärung von CORS für die domänenübergreifende Ressourcenfreigabe
In zu lesen Darüber hinaus ist hier auch eine Implementierung zusammengestellt. Schematisch (vereinfachte Version):
Wie kann man feststellen, ob es sich um eine einfache Anfrage handelt?
Browser unterteilen CORS-Anfragen in zwei Kategorien: einfache Anfragen und nicht ganz so einfache Anfragen. Sofern die beiden folgenden Bedingungen gleichzeitig erfüllt sind, handelt es sich um eine einfache Anfrage. 
1. Die Anforderungsmethode
ist eine der folgenden drei Methoden: HEAD, GET, POST
2. HTTP-Header-Informationen Überschreiten Sie nicht die folgenden Felder:
1. AkzeptierenAkzeptieren 2. Accept-Language
3. Inhalt-Sprache
4. Letzte-Ereignis-ID 5. Content-Type (beschränkt auf drei Werte application/x-www-form-urlencoded, multipart/form-data, text/plain)
Immer anders Wenn die beiden oben genannten Bedingungen erfüllt sind, handelt es sich um eine nicht einfache Anfrage.
Ajax-Cross-Domain-Leistung
Um ehrlich zu sein, habe ich einen Artikel zusammengestellt und ihn dann als Lösung verwendet, aber später habe ich das gefunden Es war immer noch Viele Leute wissen immer noch nicht wie. Wir haben keine andere Wahl, als es zu debuggen, was zeit- und arbeitsintensiv ist. Aber selbst wenn ich es analysiere, werde ich nur anhand der entsprechenden Leistung beurteilen, ob es domänenübergreifend ist, daher ist dies sehr wichtig.
Wenn bei einer Ajax-Anfrage ein domänenübergreifendes Phänomen vorliegt und dieses nicht behoben wird, tritt das folgende Verhalten auf: (Beachten Sie, dass es sich um eine Ajax-Anfrage handelt. Bitte sagen Sie nicht, warum http-Anfragen in Ordnung sind Bei Ajax ist dies jedoch nicht der Fall, da Ajax von domänenübergreifend begleitet wird, sodass nur eine HTTP-Anfrage ok nicht ausreicht.
Das erste Phänomen:Auf der angeforderten Ressource ist kein Header „Access-Control-Allow-Origin“ vorhanden undDie Antwort hatte den HTTP-Statuscode 404
Die Gründe für diese Situation sind wie folgt:
1 Diese Ajax-Anfrage ist „. Keine einfache Anfrage“, daher wird vor der Anfrage eine Preflight-Anfrage (OPTIONS) gesendet
2. Die serverseitige Hintergrundschnittstelle lässt keine OPTIONS-Anfragen zu, was dazu führt, dass die entsprechende Schnittstellenadresse nicht gefunden werden kann
Lösung: Das Backend erlaubt Optionsanfragen
Zweites Phänomen:Auf der angeforderten Ressource ist kein Header „Access-Control-Allow-Origin“ vorhandenundDie Die Antwort hatte den HTTP-Statuscode 405
Dieses Phänomen unterscheidet sich vom ersten. In diesem Fall lässt die Hintergrundmethode OPTIONS-Anfragen zu, aber einige Konfigurationsdateien (z. B. Sicherheitskonfiguration) blockieren OPTIONS-Anfragen, was dies verursacht Phänomen.
Lösung: Schließen Sie die entsprechende Sicherheitskonfiguration im Backend
Drittes Phänomen:Auf der angeforderten Ressource ist kein „Access-Control-Allow-Origin“-Header vorhanden , und Status 200
Dieses Phänomen unterscheidet sich vom ersten und zweiten darin In diesem Fall lässt der serverseitige Hintergrund OPTIONS-Anfragen zu, und die Schnittstelle lässt auch OPTIONS-Anfragen zu, es liegt jedoch eine Nichtübereinstimmung vor, wenn die Header übereinstimmen.
Zum Beispiel stimmt die Überprüfung des Ursprungsheaders nicht mit einigen Headern überein Wenn die Unterstützung fehlt (z. B. der allgemeine X-Requested-With-Header), sendet der Server die Antwort an das Front-End zurück. Nachdem das Front-End dies erkannt hat, löst es XHR.onerror aus, was dazu führt, dass Endkonsole meldet einen Fehler
Lösung: Das Backend fügt entsprechende Header-Unterstützung hinzu
Das vierte Phänomen: heade enthält mehrere Werte '*,*'
Das Symptom ist, dass die HTTP-Header-Informationen der Hintergrundantwort zwei Access-Control-Allow-Origin haben:*
Um ehrlich zu sein, tritt diese Art von Problem auf. Der Hauptgrund dafür ist, dass Personen, die eine domänenübergreifende Konfiguration durchführen, das Prinzip nicht verstehen, was zu wiederholten Konfigurationen führt, wie zum Beispiel:
1. Häufig wird im .net-Hintergrund angezeigt (normalerweise wird der Ursprung einmal in web.config und dann erneut im Code konfiguriert. Der Ursprung wird einmal manuell hinzugefügt (der Code legt beispielsweise die Rückgabe * manuell fest))
2. Wird häufig gesehen im .net-Hintergrund (Origin:* gleichzeitig in IIS und in der Webkonfiguration des Projekts festlegen)
Lösung (Eins-zu-Eins-Korrespondenz):
1. Es wird empfohlen, die im Code manuell hinzugefügten * zu löschen und nur die in der Projektkonfiguration zu verwenden
2 , es wird empfohlen, die Konfiguration* unter IIS zu löschen und nur die zu verwenden eine in der Projektkonfiguration
So lösen Sie domänenübergreifende Ajax-Lösungen
Allgemeine domänenübergreifende Ajax-Lösungen werden über JSONP oder gelöst CORS, wie folgt: (Beachten Sie, dass JSONP fast nicht mehr verwendet wird, verstehen Sie also einfach JSONP)
JSONP-Lösung Domänenübergreifende Probleme
jsonp ist eine relativ alte Lösung zur Lösung domänenübergreifender Probleme (in der Praxis nicht empfohlen). Hier finden Sie eine kurze Einführung (wenn Sie JSONP in tatsächlichen Projekten verwenden möchten, verwenden Sie im Allgemeinen JQ und andere Klassenbibliotheken, die JSONP kapseln, um Ajax zu erstellen). Anfragen)
Implementierungsprinzip
Der Grund, warum JSONP zur Lösung domänenübergreifender Probleme verwendet werden kann, liegt hauptsächlich daran, dass <script> verfügen über domänenübergreifende Funktionen, und JSONP nutzt dies, um dies zu erreichen. Das konkrete Prinzip ist in der Abbildung </script>
dargestellt
Implementierungsprozess
Die Implementierungsschritte von JSONP sind ungefähr wie folgt (siehe Artikel in der Quelle)
1. Die Client-Webseite fordert JSON vom Server an, indem sie ein < ;script>-Elementdaten, dieser Ansatz ist nicht durch die gleiche Ursprungsrichtlinie eingeschränkt
function addScriptTag(src) {
var script = document.createElement('script');
script.setAttribute("type","text/javascript");
script.src = src;
document.body.appendChild(script);
}
window.onload = function () {
addScriptTag('http://example.com/ip?callback=foo');
}
function foo(data) {
console.log('response data: ' + JSON.stringify(data));
};Nach dem Login kopieren
Bei der Anforderung wird die Schnittstellenadresse als Quelle des erstellten Skript-Tags verwendet wird erstellt, der letzte Quellcode ist die Schnittstelle. Zurückgegebener Inhalt
2. Die entsprechende Schnittstelle des Servers fügt eine Funktionsumbruchschicht außerhalb des Rückgabeparameters hinzu
foo({
"test": "testData"
});Nach dem Login kopieren
3. Das von der angeforderte Skript Das
