[javascript] Wie funktioniert Access-Control-Allow-Origin-Header?


4 Answers

Cross-Origin-Request-Sharing - CORS (AKA Cross-Domain AJAX-Anfrage) ist ein Problem, das die meisten Web-Entwickler, nach Same-Origin-Richtlinie, Browser JavaScript in einer Sicherheits-Sandbox beschränken können, in der Regel kann JS nicht direkt mit einem Remote kommunizieren Server von einer anderen Domäne. In der Vergangenheit haben Entwickler viele knifflige Möglichkeiten geschaffen, um eine domänenübergreifende Ressourcenanfrage zu erreichen.

  1. Verwenden Sie Flash / Silverlight oder serverseitig als "Proxy" für die Kommunikation mit der Fernbedienung.
  2. JSON mit Padding ( JSONP ).
  3. Integriert den Remote-Server in einen Iframe und kommuniziert über ein Fragment oder window.name, siehe here .

Diese kniffligen Wege haben mehr oder weniger Probleme, zum Beispiel JSONP könnte zu Sicherheitslücken führen, wenn Entwickler es einfach "evalieren", und oben # 3, obwohl es funktioniert, sollten beide Domänen strikte Verträge untereinander aufbauen, weder flexibel noch elegant MEINER BESCHEIDENEN MEINUNG NACH:)

W3C hatte Cross-Origin Resource Sharing (CORS) als Standardlösung eingeführt, um einen sicheren, flexiblen und empfohlenen Standard zur Lösung dieses Problems zu bieten.

Der Mechanismus

Von einer höheren Ebene können wir einfach CORS als Vertrag zwischen einem Client-AJAX-Aufruf von Domäne A und einer Seite, die auf Domäne B gehostet wird, verstehen. Eine typische Cross-Origin-Anfrage / Antwort wäre:

DomainA AJAX-Anforderungsheader

Host DomainB.com
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,application/json
Accept-Language en-us;
Accept-Encoding gzip, deflate
Keep-Alive 115
Origin http://DomainA.com 

DomainB Antwortheader

Cache-Control private
Content-Type application/json; charset=utf-8
Access-Control-Allow-Origin DomainA.com
Content-Length 87
Proxy-Connection Keep-Alive
Connection Keep-Alive

Die blauen Teile, die ich oben markiert habe, waren die Kerntatsachen, "Origin" -Aufforderungsheader "gibt an, woher die Ursprungsquellanfrage oder die Preflight-Anfrage stammt", der Antwortkopf "Access-Control-Allow-Origin" gibt an, dass diese Seite eine Fernanfrage ermöglicht DomainA (wenn der Wert "*" ist, können Remoteanforderungen von jeder Domäne verwendet werden).

Wie bereits erwähnt, hat W3 dem Browser empfohlen, eine " Preflight-Anfrage " zu implementieren, bevor er die eigentliche Cross-Origin-HTTP-Anfrage OPTIONS gesagt, es handelt sich um eine HTTP- OPTIONS Anfrage:

OPTIONS DomainB.com/foo.aspx HTTP/1.1

Wenn foo.aspx das HTTP-Verb OPTIONS unterstützt, kann die Antwort wie folgt zurückgegeben werden:

HTTP/1.1 200 OK
Date: Wed, 01 Mar 2011 15:38:19 GMT
Access-Control-Allow-Origin: http://DomainA.com
Access-Control-Allow-Methods: POST, GET, OPTIONS, HEAD
Access-Control-Allow-Headers: X-Requested-With
Access-Control-Max-Age: 1728000
Connection: Keep-Alive
Content-Type: application/json

Nur wenn die Antwort "Access-Control-Allow-Origin" enthält und ihr Wert "*" ist oder die Domäne enthält, die die CORS-Anfrage gesendet hat, sendet der Browser die aktuelle Cross-Domain-Anfrage und speichert das Ergebnis zwischen in " Preflight-Ergebnis-Cache ".

Ich habe vor drei Jahren über CORS gebloggt: AJAX Cross-Origin HTTP-Anfrage

Question

Anscheinend habe ich seine Semantik völlig falsch verstanden. Ich dachte an so etwas:

  1. Ein Client lädt JavaScript-Code MyCode.js von http: // siteA - der Ursprung .
  2. Der Antwortheader von MyCode.js enthält Access-Control-Allow-Origin: http: // siteB , was meiner Meinung nach bedeutete, dass MyCode.js übergreifende Verweise auf die Site B erstellen konnte.
  3. Der Client löst einige Funktionen von MyCode.js aus, die wiederum Anforderungen an http: // siteB stellen, was trotz der querverweisenden Anforderungen in Ordnung sein sollte.

Nun, ich liege falsch. So funktioniert es überhaupt nicht. Also habe ich Cross-Origin-Ressourcen-Sharing gelesen und versucht, Cross-Origin Resource Sharing in W3C-Empfehlung zu lesen

Eins ist sicher - ich verstehe immer noch nicht, wie ich diesen Header verwenden soll.

Ich habe die volle Kontrolle sowohl von Site A als auch von Site B. Wie aktiviere ich den JavaScript-Code, der von der Site A heruntergeladen wurde, um auf Ressourcen auf der Site B zuzugreifen, die diesen Header verwenden?

PS

Ich möchte JSONP nicht verwenden.




Wenn Sie nur eine domänenübergreifende Anwendung testen möchten, in der der Browser Ihre Anfrage blockiert, können Sie Ihren Browser einfach im unsicheren Modus öffnen und Ihre Anwendung testen, ohne Ihren Code zu ändern und Ihren Code nicht unsicher zu machen. Von MAC OS aus können Sie dies über die Terminalzeile tun:

open -a Google\ Chrome --args --disable-web-security --user-data-dir



Wann immer ich über CORS nachdenke, ist meine Intuition darüber, welche Seite die Header hostet, falsch, genau wie Sie es in Ihrer Frage beschrieben haben. Für mich ist es hilfreich, über den Zweck derselben Herkunftsrichtlinie nachzudenken.

Der Zweck der gleichen Ursprungsrichtlinie besteht darin, Sie vor schädlichem JavaScript auf siteA.com zu schützen, indem Sie auf private Informationen zugreifen, die Sie nur für siteB.com freigegeben haben. Ohne die gleiche Ursprungsrichtlinie kann JavaScript, das von den Autoren von siteA.com geschrieben wurde, Ihren Browser dazu veranlassen, Anfragen an siteB.com zu stellen, indem er Ihre Authentifizierungscookies für siteB.com verwendet. Auf diese Weise kann siteA.com die geheimen Informationen stehlen, die Sie mit siteA.com teilen.

Manchmal müssen Sie domänenübergreifend arbeiten, wo CORS ins Spiel kommt. CORS lockert dieselbe Herkunftsrichtlinie für domainA.com und verwendet den Header Access-Control-Allow-Origin um andere Domänen (domainB.com) aufzulisten, deren Ausführung vertrauenswürdig ist JavaScript, das mit domainA.com interagieren kann.

Um zu verstehen, welche Domäne die CORS-Header bedienen soll, beachten Sie dies. Sie besuchen bosic.com, das einige JavaScript-Dateien enthält, mit denen versucht wird, eine domänenübergreifende Anfrage an mybank.com zu stellen. Es sollte an mybank.com, nicht an bosic.com liegen, um zu entscheiden, ob es CORS-Header setzt, die die gleichen Ursprungsrichtlinien lockern, sodass das JavaScript von inicial.com mit ihm interagieren kann. Wenn es für malicous.com möglich wäre, eigene CORS-Header zu setzen, die eigenen JavaScript-Zugriff auf mybank.com erlauben, würde dies die gleiche Herkunftsrichtlinie vollständig aufheben.

Ich denke, der Grund für meine schlechte Intuition ist der Standpunkt, den ich bei der Entwicklung einer Site habe. Es ist meine Seite, mit all meinem JavaScript, deshalb macht es nichts böswilliges und es sollte an mir liegen , anzugeben, auf welchen anderen Seiten mein JavaScript interagieren kann. Wenn ich tatsächlich darüber nachdenke, an welchen anderen Sites JavaScript mit meiner Website interagieren möchte, und sollte ich CORS dafür verwenden?




Wenn Sie PHP verwenden, versuchen Sie, den folgenden Code am Anfang der PHP-Datei hinzuzufügen:

Wenn Sie localhost verwenden, versuchen Sie Folgendes:

header("Access-Control-Allow-Origin: *");

Wenn Sie externe Domänen wie Server verwenden, versuchen Sie Folgendes:

header("Access-Control-Allow-Origin: http://www.website.com");



Verwenden Sie React und Axios , verbinden Sie den Proxy-Link mit der URL und fügen Sie den Header hinzu, wie unten gezeigt

https://cors-anywhere.herokuapp.com/ + Your API URL

Nur durch das Hinzufügen der Proxy-Link funktioniert, aber es kann auch Fehler für keinen Zugriff erneut auslösen. Daher besser, Kopfzeile wie unten gezeigt hinzuzufügen.

axios.get(`https://cors-anywhere.herokuapp.com/[YOUR_API_URL]`,{headers: {'Access-Control-Allow-Origin': '*'}})
      .then(response => console.log(response:data);
  }





Related