Apparemment, j'ai complètement mal compris sa sémantique. J'ai pensé à quelque chose comme ça:

1. Un client télécharge le code javascript MyCode.js depuis http://siteA- l'origine .
2. L'en-tête de réponse de MyCode.js contient Access-Control-Allow-Originhttp://siteB :, ce qui, à mon avis, signifiait que MyCode.js était autorisé à faire des références d'origine croisée au site B.
3. Le client déclenche certaines fonctionnalités de MyCode.js, qui à leur tour font des demandes http://siteB, ce qui devrait être correct, bien qu'il s'agisse de demandes d'origine croisée.

Eh bien, je me trompe. Cela ne fonctionne pas du tout comme ça. J'ai donc lu Partage de ressources d'origine croisée et tenté de lire Partage de ressources d'origine croisée dans la recommandation w3c

Une chose est sûre - je ne comprends toujours pas comment suis-je censé utiliser cet en-tête.

J'ai le contrôle total du site A et du site B. Comment puis-je activer le code javascript téléchargé depuis le site A pour accéder aux ressources du site B à l'aide de cet en-tête?

PS

Je ne veux pas utiliser JSONP.

Access-Control-Allow-Originest un en -tête CORS (Cross-Origin Resource Sharing) .

Lorsque le site A essaie de récupérer le contenu du site B, le site B peut envoyer un en- Access-Control-Allow-Origintête de réponse pour indiquer au navigateur que le contenu de cette page est accessible à certaines origines. (Une origine est un domaine, plus un schéma et un numéro de port .) Par défaut, les pages du site B ne sont accessibles à aucune autre origine ; l'utilisation de l'en- Access-Control-Allow-Origintête ouvre une porte d'accès à l'origine croisée par des origines de demande spécifiques.

Pour chaque ressource / page que le site B souhaite rendre accessible au site A, le site B doit diffuser ses pages avec l'en-tête de réponse:

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

Les navigateurs modernes ne bloqueront pas complètement les demandes interdomaines. Si le site A demande une page au site B, le navigateur récupère réellement la page demandée au niveau du réseau et vérifie si les en-têtes de réponse répertorient le site A comme domaine demandeur autorisé. Si le site B n'a pas indiqué que le site A est autorisé à accéder à cette page, le navigateur déclenchera le XMLHttpRequestl » errorévénement et nier les données de réponse au code JavaScript demande.

Demandes non simples

Ce qui se passe au niveau du réseau peut être légèrement plus complexe que expliqué ci-dessus. Si la demande est une demande "non simple" , le navigateur envoie d'abord une demande OPTIONS "de contrôle en amont" sans données, pour vérifier que le serveur acceptera la demande. Une demande n'est pas simple lorsque l'un (ou les deux):

• en utilisant un verbe HTTP autre que GET ou POST (par exemple PUT, DELETE)
• utiliser des en-têtes de demande non simples; les seuls en-têtes de requêtes simples sont:
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type(ce n'est simple quand sa valeur est application/x-www-form-urlencoded, multipart/form-dataou text/plain)

Si le serveur répond au contrôle en amont OPTIONS avec des en-têtes de réponse appropriés ( Access-Control-Allow-Headerspour les en-têtes non simples, Access-Control-Allow-Methodspour les verbes non simples) qui correspondent au verbe non simple et / ou aux en-têtes non simples, le navigateur envoie la demande réelle.

En supposant que le site A souhaite envoyer une demande PUT pour /somePage, avec une Content-Typevaleur non simple de application/json, le navigateur enverrait d'abord une demande de contrôle en amont:

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

Notez que Access-Control-Request-Methodet Access-Control-Request-Headerssont ajoutés automatiquement par le navigateur; vous n'avez pas besoin de les ajouter. Ce contrôle en amont OPTIONS obtient les en-têtes de réponse réussis:

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

Lors de l'envoi de la demande réelle (une fois le contrôle en amont terminé), le comportement est identique à la façon dont une demande simple est traitée. En d'autres termes, une requête non simple dont le contrôle en amont réussit est traitée de la même manière qu'une requête simple (c'est-à-dire que le serveur doit toujours envoyer à Access-Control-Allow-Originnouveau la réponse réelle).

Le navigateur envoie la demande réelle:

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

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

Et le serveur renvoie un Access-Control-Allow-Origin, comme il le ferait pour une simple demande:

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

Voir Comprendre XMLHttpRequest sur CORS pour un peu plus d'informations sur les requêtes non simples.

Le partage de ressources inter-origines - CORS(demande AKAX inter-domaines AJAX) est un problème que la plupart des développeurs Web peuvent rencontrer, selon la même politique d'origine, les navigateurs restreignent le JavaScript du client dans un sandbox de sécurité, généralement JS ne peut pas communiquer directement avec un serveur distant d'un domaine différent. Dans le passé, les développeurs ont créé de nombreuses méthodes délicates pour répondre aux demandes de ressources interdomaines, les plus courantes étant les suivantes:

1. Utilisez Flash / Silverlight ou côté serveur comme «proxy» pour communiquer avec la télécommande.
2. JSON avec rembourrage ( JSONP ).
3. Incorpore un serveur distant dans un iframe et communique via un fragment ou un nom de fenêtre, voir ici .

Ces méthodes délicates ont plus ou moins des problèmes, par exemple JSONP pourrait entraîner une faille de sécurité si les développeurs "évaluent" simplement, et # 3 ci-dessus, bien que cela fonctionne, les deux domaines doivent établir un contrat strict entre eux, il n'est ni flexible ni élégant A MON HUMBLE AVIS:)

Le W3C a introduit le partage de ressources d'origine croisée (CORS) en tant que solution standard pour fournir un moyen sûr, flexible et recommandé de résoudre ce problème.

Le mécanisme

D'un niveau élevé, nous pouvons simplement considérer que CORS est un contrat entre un appel AJAX client du domaine A et une page hébergée sur le domaine B, une demande / réponse typique d'origine croisée serait:

En-têtes de demande DomainA 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 

En-têtes de réponse 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

Les parties bleues que j'ai marquées ci-dessus étaient les faits fondamentaux, l'en-tête de demande "Origine" indique où la demande d'origine croisée ou la demande de contrôle en amont provient ", l'en-tête de réponse" Contrôle d'accès-Autoriser-Origine "indique que cette page autorise la demande à distance depuis DomainA (si la valeur est * indiquer autorise les requêtes distantes de n'importe quel domaine).

Comme je l'ai mentionné ci-dessus, W3 a recommandé au navigateur d'implémenter une " demande de contrôle en amont " avant de soumettre la demande HTTP réellement d'origine croisée, en un mot, il s'agit d'une OPTIONSdemande HTTP :

OPTIONS DomainB.com/foo.aspx HTTP/1.1

Si foo.aspx prend en charge le verbe HTTP OPTIONS, il peut renvoyer une réponse comme ci-dessous:

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

Ce n'est que si la réponse contient "Access-Control-Allow-Origin" ET que sa valeur est "*" ou contient le domaine qui a soumis la demande CORS, en satisfaisant à cette condition obligatoire que le navigateur soumettra la demande Cross-Domain réelle et mettra en cache le résultat dans " Preflight-Result-Cache ".

J'ai blogué sur CORS il y a trois ans: demande HTTP AJAX Cross-Origin

La question est un peu trop ancienne pour y répondre, mais je la poste pour toute référence future à cette question.

Selon cet article du Mozilla Developer Network,

Une ressource effectue une requête HTTP d'origine croisée lorsqu'elle demande une ressource à partir d'un domaine ou port différent de celui que la première ressource elle-même dessert.

Une page HTML servie à partir de http://domain-a.comfait une <img>demande src pour http://domain-b.com/image.jpg.
De nombreuses pages sur le Web aujourd'hui chargent des ressources telles que des feuilles de style CSS , des images et des scripts de domaines distincts (donc ça devrait être cool).

Politique de même origine

Pour des raisons de sécurité, les navigateurs restreignent les requêtes HTTP d'origine croisée lancées à partir de scripts .
Par exemple, XMLHttpRequestet Fetchsuivez la même politique d'origine .
Ainsi, une application Web utilisant XMLHttpRequestou Fetchne pouvant effectuer que des requêtes HTTP vers son propre domaine .

Partage des ressources d'origine croisée (CORS)

Pour améliorer les applications Web, les développeurs ont demandé aux fournisseurs de navigateurs d'autoriser les demandes interdomaines.

Le mécanisme CORS (Cross-Origin Resource Sharing) offre aux serveurs Web des contrôles d'accès inter-domaines , qui permettent des transferts de données inter-domaines sécurisés.
Les navigateurs modernes utilisent CORS dans un conteneur d'API - comme XMLHttpRequestou Fetch- pour atténuer les risques de requêtes HTTP d'origine croisée.

Fonctionnement de CORS (en- Access-Control-Allow-Origintête)

Wikipédia :

La norme CORS décrit les nouveaux en-têtes HTTP qui fournissent aux navigateurs et aux serveurs un moyen de demander des URL distantes uniquement lorsqu'ils y sont autorisés.

Bien que certaines validations et autorisations puissent être effectuées par le serveur, il est généralement de la responsabilité du navigateur de prendre en charge ces en-têtes et d'honorer les restrictions qu'ils imposent.

Exemple

1. Le navigateur envoie la OPTIONSdemande avec un en- Origin HTTPtête.

   La valeur de cet en-tête est le domaine qui a servi la page parent. Lorsqu'une page de http://www.example.comtente d'accéder aux données d'un utilisateur service.example.com, l'en-tête de demande suivant est envoyé à service.example.com:

   Origine: http://www.example.com

2. Le serveur de service.example.compeut répondre avec:

   • Un en- Access-Control-Allow-Origintête (ACAO) dans sa réponse indiquant quels sites d'origine sont autorisés.
     Par exemple:

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

   • Une page d'erreur si le serveur n'autorise pas la demande d'origine croisée

   • Un en- Access-Control-Allow-Origintête (ACAO) avec un caractère générique qui autorise tous les domaines:

     Access-Control-Allow-Origin: *

Chaque fois que je commence à penser à CORS, mon intuition sur le site qui héberge les en-têtes est incorrecte, tout comme vous l'avez décrit dans votre question. Pour moi, cela aide à réfléchir à l'objectif de la même politique d'origine.

Le but de la même politique d'origine est de vous protéger contre JavaScript malveillant sur siteA.com d'accéder aux informations privées que vous avez choisi de partager uniquement avec siteB.com. Sans la même politique d'origine, JavaScript écrit par les auteurs de siteA.com pourrait faire votre navigateur faire des demandes à siteB.com, en utilisant vos cookies d'authentification pour siteB.com. De cette façon, siteA.com pourrait voler les informations secrètes que vous partagez avec siteB.com.

Parfois, vous devez travailler sur plusieurs domaines, c'est là que CORS intervient. CORS assouplit la même politique d'origine pour domainB.com, en utilisant l'en- Access-Control-Allow-Origintête pour répertorier d'autres domaines (domainA.com) qui sont approuvés pour exécuter JavaScript qui peut interagir avec domainA. com.

Pour comprendre quel domaine doit servir les en-têtes CORS, considérez ceci. Vous visitez malveillant.com, qui contient du JavaScript qui tente de faire une demande interdomaine à mybank.com. Il devrait appartenir à mybank.com, et non à malware.com, de décider s'il définit ou non des en-têtes CORS qui assouplissent la même politique d'origine permettant au JavaScript de malveillant.com d'interagir avec lui. Si malicous.com pouvait définir ses propres en-têtes CORS permettant son propre accès JavaScript à mybank.com, cela annulerait complètement la même politique d'origine.

Je pense que la raison de ma mauvaise intuition est le point de vue que j'ai lors du développement d'un site. C'est mon site, avec tout mon JavaScript, donc il ne fait rien de malicieux et ce devrait être à moi de spécifier avec quels autres sites mon JavaScript peut interagir. Alors qu'en fait, je devrais penser quels autres sites JavaScript essaie d'interagir avec mon site et dois-je utiliser CORS pour les autoriser?

1. Un client télécharge le code javascript MyCode.js depuis http: // siteA - l'origine.

Le code qui effectue le téléchargement - votre balise de script html ou xhr à partir de javascript ou autre - provient, disons, de http: // siteZ . Et, lorsque le navigateur demande MyCode.js, il envoie un en-tête Origin: indiquant "Origin: http: // siteZ ", car il peut voir que vous demandez à siteA et siteZ! = SiteA. (Vous ne pouvez pas arrêter ou interférer avec cela.)

2. L'en-tête de réponse de MyCode.js contient Access-Control-Allow-Origin: http: // siteB , ce qui, à mon avis, signifiait que MyCode.js était autorisé à faire des références d'origine croisée au site B.

non. Cela signifie que seul le site B est autorisé à effectuer cette demande. Ainsi, votre demande de MyCode.js de siteZ obtient une erreur à la place, et le navigateur ne vous donne généralement rien. Mais si vous faites que votre serveur retourne ACAO: siteZ à la place, vous obtiendrez MyCode.js. Ou s'il envoie '*', cela fonctionnera, cela laissera tout le monde entrer. Ou si le serveur envoie toujours la chaîne depuis l'en-tête Origin: ... mais ... pour la sécurité, si vous avez peur des pirates , votre serveur ne doit autoriser que les origines sur une liste restreinte, autorisées à effectuer ces demandes.

Ensuite, MyCode.js provient de siteA. Lorsqu'il fait des demandes à siteB, elles sont toutes d'origine croisée, le navigateur envoie Origin: siteA, et siteB doit prendre le siteA, reconnaître qu'il figure sur la liste restreinte des demandeurs autorisés et renvoyer ACAO: siteA. Ce n'est qu'alors que le navigateur permettra à votre script d'obtenir le résultat de ces demandes.

En utilisant React et Axios , joignez le lien proxy à l'URL et ajoutez l'en-tête comme indiqué ci-dessous

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

Le simple fait d'ajouter le lien proxy fonctionnera, mais il peut également renvoyer une erreur pour No Access. Il vaut donc mieux ajouter un en-tête comme indiqué ci-dessous.

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

AVERTISSEMENT: ne pas utiliser en production

Ceci est juste une solution rapide, si vous n'arrivez pas à comprendre pourquoi vous n'êtes pas en mesure d'obtenir une réponse, vous pouvez l'utiliser. Mais encore une fois, ce n'est pas la meilleure réponse pour la production.

J'ai reçu plusieurs downvotes et cela a du sens, j'aurais dû ajouter l'avertissement il y a longtemps.

Si vous souhaitez simplement tester une application interdomaine dans laquelle le navigateur bloque votre demande, vous pouvez simplement ouvrir votre navigateur en mode dangereux et tester votre application sans changer votre code et sans rendre votre code dangereux. Depuis MAC OS, vous pouvez le faire depuis la ligne du terminal:

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

Si vous utilisez PHP, essayez d'ajouter le code suivant au début du fichier php:

Si vous utilisez localhost, essayez ceci:

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

Si vous utilisez des domaines externes tels que le serveur, essayez ceci:

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

je travaille avec express 4 et le noeud 7.4 et angulaire, j'ai eu le même problème que
j'aide ceci: a) côté serveur: dans le fichier app.js je donne des en-têtes à toutes les réponses comme:

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

cela doit avoir avant tout routeur .
J'ai vu beaucoup d'en-têtes ajoutés:

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

mais je n'en ai pas besoin,
b) côté client: dans send ajax vous devez ajouter: "withCredentials: true", comme:

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

bonne chance.

Pour le partage d'origine croisée, définissez l'en-tête: 'Access-Control-Allow-Origin':'*';

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

Nœud: app.use('Access-Control-Allow-Origin':'*');

Cela permettra de partager du contenu pour différents domaines.

En Python, j'utilise la Flask-CORSbibliothèque avec beaucoup de succès. Cela rend le traitement avec CORS super facile et indolore. J'ai ajouté du code à partir de la documentation de la bibliothèque ci-dessous.

Installation:

$ pip install -U flask-cors

Exemple simple qui permet à CORS pour tous les domaines sur toutes les routes:

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app)

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

Pour des exemples plus spécifiques, consultez la documentation. J'ai utilisé l'exemple simple ci-dessus pour contourner le problème CORS dans une application ionique que je construis et qui doit accéder à un serveur flask séparé.

D'après ma propre expérience, il est difficile de trouver une explication simple pourquoi CORS est même une préoccupation.

Une fois que vous comprenez pourquoi il est là, les en-têtes et la discussion deviennent beaucoup plus clairs. Je vais essayer en quelques lignes.

Tout est question de cookies. Les cookies sont stockés sur un client par leur domaine.

Un exemple d'histoire: Sur votre ordinateur, il y a un cookie pour yourbank.com. Peut-être que votre session est là-dedans.

Point clé: Lorsqu'un client fait une demande au serveur, il envoie les cookies stockés sous le domaine sur lequel se trouve le client.

Vous êtes connecté sur votre navigateur pour yourbank.com. Vous demandez à voir tous vos comptes. yourbank.comreçoit la pile de cookies et renvoie sa réponse (vos comptes).

Si un autre client fait une demande d' origine croisée à un serveur, ces cookies sont envoyés, comme auparavant. Ruh roh.

Vous accédez à malicious.com. Malicious fait un tas de demandes à différentes banques, y compris yourbank.com.

Les cookies étant validés comme prévu, le serveur autorisera la réponse.

Ces cookies sont collectés et envoyés - et maintenant, malicious.coma une réponse de yourbank.

Oui.

Alors maintenant, quelques questions et réponses deviennent évidentes:

• "Pourquoi ne bloquons-nous pas simplement le navigateur de faire ça?" Oui. CORS.
• "Comment pouvons-nous contourner cela?" Demandez au serveur de dire à la demande que CORS est OK.

Collez simplement le code suivant dans votre fichier web.config.

A noté que, vous devez coller le code suivant sous la <system.webServer>balise

    <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'en-tête de réponse Access-Control-Allow-Origin indique si la réponse peut être partagée avec le code demandeur de l'origine donnée.

Header type Response       header
Forbidden header name      no

Une réponse qui indique au navigateur d'autoriser le code de n'importe quelle origine à accéder à une ressource comprendra les éléments suivants:

Access-Control-Allow-Origin: *

Pour plus d'informations, visitez ici ....

Nginx et Appache

En plus de la réponse apsillers, je voudrais ajouter un graphique wiki qui montre quand la demande est simple ou non (et la demande de pré-vol OPTIONS est envoyée ou non)

Pour une demande simple (par exemple des images hotlinking ), vous n'avez pas besoin de modifier vos fichiers de configuration de serveur, mais vous pouvez ajouter des en-têtes dans l'application (hébergée sur le serveur, par exemple en php) comme Melvin Guerrero le mentionne dans sa réponse - mais rappelez-vous - : si vous ajoutez plein les en-têtes cors dans votre serveur (config) et en même temps vous autorisez les cors simples sur l'application (par exemple php) cela ne fonctionnera pas du tout.

Et voici les configurations pour deux serveurs populaires

• activer CORS sur Nginx ( nginx.conffichier)

  Afficher l'extrait de code

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

  Exécuter l'extrait de codeMasquer les résultats

  Développer l'extrait

• activer CORS sur Appache ( .htaccessfichier)

  Afficher l'extrait de code

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

  Exécuter l'extrait de codeMasquer les résultats

  Développer l'extrait