it-swarm.com.de

Wie funktioniert der Access-Control-Allow-Origin-Header?

Anscheinend habe ich seine Semantik völlig missverstanden. Ich habe an so etwas gedacht:

  1. Ein Client lädt den Javascript-Code MyCode.js von http: // siteA - the Origin herunter.
  2. Der Antwortheader von MyCode.js enthält Access-Control-Allow-Origin: http: // siteB, was meiner Meinung nach bedeuten sollte, dass MyCode.js Querverweise auf die Site B verweisen konnte.
  3. Der Client löst einige Funktionen von MyCode.js aus, die wiederum Anfragen an http: // siteB absenden, was trotz der Herkunftsnachweise in Ordnung sein sollte.

Ich bin falsch. Es funktioniert überhaupt nicht so. Also habe ich Cross-Origin Resource Sharing gelesen und/versucht zu lesen Cross-Origin Resource Sharing in der w3c-Empfehlung

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

Ich habe vollständige Kontrolle über Site A und Site B. Wie kann ich den von Site A heruntergeladenen Javascript-Code aktivieren, um auf Ressourcen auf Site B mithilfe dieses Headers zuzugreifen?

P.S.

Ich möchte JSONP nicht nutzen.

891
mark

Access-Control-Allow-Origin ist ein CORS-Header [Cross-Origin Resource Sharing] .

Wenn Site A versucht, Inhalt von Site B abzurufen, kann Site B einen Access-Control-Allow-Origin-Antwortheader senden, um dem Browser mitzuteilen, dass der Inhalt dieser Seite für bestimmte Herkunft zugänglich ist. (Ein Origin ist eine Domäne plus ein Schema und eine Portnummer .) Standardmäßig sind die Seiten von Site B nicht für andere Origin zugänglich. Die Verwendung des Access-Control-Allow-Origin-Headers öffnet eine Tür für den Ursprungszugriff von verschiedenen Ursprungsorten.

Für jede Ressource/Seite, die Site B Site A zugänglich machen möchte, sollte Site B ihre Seiten mit dem Antwortheader bereitstellen:

Access-Control-Allow-Origin: http://siteA.com

Moderne Browser blockieren keine domänenübergreifenden Anforderungen. Wenn Site A eine Seite von Site B anfordert, ruft der Browser tatsächlich die angeforderte Seite auf Netzwerkebene ab und prüft, ob der Antwortheader Site A als zulässige Anforderungsdomäne aufgeführt ist. Wenn Site B nicht angegeben hat, dass Site A auf diese Seite zugreifen darf, löst der Browser das Ereignis XMLHttpRequest der Variable error aus und verweigert dem anfragenden JavaScript-Code die Antwortdaten.

Nicht einfache Anfragen

Was auf Netzwerkebene geschieht, kann etwas komplexer sein als oben erläutert. Wenn es sich bei der Anforderung um eine "nicht einfache" Anforderung handelt, sendet der Browser zunächst eine datenlose "Preflight" -Option, um zu überprüfen, ob der Server die Anforderung akzeptiert. Eine Anfrage ist nicht einfach, wenn entweder (oder beide):

  • verwenden eines anderen HTTP-Verbs als GET oder POST (z. B. PUT, DELETE)
  • verwenden von nicht einfachen Anforderungsheadern; Die einzigen einfachen Anforderungsheader sind:
    • Accept
    • Accept-Language
    • Content-Language
    • Content-Type (dies ist nur einfach, wenn der Wert application/x-www-form-urlencoded, multipart/form-data oder text/plain lautet)

Wenn der Server auf das OPTIONS-Preflight mit entsprechenden Antwortheatern (Access-Control-Allow-Headers für nicht einfache Header, Access-Control-Allow-Methods für nicht einfache Verben) reagiert, die mit dem nicht einfachen Verb und/oder nicht einfachen Header übereinstimmen, sendet der Browser die eigentliche Anforderung.

Angenommen, Site A möchte eine PUT-Anforderung für /somePage senden, mit einem nicht einfachen Content-Type-Wert von application/json. Der Browser sendet zunächst eine Preflight-Anforderung:

OPTIONS /somePage HTTP/1.1
Origin: http://siteA.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type

Beachten Sie, dass Access-Control-Request-Method und Access-Control-Request-Headers automatisch vom Browser hinzugefügt werden. Sie müssen sie nicht hinzufügen. Dieser OPTIONS-Preflight ruft die erfolgreichen Antwortheader ab:

Access-Control-Allow-Origin: http://siteA.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type

Beim Senden der aktuellen Anfrage (nach dem Preflight) ist das Verhalten identisch mit der Behandlung einer einfachen Anfrage. Mit anderen Worten, eine nicht einfache Anforderung, deren Preflight erfolgreich ist, wird genauso behandelt wie eine einfache Anforderung (d. H. Der Server muss noch Access-Control-Allow-Origin für die tatsächliche Antwort erneut senden).

Der Browser sendet die eigentliche Anfrage:

PUT /somePage HTTP/1.1
Origin: http://siteA.com
Content-Type: application/json

{ "myRequestContent": "JSON is so great" }

Und der Server sendet einen Access-Control-Allow-Origin zurück, genau wie bei einer einfachen Anfrage:

Access-Control-Allow-Origin: http://siteA.com

Weitere Informationen zu nicht einfachen Anforderungen finden Sie unter Verstehen von XMLHttpRequest über CORS .

1150
apsillers

Cross-Origin Request-Freigabe - CORS (AKA-domänenübergreifende AJAX - Anfrage) ist ein Problem, auf das die meisten Webentwickler stoßen könnten. Gemäß der Same-Origin-Richtlinie beschränken Browser Client-JavaScript in einer Sicherheits-Sandbox. In der Regel kann JS dies nicht direkt tun Kommunikation mit einem Remote-Server aus einer anderen Domäne. In der Vergangenheit haben Entwickler viele knifflige Methoden entwickelt, um eine domänenübergreifende Ressourcenanforderung zu erreichen. Am häufigsten werden folgende Methoden verwendet:

  1. Verwenden Sie Flash/Silverlight oder die Serverseite als "Proxy", um mit dem Remote zu kommunizieren. 
  2. JSON mit Auffüllung ( JSONP ). 
  3. Fügt den Remote-Server in einen iframe ein und kommuniziert über fragment oder window.name, siehe hier .

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

Das W3C hatte Cross-Origin Resource Sharing (CORS) als Standardlösung eingeführt, um eine sichere, flexible und empfohlene Standardlösung für dieses Problem zu bieten. 

Der Mechanismus

Von einem hohen Niveau aus können wir einfach feststellen, dass CORS ein Vertrag zwischen dem Aufruf von Client AJAX von Domäne A und einer in Domäne B gehosteten Seite ist. 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 wichtigsten Fakten. Der Header "Ursprung" -Anforderung "gibt an, woher die Anfrage oder die Preflight-Anfrage zwischen Herkunft stammt". Der Antwortheader "Access-Control-Allow-Origin" zeigt an, dass diese Seite eine Remote-Anforderung zulässt DomainA (wenn der Wert * bedeutet, dass Remoteanforderungen von einer beliebigen Domäne zulässig sind).

Wie bereits erwähnt, empfahl W3 dem Browser, eine "preflight-Anforderung" zu implementieren, bevor die eigentliche Cross-Origin-HTTP-Anforderung übermittelt wird. Kurz gesagt, handelt es sich um eine HTTP-Variable OPTIONS:

OPTIONS DomainB.com/foo.aspx HTTP/1.1

Wenn foo.aspx das HTTP-Verb "OPTIONS" unterstützt, wird möglicherweise die folgende Antwort zurückgegeben:

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 der Wert "*" ist oder die Domäne enthält, von der die CORS-Anforderung gesendet wurde, wird der Browser die tatsächliche domänenübergreifende Anforderung erfüllen und das Ergebnis zwischenspeichern in "Preflight-Ergebnis-Cache".

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

107
Wayne Ye

Die Frage ist ein bisschen zu alt für die Beantwortung, aber ich poste dies für jeden zukünftigen Verweis auf diese Frage.

Gemäß diesem Mozilla Developer Network-Artikel:

Eine Ressource erstellt eine Cross-Origin-HTTP-Anforderung, wenn sie eine Ressource von einer anderen Domäne oder einem anderen Port als dem angefordert, den die erste Ressource selbst bereitstellt.

 enter image description here

Eine HTML-Seite, die von http://domain-a.com bereitgestellt wird, stellt eine <img> src-Anforderung für http://domain-b.com/image.jpg.
Viele Seiten im Web laden heute Ressourcen wie CSS-Stylesheets, Bilder und Skripte aus separaten Domänen (daher sollte es cool sein).

Same-Origin-Richtlinie

Aus Sicherheitsgründen schränken Browser Cross-Origin HTTP Requests aus Skripten initiiert ein.
Zum Beispiel folgen XMLHttpRequest und Fetch der Same-Origin-Richtlinie.
Eine Webanwendung, die XMLHttpRequest oder Fetch verwendet, konnte HTTP-Anforderungen nur zu ihrer eigenen Domäne machen.

Ressourcenübergreifende Ressourcenfreigabe (CORS)

Um Webanwendungen zu verbessern, baten die Entwickler Browseranbieter, domänenübergreifende Anforderungen zuzulassen.

Der Mechanismus Cross-Origin Resource Sharing (CORS) gibt Web-Servern domänenübergreifende Zugriffskontrollen an, die eine sichere domänenübergreifende Datenübertragung ermöglichen.
Moderne Browser verwenden CORS in einem API-Container - wie XMLHttpRequest oder Fetch -, um die Risiken von Origin-HTTP-Anforderungen zu verringern.

Funktionsweise von CORS (Access-Control-Allow-Origin-Header)

Wikipedia :

Der CORS-Standard beschreibt neue HTTP-Header, die es Browsern und Servern ermöglichen, Remote-URLs nur dann anzufordern, wenn sie dazu berechtigt sind.

Obwohl der Server einige Überprüfungen und Autorisierungen durchführen kann, ist es liegt in der Regel im Verantwortungsbereich des Browsers, diese Header zu unterstützen und die damit verbundenen Einschränkungen zu beachten.

Beispiel

  1. Der Browser sendet die OPTIONS-Anforderung mit einem Origin HTTP-Header. 

    Der Wert dieses Headers ist die Domäne, die die übergeordnete Seite bedient hat. Wenn eine Seite aus http://www.example.com versucht, auf die Daten eines Benutzers in service.example.com zuzugreifen, wird der folgende Anforderungsheader an service.example.com gesendet:

    Herkunft: http://www.example.com

  2. Der Server unter service.example.com antwortet möglicherweise mit:

    • Ein Access-Control-Allow-Origin (ACAO) -Header in seiner Antwort, der angibt, welche Origin-Sites zulässig sind.
      Zum Beispiel: 

      Access-Control-Allow-Origin: http://www.example.com

    • Eine Fehlerseite, wenn der Server die Cross-Origin-Anforderung nicht zulässt

    • Ein Access-Control-Allow-Origin (ACAO) -Header mit einem Platzhalter, der alle Domänen zulässt:

      Access-Control-Allow-Origin: *

42
Trix

Fügen Sie mithilfe von React und Axios einen Proxy-Link zur URL hinzu und fügen Sie den Header hinzu, wie unten gezeigt

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

Nur durch das Hinzufügen des Proxy-Links wird es funktionieren, aber es kann auch wieder ein Fehler für No Access ausgelöst werden. Daher ist es besser, den Header 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);
  }
8
Dhaval Jardosh

Wenn Sie nur eine domänenübergreifende Anwendung testen möchten, in der der Browser Ihre Anforderung blockiert, können Sie Ihren Browser im unsicheren Modus öffnen und Ihre Anwendung testen, ohne Ihren Code zu ändern und Ihren Code nicht unsicher zu machen kann dies von der Terminalleitung aus:

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

Wann immer ich anfange, über CORS nachzudenken, ist meine Intuition darüber, welche Site die Header hostet, falsch, genau wie Sie es in Ihrer Frage beschrieben haben. Für mich hilft es, über den Zweck derselben Origin-Richtlinie nachzudenken.

Diese Origin-Richtlinie dient dazu, Sie vor schädlichem JavaScript auf siteA.com zu schützen, das auf private Informationen zugreift, die Sie nur für siteB.com freigegeben haben. Ohne die gleiche Origin-Richtlinie könnte JavaScript, das von den Autoren von siteA.com verfasst wurde, Ihren Browser dazu veranlassen, Anforderungen an siteB.com zu senden, wobei Ihre Authentifizierungs-Cookies für siteB.com verwendet werden. Auf diese Weise könnte siteA.com die geheimen Informationen stehlen, die Sie mit siteB.com teilen.

Manchmal müssen Sie domänenübergreifend arbeiten, wo CORS eingesetzt wird. CORS lockert dieselbe Origin-Richtlinie für domainA.com. Verwenden Sie den Header Access-Control-Allow-Origin, um andere Domänen (domainB.com) aufzulisten, die vertrauenswürdig sind, um JavaScript auszuführen, das mit domainA interagieren kann .com.

Um zu verstehen, welche Domain die CORS-Header bedienen soll, sollten Sie dies berücksichtigen. Sie besuchen böswill.com, die JavaScript enthält, mit dem versucht wird, eine domänenübergreifende Anfrage an mybank.com zu stellen. Es sollte Sache von mybank.com und nicht vonicious.com sein, zu entscheiden, ob CORS-Header festgelegt werden, durch die die gleiche Origin-Richtlinie gelockert wird, sodass JavaScript und bomix.com mit ihm interagieren können. Wenn malicous.com eigene CORS-Header festlegen könnte, die eigenen JavaScript-Zugriff auf mybank.com zulassen, würde dies die gleiche Origin-Richtlinie vollständig aufheben. 

Ich denke, der Grund für meine schlechte Intuition ist der Standpunkt, den ich bei der Entwicklung einer Website habe. Es ist my site mit all my JavaScript. Daher ist es nicht böswillig, und es sollte Aufgabe von me sein, anzugeben, mit welchen anderen Sites my JavaScript interagiert werden kann . Wann sollte ich eigentlich darüber nachdenken, welche anderen Websites JavaScript versucht, mit meiner Website zu interagieren, und sollte ich CORS verwenden, um sie zuzulassen? 

7
Dom

1. Ein Client lädt den Javascript-Code MyCode.js von http: // siteA - Origin herunter.

Der Code, der das Herunterladen übernimmt - Ihr HTML-Skript-Tag oder Xhr aus Javascript oder was auch immer - kam von http: // siteZ . Wenn der Browser MyCode.js anfordert, sendet er einen Origin: -Header mit der Aufschrift "Origin: http: // siteZ ", da er sehen kann, dass Sie siteA und siteZ! = SiteA anfordern. (Sie können das nicht stoppen oder stören.)

2. Der Antwortheader von MyCode.js enthält Access-Control-Allow-Origin: http: // siteB , was meiner Meinung nach bedeutete, dass MyCode.js Querverweise auf die Site B verweisen konnte

nein. Das bedeutet, dass nur SiteB diese Anfrage ausführen darf. Ihre Anfrage nach MyCode.js von siteZ wird stattdessen mit einem Fehler angezeigt, und der Browser gibt normalerweise nichts aus. Wenn Sie jedoch dafür sorgen, dass Ihr Server stattdessen A-C-A-O: siteZ zurückgibt, erhalten Sie MyCode.js. Oder wenn es '*' sendet, funktioniert das, das lässt jeden rein. Oder wenn der Server den String immer aus dem Origin: Header sendet ... aber aus Sicherheitsgründen, wenn Sie Angst vor Hackern haben Ihr Server sollte nur Ursprünge auf einer Shortlist zulassen, die diese Anfragen stellen dürfen.

Dann kommt MyCode.js von SiteA. Wenn Anforderungen an siteB gestellt werden, handelt es sich um Cross-Origin-Verbindungen, der Browser sendet Origin: siteA, und siteB muss die WebsiteA übernehmen, erkennt, dass sie in der kurzen Liste der zugelassenen Anforderer steht, und sendet A-C-A-O: siteA zurück. Erst dann lässt der Browser Ihr Skript das Ergebnis dieser Anfragen erhalten.

6
OsamaBinLogin

ich arbeite mit express 4 und node 7.4 und angle, ich hatte das gleiche problem, mir dabei zu helfen:
a) Server-Seite: In der Datei app.js gebe ich allen Antworten die folgenden Header:

app.use(function(req, res, next) {  
      res.header('Access-Control-Allow-Origin', req.headers.Origin);
      res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
      next();
 });  

das muss vorher alle router haben .
Ich sah viele dieser Header hinzugefügt:

res.header("Access-Control-Allow-Headers","*");
res.header('Access-Control-Allow-Credentials', true);
res.header('Access-Control-Allow-Methods', 'GET,PUT,POST,DELETE');

aber ich brauche das nicht,
b) clientseitig: In send ajax müssen Sie Folgendes hinzufügen: "withCredentials: true" wie:

$http({
     method: 'POST',
     url: 'url, 
     withCredentials: true,
     data : {}
   }).then(function(response){
        // code  
   }, function (response) {
         // code 
   });

viel Glück.

6
izik f

Wenn Sie PHP verwenden, versuchen Sie, den folgenden Code am Ende 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");
3
Melvin Guerrero

Für die gemeinsame Nutzung von Origin setzen Sie den Header: 'Access-Control-Allow-Origin':'*';

Php: header('Access-Control-Allow-Origin':'*');

Knoten: app.use('Access-Control-Allow-Origin':'*');

Dies ermöglicht das Teilen von Inhalten für verschiedene Domänen.

2
suryadev

In Python habe ich die Flask-CORS-Bibliothek mit großem Erfolg verwendet. Es macht den Umgang mit CORS sehr einfach und schmerzlos. Ich habe etwas Code aus der Dokumentation der Bibliothek hinzugefügt. 

Installation:

$ pip install -U flask-cors

Ein einfaches Beispiel, das CORS für alle Domänen auf allen Routen ermöglicht:

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app)

@app.route("/")
def helloWorld():
  return "Hello, cross-Origin-world!"

Genauere Beispiele finden Sie in der Dokumentation. Ich habe das einfache Beispiel oben verwendet, um das CORS-Problem in einer ionischen Anwendung zu umgehen, die ich baue und auf einen separaten Flopserver zugreifen muss.

2
agaidis

Der Antwortheader für Access-Control-Allow-Origin gibt an, ob der Die Antwort kann mit dem anfordernden Code des angegebenen Ursprungs geteilt werden.

Header type Response       header
Forbidden header name      no

Eine Antwort, die den Browser anweist, Code aus einem beliebigen Ursprung in .__ zuzulassen. Zugriff auf eine Ressource umfasst Folgendes:

Access-Control-Allow-Origin: *

Für weitere Informationen besuchen Sie hier ....

0
Alireza

Fügen Sie einfach den folgenden Code in Ihre web.config-Datei ein.

Beachten Sie, dass Sie den folgenden Code unter dem Tag <system.webServer> einfügen müssen

    <httpProtocol>  
    <customHeaders>  
     <add name="Access-Control-Allow-Origin" value="*" />  
     <add name="Access-Control-Allow-Headers" value="Content-Type" />  
     <add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" />  
    </customHeaders>  
  </httpProtocol>  
0
Juboraj Sarker