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

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

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

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

Ich habe die volle Kontrolle über Site A und Site B. Wie aktiviere ich den von Site A heruntergeladenen Javascript-Code, um mithilfe dieses Headers auf Ressourcen auf Site B zuzugreifen?

PS

Ich möchte JSONP nicht verwenden.

Access-Control-Allow-Originist ein CORS-Header (Cross-Origin Resource Sharing) .

Wenn Site A versucht, Inhalte von Site B abzurufen, kann Site B einen Access-Control-Allow-OriginAntwortheader senden , um dem Browser mitzuteilen, dass der Inhalt dieser Seite für bestimmte Ursprünge zugänglich ist. (Ein Ursprung ist eine Domain sowie ein Schema und eine Portnummer .) Standardmäßig sind die Seiten von Site B keinem anderen Ursprung zugänglich . Die Verwendung des Access-Control-Allow-OriginHeaders öffnet eine Tür für den Cross-Origin-Zugriff durch bestimmte anfordernde Ursprünge.

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

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

Moderne Browser blockieren domänenübergreifende Anfragen nicht direkt. Wenn Site A eine Seite von Site B anfordert, ruft der Browser die angeforderte Seite tatsächlich auf Netzwerkebene ab und prüft, ob in den Antwortheadern Site A als zulässige Anfordererdomäne aufgeführt ist. Wenn Standort B nicht angegeben hat , dass Standort A erlaubt ist , auf dieser Seite zuzugreifen, löst der Browser das XMLHttpRequest‚s errorEreignis und verweigert die Antwortdatum an den anfordernden JavaScript - Code.

Nicht einfache Anfragen

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

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

Wenn der Server auf den OPTIONS-Preflight mit geeigneten Antwortheadern ( Access-Control-Allow-Headersfür nicht einfache Header, Access-Control-Allow-Methodsfür nicht einfache Verben) antwortet, die mit dem nicht einfachen Verb und / oder den nicht einfachen Headern übereinstimmen, sendet der Browser die eigentliche Anforderung.

Angenommen, Site A möchte eine PUT-Anfrage senden , für die der Browser /somePagemit einem nicht einfachen Content-TypeWert von application/jsonzuerst eine Preflight-Anfrage senden würde:

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-Methodund Access-Control-Request-Headersvom Browser automatisch hinzugefügt werden. Sie müssen sie nicht hinzufügen. Dieser OPTIONS-Preflight erhält die erfolgreichen Antwortheader:

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

Beim Senden der eigentlichen Anfrage (nach Abschluss des Preflights) ist das Verhalten identisch mit der Behandlung einer einfachen Anfrage. Mit anderen Worten, eine nicht einfache Anfrage, deren Preflight erfolgreich ist, wird genauso behandelt wie eine einfache Anfrage (dh der Server muss immer noch Access-Control-Allow-Originerneut senden , um die eigentliche Antwort zu erhalten).

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 eine zurück Access-Control-Allow-Origin, genau wie bei einer einfachen Anfrage:

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

Siehe Verständnis XMLHttpRequest über CORS für ein wenig mehr Informationen über nicht-einfache Anfragen.

Cross-Origin Resource Sharing - CORS(AKA-domänenübergreifende AJAX-Anforderung) ist ein Problem, auf das die meisten Webentwickler laut Same-Origin-Policy stoßen könnten. Browser beschränken Client-JavaScript in einer Sicherheits-Sandbox. Normalerweise kann JS nicht direkt mit einem Remote-Server kommunizieren aus einer anderen Domäne. In der Vergangenheit haben Entwickler viele knifflige Methoden entwickelt, um domänenübergreifende Ressourcenanforderungen zu erfüllen. Am häufigsten werden folgende Methoden verwendet:

1. Verwenden Sie Flash / Silverlight oder die Serverseite als "Proxy" für die Kommunikation mit Remote.
2. JSON mit Polsterung ( JSONP ).
3. Betten Sie den Remote-Server in einen Iframe ein und kommunizieren Sie über fragment oder window.name (siehe hier) .

Diese kniffligen Methoden haben mehr oder weniger einige Probleme, zum Beispiel könnte JSONP zu Sicherheitslücken führen, wenn Entwickler es einfach "bewerten", und # 3 oben, obwohl es funktioniert, sollten beide Domänen strenge 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 eine sichere, flexible und empfohlene Standardmethode zur Lösung dieses Problems bereitzustellen.

Der Mechanismus

Auf hoher Ebene können wir einfach davon ausgehen, dass CORS ein Vertrag zwischen dem AJAX-Clientaufruf von Domain A und einer auf Domain 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 Kernfakten. "Origin" -Anforderungsheader "gibt an, woher die Cross-Origin-Anforderung oder Preflight-Anforderung stammt". Der Antwortheader "Access-Control-Allow-Origin" gibt an, dass diese Seite Remote-Anforderungen zulässt DomainA (wenn der Wert * ist, können Sie Remote-Anforderungen von jeder Domain zulassen).

Wie oben erwähnt, hat W3 dem Browser empfohlen, eine " Preflight-Anforderung " zu implementieren, bevor die eigentliche Cross-Origin-HTTP-Anforderung gesendet wird. Kurz gesagt handelt es sich um eine HTTP- OPTIONSAnforderung:

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 ihr Wert "*" ist oder die Domäne enthält, die die CORS-Anforderung gesendet hat, sendet der Browser bei Erfüllung dieser obligatorischen Bedingung die tatsächliche domänenübergreifende Anforderung und speichert das Ergebnis zwischen in " Preflight-Result-Cache ".

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

Die Frage ist etwas zu alt, um sie zu beantworten, aber ich poste sie für zukünftige Verweise auf diese Frage.

Laut diesem Artikel des Mozilla Developer Network

Eine Ressource stellt eine originensübergreifende HTTP-Anforderung, wenn sie eine Ressource von einer anderen Domäne oder einem anderen Port als dem anfordert, den die erste Ressource selbst bedient.

Eine HTML-Seite, die von bereitgestellt wird, http://domain-a.comstellt eine <img>src-Anfrage 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).

Richtlinie mit gleichem Ursprung

Aus Sicherheitsgründen beschränken Browser Ursprungsübergreifende HTTP- Anforderungen, die aus Skripten heraus initiiert werden .
Zum Beispiel, XMLHttpRequestund Fetchfolgen Sie der same-origin policy .
Eine Webanwendung, die HTTP-Anforderungen verwendet XMLHttpRequestoder Fetchnur an ihre eigene Domäne senden kann .

Cross-Origin Resource Sharing (CORS)

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

Der CORS- Mechanismus (Cross-Origin Resource Sharing) bietet Webservern domänenübergreifende Zugriffskontrollen , die sichere domänenübergreifende Datenübertragungen ermöglichen.
Moderne Browser verwenden CORS in einem API-Container - wie XMLHttpRequestoder Fetch-, um das Risiko von Ursprungs-HTTP-Anforderungen zu verringern.

Wie CORS funktioniert ( Access-Control-Allow-OriginHeader)

Wikipedia :

Der CORS-Standard beschreibt neue HTTP-Header, mit denen Browser und Server Remote-URLs nur dann anfordern können, wenn sie über Berechtigungen verfügen.

Obwohl einige Überprüfungen und Autorisierungen vom Server durchgeführt werden können, liegt es im Allgemeinen in der Verantwortung des Browsers , diese Header zu unterstützen und die von ihnen auferlegten Einschränkungen einzuhalten.

Beispiel

1. Der Browser sendet die OPTIONSAnfrage mit einem Origin HTTPHeader.

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

   Herkunft: http://www.example.com

2. Der Server von service.example.comkann antworten mit:

   • Ein Access-Control-Allow-Origin(ACAO) -Header in seiner Antwort, der angibt, welche Ursprungsorte 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: *

Immer wenn ich über CORS nachdenke, ist meine Intuition darüber, auf welcher Site die Header gehostet werden, falsch, genau wie Sie es in Ihrer Frage beschrieben haben. Für mich ist es hilfreich, über den Zweck derselben Ursprungspolitik nachzudenken.

Der Zweck derselben Ursprungsrichtlinie besteht darin, Sie vor böswilligem JavaScript auf siteA.com zu schützen, das auf private Informationen zugreift, die Sie nur für siteB.com freigeben möchten. Ohne dieselbe Ursprungsrichtlinie könnte JavaScript, das von den Autoren von siteA.com geschrieben wurde, Ihren Browser dazu bringen, Anfragen an siteB.com zu richten, indem er Ihre Authentifizierungscookies für siteB.com verwendet. 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. Hier kommt CORS ins Spiel. CORS lockert die gleiche Ursprungsrichtlinie für domainB.com und verwendet den Access-Control-Allow-OriginHeader, um andere Domänen (domainA.com) aufzulisten, denen JavaScript zur Ausführung mit domainA als vertrauenswürdig eingestuft wird. com.

Berücksichtigen Sie dies, um zu verstehen, welche Domäne die CORS-Header bedienen soll. Sie besuchen malicious.com, das JavaScript enthält, das versucht, eine domänenübergreifende Anfrage an mybank.com zu stellen. Es sollte an mybank.com und nicht an böswilliger Partei liegen, zu entscheiden, ob CORS-Header festgelegt werden, die dieselbe Ursprungsrichtlinie lockern, sodass das JavaScript von malicious.com mit ihm interagieren kann. Wenn malicous.com eigene CORS-Header festlegen könnte, die einen eigenen JavaScript-Zugriff auf mybank.com ermöglichen, würde dies dieselbe Ursprungsrichtlinie vollständig ungültig machen.

Ich denke, der Grund für meine schlechte Intuition ist der Standpunkt, den ich bei der Entwicklung einer Website habe. Es ist meine Website mit all meinem JavaScript, daher macht es nichts Bösartiges und es sollte an mir liegen , anzugeben, mit welchen anderen Websites mein JavaScript interagieren kann. Wann sollte ich tatsächlich überlegen, welche anderen Websites JavaScript versucht, mit meiner Website zu interagieren, und sollte ich CORS verwenden, um sie zuzulassen?

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

Der Code, der das Herunterladen durchführt - Ihr HTML-Skript-Tag oder xhr aus Javascript oder was auch immer - stammt beispielsweise von http: // siteZ . Und wenn der Browser MyCode.js anfordert, sendet er einen Origin: -Header mit der Aufschrift "Origin: http: // siteZ ", da er sieht, dass Sie an siteA und siteZ! = SiteA anfordern. (Sie können dies 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 Ursprungsübergreifende Verweise auf die Site B erstellen durfte.

Nein. Dies bedeutet, dass nur siteB diese Anforderung ausführen darf. Ihre Anfrage nach MyCode.js von siteZ erhält stattdessen einen Fehler, und der Browser gibt Ihnen normalerweise nichts. Wenn Sie Ihren Server jedoch dazu bringen, ACAO: siteZ zurückzugeben, erhalten Sie MyCode.js. Oder wenn es '*' sendet, funktioniert das, das lässt alle herein. Oder wenn der Server die Zeichenfolge 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 Anforderungen stellen dürfen.

Dann kommt MyCode.js von siteA. Wenn Anfragen an siteB gestellt werden, handelt es sich alle um Cross-Origin-Anfragen. Der Browser sendet Origin: siteA, und siteB muss die SiteA übernehmen, erkennen, dass sie auf der kurzen Liste der zulässigen Anforderer steht, und ACAO: siteA zurücksenden. Nur dann lässt der Browser Ihr Skript das Ergebnis dieser Anforderungen abrufen.

Verwenden von React und AxiosVerbinden Sie den Proxy-Link mit der URL und fügen Sie den Header wie unten gezeigt hinzu

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

Nur durch Hinzufügen des Proxy-Links funktioniert es, aber es kann auch wieder Fehler für No Access auslösen. 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);
  }

WARNUNG: Nicht in der Produktion verwenden

Dies ist nur eine schnelle Lösung. Wenn Sie Probleme haben, warum Sie keine Antwort erhalten, können Sie diese verwenden. Aber es ist wieder so nicht die beste Antwort für die Produktion.

Ich habe mehrere Abstimmungen erhalten und es ist völlig sinnvoll, ich hätte die Warnung schon vor langer Zeit hinzufügen sollen.

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 ohne Ihren Code unsicher zu machen. Unter MAC OS können Sie dies über die Terminalleitung tun:

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

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");

Ich arbeite mit Express 4 und Node 7.4 und Angular. Ich hatte das gleiche Problem. Ich helfe dabei:
a) Serverseite: In der Datei app.js gebe ich allen Antworten Header wie:

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();
 });  

Dies muss vor allen Router haben .
Ich habe viele dieser Header hinzugefügt gesehen:

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 musst du hinzufügen: "withCredentials: true", wie:

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

Viel Glück.

Legen Sie für die Ursprungsfreigabe die Überschrift fest: 'Access-Control-Allow-Origin':'*';

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

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

Auf diese Weise können Inhalte für verschiedene Domänen freigegeben werden.

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

Installation:

$ pip install -U flask-cors

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!"

Weitere Beispiele finden Sie in der Dokumentation. Ich habe das obige einfache Beispiel verwendet, um das CORS-Problem in einer von mir erstellten Ionenanwendung zu umgehen, die auf einen separaten Kolbenserver zugreifen muss.

Aus meiner eigenen Erfahrung ist es schwierig, eine einfache Erklärung zu finden, warum CORS überhaupt ein Problem darstellt.

Sobald Sie verstehen, warum es dort ist, werden die Überschriften und die Diskussion viel klarer. Ich werde es in ein paar Zeilen versuchen.

Es geht nur um Cookies. Cookies werden von ihrer Domain auf einem Client gespeichert.

Eine Beispielgeschichte: Auf Ihrem Computer gibt es ein Cookie für yourbank.com. Vielleicht ist Ihre Sitzung dort.

Wichtiger Punkt: Wenn ein Client eine Anfrage an den Server stellt, sendet er die Cookies, die unter der Domäne gespeichert sind, in der sich der Client befindet.

Sie sind in Ihrem Browser bei angemeldet yourbank.com. Sie möchten alle Ihre Konten anzeigen. yourbank.comempfängt den Stapel Cookies und sendet seine Antwort (Ihre Konten) zurück.

Wenn ein anderer Client eine Cross-Origin- Anfrage an einen Server stellt, werden diese Cookies wie zuvor gesendet. Ruh roh.

Sie navigieren zu malicious.com. Malicious stellt eine Reihe von Anfragen an verschiedene Banken, einschließlich yourbank.com.

Da die Cookies wie erwartet validiert werden, autorisiert der Server die Antwort.

Diese Cookies werden gesammelt und mitgeschickt - und haben jetzt malicious.comeine Antwort von yourbank.

Huch.

Nun werden einige Fragen und Antworten offensichtlich:

• "Warum blockieren wir den Browser nicht einfach daran?" Ja. CORS.
• "Wie kommen wir darum herum?" Lassen Sie den Server der Anfrage mitteilen, dass CORS in Ordnung ist.

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

Beachten Sie, dass Sie den folgenden Code unter <system.webServer>tag 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>  

Der Antwortheader Access-Control-Allow-Origin gibt an, ob die Antwort mit dem Anfordern von Code vom angegebenen Ursprung geteilt werden kann.

Header type Response       header
Forbidden header name      no

Eine Antwort, die den Browser anweist, Code von jedem Ursprung den Zugriff auf eine Ressource zuzulassen, enthält Folgendes:

Access-Control-Allow-Origin: *

Weitere Informationen finden Sie hier ....

Nginx und Appache

Als Ergänzung zur Antwort von apsillers möchte ich ein Wiki-Diagramm hinzufügen, das zeigt , ob die Anfrage einfach ist oder nicht (und die OPTIONS-Anfrage vor dem Flug gesendet wird oder nicht).

Für einfache Anfragen (z. B. Hotlinking-Bilder ) müssen Sie Ihre Serverkonfigurationsdateien nicht ändern, aber Sie können Header in Anwendungen (auf Servern gehostet, z. B. in PHP) hinzufügen, wie Melvin Guerrero in seiner Antwort erwähnt - aber denken Sie daran Sie : Wenn Sie vollständig hinzufügen cors-Header in Ihrem Server (config) und gleichzeitig erlauben Sie einfache cors in der Anwendung (z. B. PHP), dies funktioniert überhaupt nicht.

Und hier sind Konfigurationen für zwei beliebte Server

• einschalten CORS auf Nginx ( nginx.confDatei)

  Code-Snippet anzeigen

  location ~ ^/index\.php(/|$) {
     ...
      add_header 'Access-Control-Allow-Origin' "$http_origin" always; # if you change "$http_origin" to "*" you shoud get same result - allow all domain to CORS (but better change it to your particular domain)
      add_header 'Access-Control-Allow-Credentials' 'true' always;
      if ($request_method = OPTIONS) {
          add_header 'Access-Control-Allow-Origin' "$http_origin"; # DO NOT remove THIS LINES (doubled with outside 'if' above)
          add_header 'Access-Control-Allow-Credentials' 'true';
          add_header 'Access-Control-Max-Age' 1728000; # cache preflight value for 20 days
          add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';  # arbitrary methods
          add_header 'Access-Control-Allow-Headers' 'My-First-Header,My-Second-Header,Authorization,Content-Type,Accept,Origin'; # arbitrary headers
          add_header 'Content-Length' 0;
          add_header 'Content-Type' 'text/plain charset=UTF-8';
          return 204;
      }
  }

  Führen Sie das Code-Snippet ausErgebnisse ausblenden

  Erweitern Sie das Snippet

• einschalten CORS auf Appache ( .htaccessDatei)

  Code-Snippet anzeigen

  # ------------------------------------------------------------------------------
  # | Cross-domain Ajax requests                                                 |
  # ------------------------------------------------------------------------------
  
  # Enable cross-origin Ajax requests.
  # http://code.google.com/p/html5security/wiki/CrossOriginRequestSecurity
  # http://enable-cors.org/
  
  # change * (allow any domain) below to your domain
  Header set Access-Control-Allow-Origin "*"
  Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
  Header always set Access-Control-Allow-Headers "My-First-Header,My-Second-Header,Authorization, content-type, csrf-token"
  Header always set Access-Control-Allow-Credentials "true"

  Führen Sie das Code-Snippet ausErgebnisse ausblenden

  Erweitern Sie das Snippet