Apparentemente, ho completamente frainteso la sua semantica. Ho pensato a qualcosa del genere:

1. Un client scarica il codice javascript MyCode.js da http://siteA- l'origine .
2. L'intestazione della risposta di MyCode.js contiene Access-Control-Allow-Originhttp://siteB :, che pensavo significasse che MyCode.js era autorizzato a fare riferimenti incrociati al sito B.
3. Il client attiva alcune funzionalità di MyCode.js, che a loro volta inviano richieste http://siteB, il che dovrebbe andare bene, nonostante siano richieste di origine incrociata.

Bene, mi sbaglio. Non funziona affatto così. Quindi, ho letto la condivisione delle risorse tra le origini e ho tentato di leggere la condivisione delle risorse tra le origini nella raccomandazione w3c

Una cosa è certa: non capisco ancora come dovrei usare questa intestazione.

Ho il pieno controllo sia del sito A che del sito B. Come posso abilitare il codice javascript scaricato dal sito A per accedere alle risorse sul sito B usando questa intestazione?

PS

Non desidero utilizzare JSONP.

Access-Control-Allow-Originè un'intestazione CORS (Cross-Origin Resource Sharing) .

Quando il sito A tenta di recuperare il contenuto dal sito B, il sito B può inviare Access-Control-Allow-Originun'intestazione di risposta per dire al browser che il contenuto di questa pagina è accessibile a determinate origini. (L' origine è un dominio, oltre a un numero di schema e la porta .) Per impostazione predefinita, le pagine del sito B sono non accessibili a qualsiasi altra origine ; l'utilizzo Access-Control-Allow-Origindell'intestazione apre una porta per l'accesso tra le origini mediante origini richieste specifiche.

Per ogni risorsa / pagina che il sito B vuole rendere accessibile al sito A, il sito B dovrebbe pubblicare le sue pagine con l'intestazione della risposta:

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

I browser moderni non bloccheranno completamente le richieste tra domini. Se il sito A richiede una pagina dal sito B, il browser recupererà effettivamente la pagina richiesta a livello di rete e verificherà se le intestazioni di risposta elencano il sito A come dominio richiedente autorizzato. Se il sito B non ha indicato che del sito è permesso di accedere a questa pagina, il browser attiverà la XMLHttpRequest's errorevento e negare i dati di risposta per il codice JavaScript richiedente.

Richieste non semplici

Ciò che accade a livello di rete può essere leggermente più complesso di quanto spiegato sopra. Se la richiesta è una richiesta "non semplice" , il browser invia prima una richiesta OPTIONS "verifica preliminare" senza dati, per verificare che il server accetti la richiesta. Una richiesta non è semplice quando uno (o entrambi):

• utilizzando un verbo HTTP diverso da GET o POST (ad esempio PUT, DELETE)
• utilizzando intestazioni di richiesta non semplici; le uniche semplici intestazioni delle richieste sono:
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type(questo è solo semplice quando il suo valore è application/x-www-form-urlencoded, multipart/form-datao text/plain)

Se il server risponde al preflight OPTIONS con intestazioni di risposta appropriate ( Access-Control-Allow-Headersper intestazioni non semplici, Access-Control-Allow-Methodsper verbi non semplici) che corrispondono al verbo non semplice e / o intestazioni non semplici, il browser invia la richiesta effettiva.

Supponendo che il sito A voglia inviare una richiesta PUT per /somePage, con un Content-Typevalore non semplice di application/json, il browser invierebbe prima una richiesta di verifica preliminare:

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

Si noti che Access-Control-Request-Methode Access-Control-Request-Headersvengono aggiunti automaticamente dal browser; non è necessario aggiungerli. Questo preflight OPTIONS ottiene le intestazioni della risposta corretta:

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

Quando si invia la richiesta effettiva (dopo aver eseguito il preflight), il comportamento è identico a come viene gestita una richiesta semplice. In altre parole, una richiesta non semplice il cui preflight ha esito positivo viene trattata come una semplice richiesta (ovvero, il server deve ancora inviare Access-Control-Allow-Originnuovamente per la risposta effettiva).

Il browser invia la richiesta effettiva:

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

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

E il server restituisce un Access-Control-Allow-Origin, proprio come farebbe per una semplice richiesta:

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

Vedere Informazioni su XMLHttpRequest su CORS per ulteriori informazioni su richieste non semplici.

Condivisione delle risorse tra origini - CORS(richiesta AJAX tra domini AKA) è un problema che la maggior parte degli sviluppatori Web potrebbe riscontrare, secondo la stessa politica di origine, i browser limitano JavaScript client in una sandbox di sicurezza, di solito JS non può comunicare direttamente con un server remoto da un dominio diverso. In passato gli sviluppatori hanno creato molti modi complicati per ottenere la richiesta di risorse tra domini, più comunemente usando modi sono:

1. Utilizzare Flash / Silverlight o lato server come "proxy" per comunicare con il telecomando.
2. JSON con imbottitura ( JSONP ).
3. Incorpora il server remoto in un iframe e comunica tramite frammento o nome_finestra, fare riferimento qui .

Quei modi complicati hanno più o meno alcuni problemi, ad esempio JSONP potrebbe comportare un buco nella sicurezza se gli sviluppatori semplicemente lo "valutano", e il n. 3 sopra, sebbene funzioni, entrambi i domini dovrebbero costruire un rigoroso contratto tra loro, né flessibile né elegante A PARER MIO:)

Il W3C aveva introdotto la condivisione delle risorse incrociate (CORS) come soluzione standard per fornire un modo standard sicuro, flessibile e raccomandato per risolvere questo problema.

Il meccanismo

Da un livello elevato possiamo semplicemente ritenere che CORS sia un contratto tra la chiamata AJAX del client dal dominio A e una pagina ospitata sul dominio B, una tipica richiesta / risposta Cross-Origin sarebbe:

Dominio A Intestazioni richieste AJAX

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 

Intestazioni di risposta DomainB

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

Le parti blu che ho segnato sopra erano i fatti di Kernal, l'intestazione della richiesta "Origine" indica da dove proviene la richiesta di origine incrociata o la richiesta di verifica preliminare ", l'intestazione della risposta" Accesso-Controllo-Consenti-Origine "indica che questa pagina consente la richiesta remota da Dominio A (se il valore è * indica che consente le richieste remote da qualsiasi dominio).

Come accennato in precedenza, W3 ha raccomandato al browser di implementare una " richiesta di verifica preliminare " prima di inviare la richiesta HTTP Cross-Origin, in breve è una OPTIONSrichiesta HTTP :

OPTIONS DomainB.com/foo.aspx HTTP/1.1

Se foo.aspx supporta il verbo HTTP OPTIONS, potrebbe restituire una risposta come di seguito:

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

Solo se la risposta contiene "Access-Control-Allow-Origin" E il suo valore è "*" o contiene il dominio che ha inviato la richiesta CORS, soddisfacendo questa condizione obbligatoria il browser invierà la richiesta effettiva tra domini e memorizzerà nella cache il risultato in " Preflight-Result-Cache ".

Ho scritto un blog su CORS tre anni fa: richiesta HTTP AJAX Cross-Origin

La domanda è un po 'troppo vecchia per rispondere, ma sto pubblicando questo per qualsiasi riferimento futuro a questa domanda.

Secondo questo articolo di Mozilla Developer Network,

Una risorsa effettua una richiesta HTTP di origine incrociata quando richiede una risorsa da un dominio o porta diversi da quello utilizzato dalla prima risorsa stessa.

Una pagina HTML servita da http://domain-a.comeffettua una <img>richiesta src per http://domain-b.com/image.jpg.
Molte pagine del web oggi caricano risorse come fogli di stile CSS , immagini e script da domini separati (quindi dovrebbe essere interessante).

Politica sulla stessa origine

Per motivi di sicurezza, i browser limitano le richieste HTTP tra origini avviate dagli script .
Ad esempio, XMLHttpRequeste Fetchseguire la politica della stessa origine .
Pertanto, un'applicazione Web che utilizza XMLHttpRequesto Fetchpotrebbe effettuare richieste HTTP solo al proprio dominio .

Condivisione delle risorse tra le origini (CORS)

Per migliorare le applicazioni Web, gli sviluppatori hanno chiesto ai fornitori di browser di consentire richieste tra domini.

Il meccanismo di condivisione delle risorse tra origini (CORS) offre controlli di accesso tra domini dei server Web , che consentono trasferimenti sicuri di dati tra domini.
I browser moderni utilizzano CORS in un contenitore API - come XMLHttpRequesto Fetch- per mitigare i rischi di richieste HTTP di origine incrociata.

Come funziona CORS (Access-Control-Allow-Origin intestazione)

Wikipedia :

Lo standard CORS descrive le nuove intestazioni HTTP che forniscono ai browser e ai server un modo per richiedere URL remoti solo quando dispongono dell'autorizzazione.

Sebbene una certa convalida e autorizzazione possano essere eseguite dal server, è generalmente responsabilità del browser supportare queste intestazioni e rispettare le restrizioni che impongono.

Esempio

1. Il browser invia la OPTIONSrichiesta con Origin HTTPun'intestazione.

   Il valore di questa intestazione è il dominio che ha servito la pagina principale. Quando una pagina da http://www.example.comtenta di accedere ai dati di un utente service.example.com, la seguente intestazione della richiesta viene inviata a service.example.com:

   Origine: http://www.example.com

2. Il server all'indirizzo service.example.compotrebbe rispondere con:

   • An Access-Control-Allow-Origin(ACAO) intestazione nella sua risposta che indica che i siti di origine sono ammessi.
     Per esempio:

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

   • Una pagina di errore se il server non consente la richiesta di origine incrociata

   • An Access-Control-Allow-Origin(ACAO) un colpo di testa con un carattere jolly che consente a tutti i domini:

     Access-Control-Allow-Origin: *

Ogni volta che inizio a pensare a CORS, la mia intuizione su quale sito ospita le intestazioni è errata, proprio come hai descritto nella tua domanda. Per me, aiuta a pensare allo scopo della stessa politica di origine.

Lo scopo della stessa politica di origine è di proteggerti da JavaScript dannoso su siteA.com accedendo a informazioni private che hai scelto di condividere solo con siteB.com. Senza la stessa politica di origine, JavaScript scritto dagli autori di siteA.com potrebbe fare in modo che il browser invii richieste a siteB.com, utilizzando i cookie di autenticazione per siteB.com. In questo modo, siteA.com potrebbe rubare le informazioni segrete che condividi con siteB.com.

A volte è necessario lavorare su più domini, dove entra in gioco CORS. CORS rilassa la stessa politica di origine per domainB.com, usando Access-Control-Allow-Origin intestazione per elencare altri domini (domainA.com) ritenuti affidabili per eseguire JavaScript in grado di interagire con domainA. com.

Per capire quale dominio dovrebbe servire le intestazioni CORS, considerare questo. Visiti il ​​sito Web dannoso.com, che contiene alcuni JavaScript che tenta di effettuare una richiesta interdominio a mybank.com. Dovrebbe spettare a mybank.com, non malicious.com, decidere se impostare o meno le intestazioni CORS che allentano la stessa politica di origine consentendo a JavaScript di malicious.com di interagire con esso. Se malicous.com fosse in grado di impostare le proprie intestazioni CORS consentendo il proprio accesso JavaScript a mybank.com, questo annullerebbe completamente la stessa politica di origine.

Penso che la ragione della mia cattiva intuizione sia il punto di vista che ho nello sviluppo di un sito. È il mio sito, con tutto il mio JavaScript, quindi non sta facendo nulla di malevolo e dovrebbe spettare a me specificare con quali altri siti il mio JavaScript può interagire. Quando in effetti dovrei pensare a quali altri siti JavaScript sta cercando di interagire con il mio sito e dovrei usare CORS per consentirli?

1. Un client scarica il codice javascript MyCode.js da http: // siteA - l'origine.

Il codice che esegue il download - il tuo tag di script html o xhr da javascript o altro - proviene, diciamo, da http: // siteZ . E, quando il browser richiede MyCode.js, invia un'intestazione Origin: che dice "Origin: http: // siteZ ", perché può vedere che stai richiedendo siteA e siteZ! = SiteA. (Non puoi fermarti o interferire con questo.)

2. L'intestazione della risposta di MyCode.js contiene Access-Control-Allow-Origin: http: // siteB , che pensavo significasse che a MyCode.js era consentito fare riferimenti incrociati al sito B.

no. Significa che solo il sitoB può eseguire questa richiesta. Quindi la tua richiesta di MyCode.js da siteZ riceve invece un errore e il browser in genere non ti dà nulla. Ma se fai in modo che il tuo server restituisca ACAO: siteZ invece, otterrai MyCode.js. O se invia '*', funzionerà, farà entrare tutti. O se il server invia sempre la stringa dall'intestazione Origin: ... ma ... per sicurezza, se hai paura degli hacker , il tuo server dovrebbe consentire solo origini in un elenco ristretto, a cui è consentito effettuare tali richieste.

Quindi, MyCode.js proviene dal sitoA. Quando invia richieste al sito B, sono tutte di origine incrociata, il browser invia Origine: sito A e sito B deve prendere il sito A, riconoscere che è nell'elenco breve dei richiedenti consentiti e inviare nuovamente ACAO: sitoA. Solo così il browser consentirà al tuo script di ottenere il risultato di tali richieste.

Utilizzando React e Axios , unisci il link proxy all'URL e aggiungi l'intestazione come mostrato di seguito

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

Semplicemente aggiungendo il collegamento Proxy funzionerà, ma può anche generare nuovamente l'errore per No Access. Quindi è meglio aggiungere l'intestazione come mostrato di seguito.

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

ATTENZIONE: non utilizzare in produzione

Questa è solo una soluzione rapida, se stai lottando con il motivo per cui non sei in grado di ottenere una risposta, PUOI usarla. Ma di nuovo lo è non è la migliore risposta per la produzione.

Ho ottenuto diversi downgrade e ha perfettamente senso, avrei dovuto aggiungere l'avvertimento molto tempo fa.

Se vuoi solo testare un'applicazione interdominio in cui il browser blocca la tua richiesta, puoi semplicemente aprire il browser in modalità non sicura e testare la tua applicazione senza cambiare il tuo codice e senza renderlo pericoloso. Da MAC OS puoi farlo dalla linea terminale:

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

Se stai usando PHP, prova ad aggiungere il seguente codice all'inizio del file php:

Se stai usando localhost, prova questo:

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

Se si utilizzano domini esterni come server, provare questo:

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

io lavoro con express 4 e il nodo 7.4 e angolare, ho avuto lo stesso problema, mi aiuta a questo:
a) lato server: nel file app.js do intestazioni a tutte le risposte come:

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

questo deve avere prima di tutto il router .
Ho visto molte aggiunte queste intestazioni:

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

ma non ne ho bisogno,
b) lato client: in send ajax devi aggiungere: "withCredentials: true", come:

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

in bocca al lupo.

Per la condivisione incrociata dell'origine, imposta l'intestazione: 'Access-Control-Allow-Origin':'*';

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

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

Ciò consentirà di condividere contenuti per domini diversi.

In Python ho usato la Flask-CORSlibreria con grande successo. Rende il trattamento con CORS super facile e indolore. Ho aggiunto del codice dalla documentazione della libreria di seguito.

Installazione:

$ pip install -U flask-cors

Semplice esempio che consente CORS per tutti i domini su tutte le rotte:

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app)

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

Per esempi più specifici consultare la documentazione. Ho usato il semplice esempio sopra per aggirare il problema CORS in un'applicazione ionica che sto costruendo che deve accedere a un server di matracci separato.

Dalla mia esperienza, è difficile trovare una semplice spiegazione del perché CORS è anche una preoccupazione.

Una volta capito perché è lì, le intestazioni e la discussione diventano molto più chiare. Ci proverò in poche righe.

Si tratta di cookie. I cookie sono memorizzati su un client dal loro dominio.

Un esempio: sul tuo computer c'è un cookie per yourbank.com. Forse la tua sessione è lì.

Punto chiave: quando un client effettua una richiesta al server, invierà i cookie memorizzati nel dominio in cui si trova il client.

Hai effettuato l'accesso nel tuo browser a yourbank.com. Richiedi di vedere tutti i tuoi account. yourbank.comriceve la pila di cookie e rispedisce la sua risposta (i tuoi account).

Se un altro client fa un richiesta di origine incrociata a un server, tali cookie vengono inviati insieme, proprio come prima. Ruh Roh.

Navighi verso malicious.com . I dannosi fanno un sacco di richieste a diverse banche, incluso yourbank.com.

Poiché i cookie sono convalidati come previsto, il server autorizzerà la risposta.

Quei cookie vengono raccolti e inviati insieme - e ora, malicious.com ha una risposta da yourbank.

Yikes.

Quindi ora alcune domande e risposte diventano evidenti:

• "Perché non impediamo al browser di farlo?" Sì. CORS.
• "Come ci aggiriamo?" Chiedi al server di dire alla richiesta che CORS è OK.

Basta incollare il seguente codice nel file web.config.

Notato che, devi incollare il seguente codice sotto il <system.webServer>tag

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

L'intestazione della risposta Access-Control-Allow-Origin indica se la risposta può essere condivisa con il codice richiedente dall'origine specificata.

Header type Response       header
Forbidden header name      no

Una risposta che dice al browser di consentire al codice di qualsiasi origine di accedere a una risorsa includerà quanto segue:

Access-Control-Allow-Origin: *

Per maggiori informazioni, visita qui ....

Nginx e Appache

In aggiunta alla risposta di Apsillers, vorrei aggiungere un grafico wiki che mostra quando la richiesta è semplice o meno (e la richiesta pre-volo OPTIONS viene inviata o meno)

Per una semplice richiesta (ad es . Immagini hotlinking ) non è necessario modificare i file di configurazione del server ma è possibile aggiungere intestazioni nell'applicazione (ospitata sul server, ad esempio in php) come menziona Melvin Guerrero nella sua risposta - ma ricorda : se aggiungi pieno intestazioni cors nel tuo server (config) e allo stesso tempo permetti cors semplice sull'applicazione (es. php) questo non funzionerà affatto.

E qui ci sono configurazioni per due server popolari

• attiva CORS su Nginx ( nginx.conffile)

  Mostra snippet di codice

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

  Esegui snippet di codiceNascondi risultati

  Espandi frammento

• attiva CORS su Appache ( .htaccessfile)

  Mostra snippet di codice

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

  Esegui snippet di codiceNascondi risultati

  Espandi frammento