[6]}Cross-Origin Request Sharing - CORS (Aka Cross-Domain AJAX request) to problem, który może napotkać większość programistów internetowych, zgodnie z zasadami tego samego pochodzenia, przeglądarki ograniczają JavaScript Klienta w piaskownicy bezpieczeństwa, Zwykle JS nie może bezpośrednio komunikować się ze zdalnym serwerem z innej domeny. W przeszłości programiści stworzyli wiele trudnych sposobów na osiągnięcie żądania zasobów między domenami, najczęściej używanymi sposobami są: {]}

1. użyj Flash/Silverlight lub po stronie serwera jako " proxy" komunikować się z pilotem.
2. JSON With Padding (JSONP ).
3. osadza zdalny serwer w ramce iframe i komunikuje się poprzez fragment lub window.name, patrz tutaj .

Te trudne sposoby mają mniej więcej pewne problemy, na przykład JSONP może spowodować dziurę w bezpieczeństwie, jeśli deweloperzy po prostu "eval" go, a #3 powyżej, chociaż to działa, obie domeny powinny budować ścisły kontrakt między sobą, to ani elastyczne, ani eleganckie IMHO:) {]}

W3C miał wprowadzono Cross-Origin Resource Sharing (CORS) jako standardowe rozwiązanie, aby zapewnić bezpieczny, elastyczny i zalecany standardowy sposób rozwiązania tego problemu.

Mechanizm

Z wysokiego poziomu możemy po prostu uznać, że CORS jest umową między Klientem AJAX wywołania z domeny a i strony hostowanej na domenie B, typowy Cross-Origin żądanie / odpowiedź będzie:

DomainA AJAX request headers

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 

Odpowiedź DomainB nagłówki

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

Niebieskie części, które zaznaczyłem powyżej, to fakty kernal, nagłówek żądania" Origin "wskazuje, skąd pochodzi żądanie cross-origin lub żądanie inspekcji wstępnej", nagłówek odpowiedzi "Access-Control-Allow-Origin" wskazuje, że ta strona pozwala na zdalne żądanie z domeny (jeśli wartość to * indicate pozwala na zdalne żądania z dowolnej domeny).

Jak wspomniałem powyżej, W3 zaleca przeglądarce zaimplementować "preflight request " przed złożeniem Cross-Origin HTTP request, w skrócie jest to http OPTIONS request:

OPTIONS DomainB.com/foo.aspx HTTP/1.1

If foo.aspx obsługuje opcje http verb, może zwrócić odpowiedź jak poniżej:

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

Tylko jeśli odpowiedź zawiera "Access-Control-Allow-Origin", a jej wartością jest "*" lub zawiera domenę, która przesłała żądanie CORS, spełniając ten warunek mandtory przeglądarka wyśle rzeczywiste żądanie między domenami i wywoła wynik w pamięci podręcznej " Preflight-Result-Cache".

Blogowałem o CORS trzy lata temu: AJAX Cross-Origin HTTP request

Pytanie jest trochę za Stare, aby odpowiedzieć, ale zamieszczam to w przyszłości odniesienia do tego pytania.

[20]}zasób wysyła żądanie HTTP cross-origin , gdy żąda zasobu z innej domeny lub portu niż ten, do którego służy pierwszy zasób.

Strona HTML serwowana z http://domain-a.com tworzy <img> src wniosek o http://domain-b.com/image.jpg.
Wiele stron w sieci ładuje dziś zasoby takie jak arkusze stylów CSS , obrazy i Skrypty z oddzielnych domen (więc powinno być fajnie).

Polityka Tego Samego Pochodzenia

Cross-Origin Resource Sharing (CORS)

Aby ulepszyć aplikacje internetowe, Programiści zwrócili się do dostawców przeglądarek o zezwolenie na żądania między domenami.

Jak działa CORS (Access-Control-Allow-Origin header)

Wikipedia:

Standard CORS opisuje nowe nagłówki HTTP, które zapewniają przeglądarkom i serwerom możliwość żądania zdalnych adresów URL tylko wtedy, gdy mają uprawnienia.

Chociaż niektóre walidacje i autoryzacje mogą być wykonywane przez Serwer, jest ogólnie obowiązkiem przeglądarki , aby wspierać te nagłówki i szanować nakładają ograniczenia.

Przykład

1. Przeglądarka wysyła zapytanie OPTIONS z nagłówkiem Origin HTTP.

   Wartością tego nagłówka jest domena, która obsługiwała Stronę nadrzędną. Gdy strona z http://www.example.com próbuje uzyskać dostęp do danych użytkownika w service.example.com, następujący nagłówek żądania zostanie wysłany do service.example.com:

   Pochodzenie: http://www.example.com

2. Serwer na service.example.com może odpowiedzieć:

   • An Access-Control-Allow-Origin (ACAO) nagłówek w odpowiedzi wskazujący, które miejsca pochodzenia są dozwolone.
     Na przykład:

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

   • Strona błędu, jeśli serwer nie zezwala na żądanie cross-origin

   • Nagłówek Access-Control-Allow-Origin (ACAO) z symbolem wieloznacznym, który pozwala na wszystkie domeny:

     Access-Control-Allow-Origin: *

Jeśli chcesz po prostu przetestować aplikację cross domain, w której przeglądarka blokuje twoje żądanie, możesz po prostu otworzyć przeglądarkę w trybie niebezpiecznym i przetestować aplikację bez zmiany kodu i bez uczynienia kodu niebezpiecznym. Z MAC OS można to zrobić z linii terminala:

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

Używając React i Axios, Dołącz łącze proxy do adresu URL i dodaj nagłówek, jak pokazano poniżej

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

Po prostu dodając link Proxy będzie działać, ale może również rzucić błąd dla braku dostępu ponownie. Dlatego lepiej dodać nagłówek, jak pokazano poniżej.

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

1. Klient pobiera kod javascript MyCode.js z http://siteA - pochodzenie.

Kod, który pobiera - Twój znacznik HTML script lub xhr z javascript lub cokolwiek innego-pochodzi z, powiedzmy, http://siteZ . I, gdy przeglądarka zażąda MyCode.js, wysyła nagłówek Origin: mówiący " Origin: http://siteZ ", ponieważ widać, że prosisz o siteA i siteZ!= siteA. (Nie można zatrzymać ani ingerować w to.)

2. Nagłówek odpowiedzi MyCode.js zawiera Access-Control-Allow-Origin: http://siteB , co myślałem, że oznacza to MyCode.js mógł tworzyć odniesienia do strony B.

Nie. Oznacza to, że tylko siteB może wykonać to żądanie. Więc twoja prośba o MyCode.zamiast tego js z siteZ pobiera błąd, a przeglądarka zazwyczaj nie daje nic. Ale jeśli sprawisz, że twój serwer zwróci A-C-A-o: siteZ, otrzymasz MyCode.js . Lub jeśli to wysyła"*", to zadziała, to wpuści wszystkich. Lub jeżeli serwer zawsze wysyła łańcuch z nagłówka Origin:... ale... dla bezpieczeństwa, jeśli boisz się hakerów, Twój serwer powinien zezwalać tylko na origins na krótkiej liście, które mogą składać te żądania.

Wtedy MyCode.js pochodzi z siteA. Kiedy wysyła żądania do siteB, wszystkie są cross-origin, przeglądarka wysyła Origin: siteA, a siteB musi wziąć siteA, rozpoznać, że znajduje się na krótkiej liście dozwolonych żądań i odeślij A-C-a-o: siteA. Dopiero wtedy przeglądarka pozwoli Twojemu skryptowi uzyskać wynik tych żądań.

Pracuję z Expressem 4 i node 7.4 i angular, miałem ten sam problem pomagam w tym:
a) strona serwera: w aplikacji plik.js daję nagłówki do wszystkich odpowiedzi typu:

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

To musi mieć przed wszystkimi routerami .
Widziałem wiele dodanych nagłówków:

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

Ale nie potrzebuję tego,
b) po stronie klienta: w send ajax musisz dodać: "withCredentials: true", jak:

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

Ilekroć zaczynam myśleć o CORS, moja intuicja co do tego, która strona hostuje nagłówki, jest niepoprawna, tak jak opisałeś w swoim pytaniu. Dla mnie pomaga myślenie o celu tej samej polityki pochodzenia.

Celem tej samej polityki pochodzenia jest ochrona przed złośliwym JavaScript na siteA.com dostęp do prywatnych informacji, z którymi chcesz się dzielić siteB.com. bez tej samej polityki pochodzenia, JavaScript napisany przez autorów siteA.com może sprawić, że Twoje przeglądarka wysyła żądania do siteB.com, korzystanie z plików cookie uwierzytelniających dla siteB.com w ten sposób, siteA.com może ukraść tajne informacje, którymi się dzielisz siteA.com.

Czasami trzeba pracować cross domain, czyli gdzie pojawia się CORS. Korsarz domainA.com, używając nagłówka Access-Control-Allow-Origin do wyświetlenia innych domen (domainB.com), które są zaufane do uruchamiania JavaScript, który może współdziałać z domainA.com.

Aby zrozumieć, która domena powinna służyć CORS nagłówki, rozważ to. Odwiedzasz malicious.com, który zawiera JavaScript, który próbuje wysłać żądanie cross domain do mybank.com. powinno być do mybank.com, nie malicious.com, aby zdecydować, czy ustawia nagłówki CORS, które rozluźniają tę samą politykę origin, pozwalając JavaScript z malicious.com do interakcji z nim. Gdyby było to możliwe dla malicous.com aby ustawić własne nagłówki CORS umożliwiające własny dostęp JavaScript do mybank.com, to całkowicie zniweczyłoby to samo pochodzenie Polityka.

Myślę, że powodem mojej złej intuicji jest punkt widzenia, który mam podczas tworzenia strony. Its my site, with all my JavaScript, dlatego nie robi nic złośliwego i to powinno być do me aby określić, które inne strony my JavaScript może wchodzić w interakcje z. Kiedy w rzeczywistości powinienem myśleć, które inne Strony JavaScript próbują wchodzić w interakcję z moją witryną i czy powinienem używać CORS, aby na to pozwolić?

Jeśli używasz PHP, spróbuj dodać następujący kod w pliku php:

Jeśli używasz localhost, spróbuj tego:

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

Jeśli używasz zewnętrznych domen, takich jak serwer, spróbuj tego:

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

Do dzielenia między źródłami, Ustaw nagłówek: 'Access-Control-Allow-Origin':'*';

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

Węzeł: app.use('Access-Control-Allow-Origin':'*');

Pozwoli to na udostępnianie treści dla różnych domen.

W Pythonie używałem Flask-CORS biblioteka z wielkim sukcesem. To sprawia, że radzenie sobie z Kors super łatwe i bezbolesne. Dodałem kod z dokumentacji biblioteki poniżej.

Instalowanie:

$ pip install -U flask-cors

Prosty przykład, który pozwala CORS dla wszystkich domen na wszystkich trasach:

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app)

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

Bardziej szczegółowe przykłady można znaleźć w dokumentacji. Użyłem prostego przykładu powyżej, aby ominąć problem CORS w aplikacji jonowej, którą buduję, aby uzyskać dostęp do oddzielny serwer flask.