Access-Control-Allow-Origin Plusieurs Domaines D'Origine?

Est-il un moyen pour permettre à de multiples inter-domaines à l'aide de la Access-Control-Allow-Origin - tête?

Je suis conscient de la *, mais c'est trop ouvert. J'ai vraiment envie de donner juste un couple de domaines.

Comme un exemple, quelque chose comme ceci:

Access-Control-Allow-Origin: http://domain1.example, http://domain2.example

J'ai essayé le code ci-dessus, mais il ne semble pas fonctionner dans Firefox.

Est-il possible de spécifier plusieurs domaines ou suis-je coincé avec seulement un seul?

Plutôt que de laisser un espace séparé de la liste d'origine (origine de la liste ou nulle) est soit une origine unique ou de la chaîne de la valeur "null". (merci @maxpolk)
En utilisant la plus récente de Firefox, ni la séparation par virgule, ni les séparant par des espaces domaines a fait un travail. Correspondant à une liste de domaines et de mettre un seul hôte dans les en-têtes est toujours mieux de sécurité et ne fonctionne correctement.
Si vous êtes aux prises avec ce pour HTTPS, j'ai trouvé un solution.
ou "*" ? shared based by returning the value of the Origin request header, "*", or "null"
remarque importante: en autorisant uniquement les cretain les domaines de la Access-Control-Allow-Origin en-tête n' pas, les autres domaines ne peuvent pas déclencher une méthode sur ce critère (par exemple, RESTE la méthode API). Cela signifie simplement que la refusé origines ne peut pas utiliser le résultat en javascript (navigateur assure que c'). Pour restreindre l'accès à un point de terminaison pour des domaines spécifiques d'utilisation d'un serveur-côté filtre de requête, par exemple, renvoie HTTP 401 pour les interdits domaines.
Vous devriez toujours ajouter Vary: Origin en-tête lorsque vous souhaitez utiliser plusieurs Url, voir: fetch.spec.whatwg.org/#cors-protocol-and-http-caches

InformationsquelleAutor Thomas J Bradley | 2009-10-31

818

Sons comme le recommande façon de le faire est d'avoir votre serveur de lire l'en-tête d'Origine de la part du client, de la comparer à la liste des domaines que vous souhaitez autoriser, et si elle correspond, en écho de la valeur de la Origin - tête en arrière pour le client comme le Access-Control-Allow-Origin tête dans la réponse.

Avec .htaccess vous pouvez le faire comme ceci:
```
# ----------------------------------------------------------------------
# Allow loading of external fonts
# ----------------------------------------------------------------------
<FilesMatch "\.(ttf|otf|eot|woff|woff2)$">
    <IfModule mod_headers.c>
        SetEnvIf Origin "http(s)?://(www\.)?(google.com|staging.google.com|development.google.com|otherdomain.example|dev02.otherdomain.example)$" AccessControlAllowOrigin=$0
        Header add Access-Control-Allow-Origin %{AccessControlAllowOrigin}e env=AccessControlAllowOrigin
        Header merge Vary Origin
    </IfModule>
</FilesMatch>
```
- Super! Je n'ai même pas penser à le faire.
- Cela correspond à ce que le W3C suggère -- w3.org/TR/cors/#access-control-allow-origin-response-hea
- Mon problème avec cette réponse, c'est qu'il n'a pas vraiment m'aider, parce que nous utilisons un CDN, et, évidemment, nous ne pouvons pas contrôler la façon dont le CA définit les en-têtes par programmation.
- Comme @BT notes ce n'est pas une bonne solution car il ne fonctionne pas sur un CDN. Avec cela étant dit, si vous voulez continuer à le faire il y a deux typiques CA configurations. Dans la première, vous utilisez votre serveur comme un serveur d'origine. Dans ce cas, la spécification d'un simple * (tout n'est pas idéal) serait de travailler. CA serait cache cet en-tête ainsi que tout ce que vous envoyez et servir au client. Dans le second, vous utilisez une télécommande (CA géré serveur que l'origine. Dans ce cas, vous devez configurer le CDN pour en envoyer un en-tête HTTP personnalisé pour ce contenu. (Encore une fois, vous devez spécifier *)
- Il fonctionne dans IE XD sans avoir à régler quoi que ce soit.
- +1 pour le commentaire de @genexp pour mentionner important CA de l'installation. Bon CA va (devrait) cache les en-têtes, vous définissez si l'évolution dynamique de l'en-tête n'est pas l'idéal. Cela est vrai pour un CDN comme maxcdn, qui met en cache de vos Access-Control-Allow-Origin-tête, vous l'envoyer et pour il pour travailler après la modification de votre htaccess vous avez besoin de purger votre cache du cdn.
- Exemple réel (Nginx) dans ma réponse ci-dessous - stackoverflow.com/a/12414239/6084
- C'est ce qu'un client doit mettre en œuvre pour l'en-Tête donateurs n'restriction ... pas un algorithme pour être mis en œuvre côté serveur, à mon humble avis
- C'est une excellente solution pour une exposition sélective des web services. Il n'est pas étanche à l'air, mais un excellent moyen de limiter côté client demande origines dans les navigateurs. Merci!
- Si les caches ou les Cdn ne sont pas un problème, utilisez le en-tête Vary pour indiquer le cache/CDN de maintenir séparés les réponses de différents Origine de la demande de valeurs d'en-tête. Vous devez inclure un en-tête comme le "Vary: Origine" dans votre réponse. Le cache/CDN sait alors qu'il doit envoyer une réponse à une demande avec en-tête "Origine: foo.example.com", et une autre réponse à une demande avec en-tête "Origine: bar.example.com".
- Ne peut pas le client usurper l'en-tête d'origine? Quelque chose de picotement à la base de mon crâne sens une faille de sécurité il y a juste en écho au client l'en-tête d'Origine.
- si vous avez accès à l'en-tête d'Origine, vous êtes passé de la SCRO.
- Il n'y apparaîtront pas à des conflits dans le recommandé moyen de le faire. Veuillez voir mon suivi de la question. stackoverflow.com/questions/25309318/...
- Header always set a fonctionné pour moi.
- Toujours à l'aide d'un en-tête Vary (indépendamment de si le serveur est derrière un CDN ou pas) semble être la meilleure pratique, voir par exemple developer.mozilla.org/en-US/docs/Web/HTTP/... . Peut-être que vous pouvez l'ajouter à la réponse?
- Avec cette approche, toujours définir un en-tête Vary pour assurer la mise en cache n'est pas de casser des choses: Header append Vary Origin
- J'ai une énorme liste de sites. Comment puis-je les mettre dans un plus lisible liste, comme un tableau ou quelque chose, que j'ai ensuite inclure dans le SetEnvIf-la règle?
- pouvez-vous développer un peu plus sur les raisons de ce saturdayplace dit n'est pas correct? Le client peut falsifier les en-tête d'Origine de la demande qu'il fait pour le serveur, de sorte que le serveur pourrait penser qu'un autre client (Origine) fait la demande et que cela permettrait d'accès.
- même question que j'ai demandé à JohnKurlak va pour vous
- Ignorer mon commentaire... je pense que j'ai mal compris (et l'ai supprimé pour éviter de dérouter les autres). Toutefois, @PaulDraper commentaire est valable. Si vous essayez de définir la Origin en-tête d'une requête Ajax, le navigateur va vous donner une erreur de ce type: "a Refusé d'dangereuses en-tête "Origine"".
- D'où vient le htaccess aller?
- Il commence par une période d': .htaccess et vous permet de modifier les paramètres du serveur web. Vous le mettez dans le dossier racine de votre site web.
- Excellent! De grandes choses peuvent être que de simple, comme ça, merci beaucoup!
- est le e après %{AccessControlAllowOrigin}e une faute de frappe? aucun
- Je pense que SetEnvIf paramètre manque de s'échapper des points, c'est à dire google.com devrait être google\.com, sinon domaines comme googleFcom seront également permis...
- C'est génial ! Merci pour votre réponse. Est-il possible d'ajouter une variable de nom de domaine ? J'ai principales de domaine et sous-domaine pour les actifs comme: (static.example.com/example.com)
- À noter que cela nécessite que mod_setenv est activé. Que ce soit clair, je vous propose l'envelopper le tout dans un <IfModule mod_setenvif.c>
InformationsquelleAutor yesthatguy
208

Une autre solution, je suis à l'aide de PHP:
```
$http_origin = $_SERVER['HTTP_ORIGIN'];

if ($http_origin == "http://www.domain1.com" || $http_origin == "http://www.domain2.com" || $http_origin == "http://www.domain3.com")
{  
    header("Access-Control-Allow-Origin: $http_origin");
}
```
- Pourquoi ne pas utiliser l'approche proposée dans stackoverflow.com/a/1850482/11635 [et ne pas envoyé un caractère générique, juste à la demande de l'origine] ? C'est juste plus permissive, sans parvenir à quelque chose de plus?
- ayant header('Access-Control-Allow-Origin: *') dit parfois ne peut pas utiliser de joker si les informations d'identification indicateur est vrai - se produit lorsque header('Access-Control-Allow-Credentials: true')probablement. Donc, c'est mieux pour Permettre à l'Origine de la $http_origin lui-même si les conditions sont remplies
- Tour de Nice. m'a aidé. Je vous remercie.
- remplacer la dernière ligne avec header("Access-Control-Allow-Origin: " . $http_origin); pour le faire fonctionner
- les deux façons qu'il fonctionne. Les variables PHP à l'intérieur de guillemets doubles sont évalués: php.net/manual/de/...
- ah ok ! Je ne savais pas à propos de la double citation chose. merci
- J'ai été en utilisant cela, mais il s'est cassé lorsque le code a été déplacé vers un nouveau serveur où $_SERVER['HTTP_ORIGIN'] n'est pas pris en charge. Apparemment ce n'est pas garanti d'être là, même si il est habituellement. Telle est la beauté de PHP.
- $_SERVER['HTTP_ORIGIN'] est uniquement prise en charge par Chrome pour certaines requêtes, cet en-tête n'est pas envoyé par firefox et chrome, voir stackoverflow.com/questions/4566378/how-secure-is-http-origin
- Ce code apparaît erronée, dans la mesure où si aucun HTTP_ORIGIN en-tête est reconnu, pas de Access-Control-Allow-Origin est fixé à tous, en laissant le script grande ouverte.
- Lol, maintenant c'est un truc intelligent. Merci.
- en fait "de large fermé" serait plus exact, car le but de cette opération est d'ouvrir le script à d'autres domaines 😉
- veuillez également ajouter le Vary: Origin en-tête. voir: fetch.spec.whatwg.org/#cors-protocol-and-http-caches
InformationsquelleAutor Nikolay Ivanov
108

Cela a fonctionné pour moi:
```
SetEnvIf Origin "^http(s)?://(.+\.)?(domain\.example|domain2\.example)$" origin_is=$0 
Header always set Access-Control-Allow-Origin %{origin_is}e env=origin_is
```
Lorsqu'il est mis en .htaccess, il va travailler pour vous.
- la meilleure solution pour moi, mais j'ai ajouté la prise en charge de port (par exemple, localhost:3000 pour le développement): SetEnvIf Origine "^http(s)?://(.+\.)?(localhost|stackoverflow.com|exemple1.com)(:[0-9]+)?$" origin_is=$0
- De la plusieurs réponses tout autour de stackoverflow, ce fut le seul qui a fonctionné.
- J'ai besoin d'ajouter Header set Access-Control-Allow-Credentials true pour que cela fonctionne comme @George 's réponse
- Cela fonctionne pour vous lorsque j'utilise Origine. Mais dans certains cas, l'Origine n'est pas disponible dans certaines demandes et il est un navigateur spécifique ainsi. Alors, j'ai décidé d'utiliser Referer au lieu de Origin. À l'aide de Referer fonctionne, mais le problème est qu'il définit l'URL complète de retour à Access-Control-Allow-Origin je veux le nom de domaine de Referer et de l'attribuer à Access-Control-Allow-Origin. Quelque chose comme le résultat de cette - echo http://example.com/index.php/ab/cd | cut -d'/' -f1,2,3 de commande bash . Est-ce possible de faire la même chose dans l' (apache)fichier conf? Une Idée?
- Cela ne fonctionne pas pour moi. Avoir toujours un code d'erreur 500 lorsque je ajouter les 2 lignes. En fait l'utilisation de PHP 5.6.15
- Merci à vous et merci spécial à @vszurma parce que je vois tout le monde a oublié la célèbre localhost.
InformationsquelleAutor Jay Dave
88

J'ai eu le même problème avec woff-polices de caractères, de plusieurs sous-domaines devaient avoir accès. Pour permettre aux sous-domaines, j'ai ajouté quelque chose comme cela pour mon httpd.conf:
```
SetEnvIf Origin "^(.*\.example\.com)$" ORIGIN_SUB_DOMAIN=$1
<FilesMatch "\.woff$">
    Header set Access-Control-Allow-Origin "%{ORIGIN_SUB_DOMAIN}e" env=ORIGIN_SUB_DOMAIN
</FilesMatch>
```
Pour de multiples domaines, vous pouvez simplement modifier la regex dans SetEnvIf.
- A fait le tour. Assurez-vous simplement de s'adapter à l'expression régulière correctement. J'ai besoin d'ajouter un point d'interrogation afin de permettre le domaine lui-même, par exemple, (.*\.?example\.org) pour example.com et sub.example.com.
- Toute réflexion sur la façon d'adapter ce pour IIS 7?
- N'est pas qu'une victoire la fin si ? Ce qui peut empêcher un utilisateur malveillant de falsifier les en-tête d'Origine de la valeur ?
- Access-Control-Allow-Origin n'est pas sur le masquage des ressources de quelqu'un qui peut en faire la demande. C'est à propos de la prévention d'un site malveillant d'avoir des utilisateurs finaux de l'appelant de votre site. Dans le cas de fichiers de police, ce qui ne peut effectivement limiter chaude la liaison des polices, pourquoi ils (mozilla/firefox) ne font pas la même pour les autres ressources (js, css, etc) est au delà de moi.
- il y a un bug dans votre regex, il permettra également subexample.com. Vous devez modifier: ((.*\.)?example\.org)
- fichiers multimédias sont permis, à cause de raisons de compatibilité, en combinaison avec le fait qu'ils sont relativement actifs à faible risque par rapport à un code exécutable, comme les scripts.
- Je parlais en termes de scripts... woff fichiers sont supports, et ne sont pas autorisées, tandis que les scripts sont encore. C'était mon point de vue en termes de sensation, comme une rétrospective de changement.
- Aucun moyen de pour que sur une seule voie de mon php app?
- Le problème c'est que lorsque le navigateur met en cache le fichier, il va bloquer la demande qu'il a le tort de la SCRO-tête.
InformationsquelleAutor Staugaard
62

Voici comment faire l'écho de l'en-tête d'Origine si elle correspond à votre nom de domaine avec Nginx, c'est utile si vous souhaitez répondre à une police de plusieurs sous-domaines:
```
location /fonts {
    # this will echo back the origin header
    if ($http_origin ~ "example.org$") {
        add_header "Access-Control-Allow-Origin" $http_origin;
    }
}
```
- Ne comprends pas comment est-ce différent: add_header Access-Control-Allow-Origin:*; le Soin de l'expliquer?
- cela va revenir un en-tête qui autorise le navigateur d'envoyer des demandes à partir du domaine spécifié. si j'ai bien deviné, je dirais que le navigateur puisse autoriser le contenu d'un autre domaine chargé sur la page pour accéder au serveur à l'autre.
- pour une chose, il peut y avoir de sécurité renforcée d'où "Autoriser *" n'est pas autorisé, mais déterminée et correspondance de nom d'hôte pour le permettre d'en-tête fonctionne. Un exemple ici, si vous souhaitez envoyer les informations d'autorisation de la croix de domaine, vous ne pouvez pas utiliser "Permettent *"
- La STC, c'est la raison exacte -- je ne veux pas limiter les clients, mais je ne veux autorisation d'utilisation. La seule façon de le faire selon les specs, c'est le retour à l'Origine. En fait, je suis surpris de constater qu'ils ont même * -- retourner l'origine ou n'en ont pas.
- Est le . dans example.org interprétée comme une valeur, étant donné que c'est une expression régulière? Dans ce cas, serait-ce à tort de permettre à un exemple personnalisé-org TLD?
- Une bonne regex doit être "^example\.org$" parce que vous avez besoin pour s'assurer qu'un hacker ne peut pas passer à travers votre regex avec subdomainexample.org (utiliser ^) ou example.orgevil (utiliser $) ou examplezorg (escape \.)
- Probablement plus comme "\.?example\.org$" -- nous ne voulons pas d'ancrage sur le début de la chaîne parce que ce serait empêcher valide les sous-domaines de l'appariement de la première place. Si le client demande l'apex (sans aucun sous-domaine partie) nous voulons que le match de trop.
InformationsquelleAutor mjallday

Voici ce que j'ai fait pour une application en PHP qui est demandé par AJAX

$request_headers        = apache_request_headers();
$http_origin            = $request_headers['Origin'];
$allowed_http_origins   = array(
                            "http://myDumbDomain.example"   ,
                            "http://anotherDumbDomain.example"  ,
                            "http://localhost"  ,
                          );
if (in_array($http_origin, $allowed_http_origins)){  
    @header("Access-Control-Allow-Origin: " . $http_origin);
}

Si le requérant origine est autorisé par mon serveur, le retour de la $http_origin lui-même en tant que valeur de la Access-Control-Allow-Origin en-tête au lieu de retourner un * générique.

InformationsquelleAutor Rakib

20

Il y a un inconvénient, vous devez être conscient: dès Que vous les fichiers source dans un CDN (ou tout autre serveur qui ne permet pas de script) ou si vos fichiers sont mis en cache sur un proxy, la modification de la réponse basée sur "l'Origine" en-tête de requête ne fonctionnera pas.
- Pourriez-vous élaborer sur ce sujet, ou le point de nous quelque part nous pouvons regarder pour plus d'info? Je suis à la recherche de le faire avec Honneur, et j'espère que vous avez tort. L'un de nos opérations techniques gars m'a dit que tant que notre CDN de semences serveur envoie l'en-tête, le CDN a lui-même vous l'envoyer. Ont encore de le tester
- Si les caches ou les Cdn ne sont pas un problème, utilisez l'en-tête Vary à dire le cache/CDN de maintenir séparés les réponses de différents Origine de la demande de valeurs d'en-tête. Vous devez inclure un en-tête comme le "Vary: Origine" dans votre réponse. Le cache/CDN sait alors qu'il doit envoyer une réponse à une demande avec en-tête "Origine: foo.example.com", et une autre réponse à une demande avec en-tête "Origine: bar.example.com".
- Vary: Origin n'est pas pris en charge par Akamai, l'un des plus grands CA existe... Plus les détails sont disponibles ici
InformationsquelleAutor Mark
19

Pour plusieurs domaines, dans votre .htaccess:
```
<IfModule mod_headers.c>
    SetEnvIf Origin "http(s)?://(www\.)?(domain1.example|domain2.example)$" AccessControlAllowOrigin=$0$1
    Header add Access-Control-Allow-Origin %{AccessControlAllowOrigin}e env=AccessControlAllowOrigin
    Header set Access-Control-Allow-Credentials true
</IfModule>
```
- Cet extrait de code fonctionne parfaitement pour moi. Mais je ne comprends pas ce qu'il fait 😀
- cela a fonctionné pour moi, bien que j'ai dû ajouter un '^' j'ai.e.... SetEnvIf Origine "^http(s)?://(www\.)?
- Il fait à peu près le même que stackoverflow.com/a/14034228/209139. C'est juste que .htaccess syntaxe est beaucoup plus difficile à lire que de PHP. Header set Vary Origin serait une belle addition à cette réponse.
- Merci beaucoup pour votre aide
- J'ai dû changer AccessControlAllowOrigin=$0$1 à AccessControlAllowOrigin=$0. Sinon, il n'a pas de travail pour HTTPS origines. http://example.com est sorti correctement, mais https://example.com est sorti comme https://example.coms, avec un supplément de s sur la fin.
InformationsquelleAutor George
17

Pour Nginx les utilisateurs pour permettre à la SCRO pour plusieurs domaines. J'aime l' @marshall exemple, bien que sa anwers seulement correspond à un domaine. Pour correspondre à une liste de domaine et sous-domaine cette regex faire de la facilité à travailler avec des polices:
```
location ~* \.(?:ttf|ttc|otf|eot|woff|woff2)$ {
   if ( $http_origin ~* (https?://(.+\.)?(domain1|domain2|domain3)\.(?:me|co|com)$) ) {
      add_header "Access-Control-Allow-Origin" "$http_origin";
   }
}
```
Cela ne echo "Access-Control-Allow-Origin" en-têtes qui correspond à la liste des domaines.
- gist.github.com/Stanback/7145487 a été utile pour moi.
- Pensez que vous avez besoin de verrouiller que la regex à la fin avec \z parce que sinon domain3.com.badhacker.com serait autorisé l'accès.
- Nous définissons $ à la fin qui ne fait que
- Désolé je voulais dire dans le sens exemple, le message de @AdrianoRosa fait la même chose que \z
InformationsquelleAutor Adriano Rosa
15

Pour IIS 7.5+ avec Réécriture d'URL 2.0 module installé, veuillez voir cette SORTE de réponse
- A travaillé comme un charme, merci!
InformationsquelleAutor Paco Zarate

Voici une solution pour Java web app, en fonction de la réponse de yesthatguy.

Je suis en utilisant Maillot de REPOS 1.x

Configurer l'web.xml pour être au courant de Maillot de REPOS et de la CORSResponseFilter

 <!-- Jersey REST config -->
  <servlet>    
    <servlet-name>JAX-RS Servlet</servlet-name>
    <servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
    <init-param> 
        <param-name>com.sun.jersey.api.json.POJOMappingFeature</param-name>
        <param-value>true</param-value>
    </init-param>
    <init-param>
      <param-name>com.sun.jersey.spi.container.ContainerResponseFilters</param-name>
      <param-value>com.your.package.CORSResponseFilter</param-value>
    </init-param>   
    <init-param>
        <param-name>com.sun.jersey.config.property.packages</param-name>
        <param-value>com.your.package</param-value>
    </init-param>        
    <load-on-startup>1</load-on-startup>
  </servlet>
  <servlet-mapping>
    <servlet-name>JAX-RS Servlet</servlet-name>
    <url-pattern>/ws/*</url-pattern>
  </servlet-mapping>

Voici le code pour CORSResponseFilter

import com.sun.jersey.spi.container.ContainerRequest;
import com.sun.jersey.spi.container.ContainerResponse;
import com.sun.jersey.spi.container.ContainerResponseFilter;


public class CORSResponseFilter implements ContainerResponseFilter{

@Override
public ContainerResponse filter(ContainerRequest request,
        ContainerResponse response) {

    String[] allowDomain = {"http://localhost:9000","https://my.domain.example"};
    Set<String> allowedOrigins = new HashSet<String>(Arrays.asList (allowDomain));                  

    String originHeader = request.getHeaderValue("Origin");

    if(allowedOrigins.contains(originHeader)) {
        response.getHttpHeaders().add("Access-Control-Allow-Origin", originHeader);

        response.getHttpHeaders().add("Access-Control-Allow-Headers",
                "origin, content-type, accept, authorization");
        response.getHttpHeaders().add("Access-Control-Allow-Credentials", "true");
        response.getHttpHeaders().add("Access-Control-Allow-Methods",
                "GET, POST, PUT, DELETE, OPTIONS, HEAD");
    }

    return response;
}

}

Le Lien ci-Dessus est Expiré, vous pouvez en ajouter de nouveaux, ou de la mise à jour de répondre avec plus de détails, Merci
J'ai ajouté plus de détails,espérons que cette aide

InformationsquelleAutor duvo

11

Comme mentionné ci-dessus, Access-Control-Allow-Origin doit être unique et Vary doit être réglé à Origin si vous êtes derrière un CDN (Content delivery Network).

Partie de mon Nginx configuration:
```
if ($http_origin ~* (https?://.*\.mydomain.example(:[0-9]+)?)) {
  set $cors "true";
}
if ($cors = "true") {
  add_header 'Access-Control-Allow-Origin' "$http_origin";
  add_header 'X-Frame-Options' "ALLOW FROM $http_origin";
  add_header 'Access-Control-Allow-Credentials' 'true';
  add_header 'Vary' 'Origin';
}
```
- a set $cors une sorte de sens caché, ou est-il spécifique à votre conifg? il semble qu'il peut être omis, ainsi que la deuxième if
- C'est vrai, il peut être omis si c'est la seule condition de vous tester pour définir les en-têtes, j'ai eu plusieurs dans ma config.
InformationsquelleAutor hernvnc
9

Peut-être que je me trompe, mais pour autant que je peux voir Access-Control-Allow-Origin a un "origin-list" comme paramètre.

Par définition un origin-list est:
```
origin            = "origin" ":" 1*WSP [ "null" /origin-list ]
origin-list       = serialized-origin *( 1*WSP serialized-origin )
serialized-origin = scheme "://" host [ ":" port ]
                  ; <scheme>, <host>, <port> productions from RFC3986
```
Et à partir de cela, je soutiens origines différentes sont admis et doivent être séparés par un espace.
- Il semble que ce soit une interprétation correcte de la spécification; cela dit, la spec ne semble pas être entièrement pris en charge par les navigateurs actuels (par exemple, je viens de testé sur Firefox 17.0 et a confirmé qu'il ne fonctionnera pas).
- Le SCRO spécification 5.1 Access-Control-Allow-Origin Response Header unis que l'origine de la liste est limitée: Plutôt que de laisser un espace-liste séparée par des origines, c'est soit une origine unique ou de la chaîne de la valeur "null".
- Comme je l'ai mentionné dans un commentaire sur mon propre réponse, qui fait partie de l'un des réalisateurs note, pas un RFC 2119 exigence. La "bonne" réponse est absolument à l'utilisation de l'espace délimité par les valeurs. Le problème est tout simplement que les implémentations sont incomplètes et donc la "bonne" réponse n'est pas nécessairement le travail. Il devrait, mais il ne le fait pas. Toutefois, à l'avenir, que des implémentations d'aller mieux, cela pourrait changer.
InformationsquelleAutor drAlberT
7

J'ai eu du mal à le définir pour un domaine exécutant le protocole HTTPS, alors j'ai pensé que je voudrais partager la solution. J'ai utilisé la directive suivante dans mon httpd.conf fichier:
```
    <FilesMatch "\.(ttf|otf|eot|woff)$">
            SetEnvIf Origin "^http(s)?://(.+\.)?example\.com$" AccessControlAllowOrigin=$0
            Header set Access-Control-Allow-Origin %{AccessControlAllowOrigin}e env=AccessControlAllowOrigin
    </FilesMatch>
```
Changement example.com à votre nom de domaine. Ajoutez ceci à l'intérieur <VirtualHost x.x.x.x:xx> dans votre httpd.conf fichier. Notez que si votre VirtualHost a un port suffixe (par exemple :80), alors cette directive ne s'appliquera pas en HTTPS, donc il vous faudra aussi aller à /etc/apache2/sites-available/default-ssl et ajouter la même directive dans ce fichier, à l'intérieur de la <VirtualHost _default_:443> section.

Une fois les fichiers de configuration sont mis à jour, vous devez exécuter les commandes suivantes dans le terminal:
```
a2enmod headers
sudo service apache2 reload
```
- J'aime cette option et combinée/modifié avec la mise en œuvre que @George. Parfois, les serveurs n'ont pas a2enmod disponibles, de sorte que tous vous avez à faire est de vérifier votre principal httpd.conf pour voir si la ligne: LoadModule headers_module modules/mod_headers.donc est sans commentaire.
- Mon origine avait un numéro de port, j'ai donc modifié l'expression régulière que: ^http(s)?://(.+\.)?example\.com(:\d+)?$
InformationsquelleAutor Alex W

Si vous rencontrez des problèmes avec les polices, utilisez:

<FilesMatch "\.(ttf|ttc|otf|eot|woff)$">
    <IfModule mod_headers>
        Header set Access-Control-Allow-Origin "*"
    </IfModule>
</FilesMatch>

InformationsquelleAutor noun

Pour ExpressJS applications que vous pouvez utiliser:

app.use((req, res, next) => {
    const corsWhitelist = [
        'https://domain1.example',
        'https://domain2.example',
        'https://domain3.example'
    ];
    if (corsWhitelist.indexOf(req.headers.origin) !== -1) {
        res.header('Access-Control-Allow-Origin', req.headers.origin);
        res.header('Access-Control-Allow-Headers', 'Origin, X-Requested-With, Content-Type, Accept');
    }

    next();
});

InformationsquelleAutor eyecatchUp

2

HTTP_ORIGIN n'est pas utilisé par tous les navigateurs. Comment sécuriser HTTP_ORIGIN? Pour moi il s'agit vide en FF.

J'ai des sites que j'permettre l'accès à mon site envoyer sur un ID de site, je vérifie ma DB pour l'enregistrement avec cet id et obtenir SITE_URL valeur de la colonne (www.yoursite.com).
```
header('Access-Control-Allow-Origin: http://'.$row['SITE_URL']);
```
Même si les envoyer sur un site valide ID de la requête doit être du domaine figurant dans ma DB associé à ce site ID.

InformationsquelleAutor mathius1

Voici une option d'étendue pour apache qui comprend quelques-uns des plus récents et prévus police définitions:

<FilesMatch "\.(ttf|otf|eot|woff|woff2|sfnt|svg)$">
    <IfModule mod_headers.c>
        SetEnvIf Origin "^http(s)?://(.+\.)?(domainname1|domainname2|domainname3)\.(?:com|net|org)$" AccessControlAllowOrigin=$0$1$2
        Header add Access-Control-Allow-Origin %{AccessControlAllowOrigin}e env=AccessControlAllowOrigin
        Header set Access-Control-Allow-Credentials true
    </IfModule>
</FilesMatch>

InformationsquelleAutor Mike Kormendy

Pour faciliter multiples accès de domaine pour un ASMX service, j'ai créé cette fonction dans le monde.asax fichier:

protected void Application_BeginRequest(object sender, EventArgs e)
{
    string CORSServices = "/account.asmx|/account2.asmx";
    if (CORSServices.IndexOf(HttpContext.Current.Request.Url.AbsolutePath) > -1)
    {
        string allowedDomains = "http://xxx.yyy.example|http://aaa.bbb.example";

        if(allowedDomains.IndexOf(HttpContext.Current.Request.Headers["Origin"]) > -1)
            HttpContext.Current.Response.AddHeader("Access-Control-Allow-Origin", HttpContext.Current.Request.Headers["Origin"]);

        if(HttpContext.Current.Request.HttpMethod == "OPTIONS")
            HttpContext.Current.Response.End();
    }
}

Cela permet de la SCRO manipulation de OPTIONS verbe aussi.

InformationsquelleAutor Derek Wade

PHP exemple de code pour la mise en correspondance des sous-domaines.

if( preg_match("/http:\/\/(.*?)\.yourdomain.example/", $_SERVER['HTTP_ORIGIN'], $matches )) {
        $theMatch = $matches[0];
        header('Access-Control-Allow-Origin: ' . $theMatch);
}

InformationsquelleAutor blak3r

Assez facile de copier /coller pour .NET applications, j'ai écrit ceci pour permettre la SCRO à partir de l'intérieur d'un global.asax fichier. Ce code suit les conseils donnés dans les actuellement accepté de répondre, reflétant la dos d'origine est donnée dans la demande dans la réponse. Ce bien un '*' sans l'utiliser.

La raison pour cela est qu'il permet à plusieurs autres caractéristiques de la SCRO, y compris la possibilité d'envoyer une requête AJAX XMLHttpRequest avec le "withCredentials' attribut de la valeur "true".

void Application_BeginRequest(object sender, EventArgs e)
{
    if (Request.HttpMethod == "OPTIONS")
    {
        Response.AddHeader("Access-Control-Allow-Methods", "GET, POST");
        Response.AddHeader("Access-Control-Allow-Headers", "Content-Type, Accept");
        Response.AddHeader("Access-Control-Max-Age", "1728000");
        Response.End();
    }
    else
    {
        Response.AddHeader("Access-Control-Allow-Credentials", "true");

        if (Request.Headers["Origin"] != null)
            Response.AddHeader("Access-Control-Allow-Origin" , Request.Headers["Origin"]);
        else
            Response.AddHeader("Access-Control-Allow-Origin" , "*");
    }
}

InformationsquelleAutor QA Collective

2

Une approche plus souple est d'utiliser Apache 2.4 expressions. Vous pouvez le match contre les domaines, les chemins, et juste au sujet de chaque d'autres demande variable. Si la réponse envoyée est toujours *, la seule demandeurs recevoir sont ceux qui répondent aux exigences de toute façon. À l'aide de la Origin (ou autre) en-tête de requête dans l'expression, Apache fusionner automatiquement dans le Vary en-tête de réponse, de sorte que la réponse ne sera pas réutilisé pour une origine différente.
```
<IfModule mod_headers.c>
    <If "%{HTTP:Host} =~ /\\bcdndomain\\.example$/i && %{HTTP:Origin} =~ /\\bmaindomain\\.example$/i">
        Header set Access-Control-Allow-Origin "*"
    </If>
</IfModule>
```
- Je suis venu ici parce que certains navigateurs n'acceptent pas * avec les informations d'identification comme Login. Ainsi, il sera mieux si vous passez à la correspondance nom d'hôte au lieu de *.
- comment fait-on dynamiquement capturer l'origine exacte et l'envoyer en arrière quand il y a de multiples origines, au lieu de répéter le code pour chaque domaine? On dirait qu'il à possible avec des expressions mais les docs ne sont pas claires pour moi.
- En fait mon vrai problème était parce que laravel n'a pas renvoyé de la Access-Control-Allow-Origin - tête pour OPTIONS de contrôle en amont demander que des contrôles pour les en-têtes pour voir si le serveur permet à cette origine. Je me suis fixé. Donc * n'était pas le vrai problème pour moi. Mais, là encore, certains navigateurs n'acceptent pas * avec des informations d'identification, donc lors d'une Web App est l'envoi de la Croix-Origine de la demande, ils doivent spécifier HTTP_ORIGIN en-tête auquel vous pouvez accéder de façon dynamique avec la variable Origin dans .htaccess pour Apache, ou $_SERVER['HTTP_ORIGIN']; en PHP. De toute façon, votre solution est la bonne, alors qu'elle permet à toutes les origines, mais moins sécurisé
- Mais 2 choses à retenir, c'est que 1) Fournir * permet tout. 2) l'ACCUEIL est différent de l'ORIGINE. L'HÔTE est l'HÔTE CIBLE` qui est passé à la tête de la demande. Mais l'ORIGINE est la INITIAL HOST qui envoyer la demande à la TARGET HOST. Par conséquent, dans votre code, ORIGIN HOST est ignoré et n'est jamais utilisé. Voir les réponses ci-dessus et vous verrez comment ils utilisent ORIGIN valeurs à ajouter dans Access-Control-Allow-Origin.
- Ne pas permettre à tout le monde parce que l'utilisation de la Origin en-tête de requête dans l'expression, Apache fusionner automatiquement dans le Vary en-tête de réponse, sauf si on utilise req_novary('Origin') (probablement indésirables). Les navigateurs savent qu'ils peuvent obtenir une réponse différente pour un autre Origin et si la valeur envoyée ne passe pas un test, le Access-Control-Allow-Origin en-tête n'est jamais réglé.
- Ne définissez jamais si elle ne parvient pas à correspondre à un sens. Je ne comprenais pas tous les comportements de htaccess, donc j'ai fait le mien directement à partir de Laravel code (PHP). Mais maintenant, je les comprends.
InformationsquelleAutor Walf

Et une réponse de plus en Django. Pour avoir une vue unique de permettre la SCRO à partir de plusieurs domaines, voici mon code:

def my_view(request):
    if 'HTTP_ORIGIN' in request.META.keys() and request.META['HTTP_ORIGIN'] in ['http://allowed-unsecure-domain.com', 'https://allowed-secure-domain.com', ...]:
        response = my_view_response() # Create your desired response data: JsonResponse, HttpResponse...
        # Then add CORS headers for access from delivery
        response["Access-Control-Allow-Origin"] = request.META['HTTP_ORIGIN']
        response["Access-Control-Allow-Methods"] = "GET" # "GET, POST, PUT, DELETE, OPTIONS, HEAD"
        response["Access-Control-Max-Age"] = "1000"  
        response["Access-Control-Allow-Headers"] = "*"  
        return response

InformationsquelleAutor Silvain

0

De Google de soutien de réponse sur la diffusion d'annonces sur SSL et la la grammaire dans la RFC lui-même semblerait indiquer que vous pouvez délimiter l'espace de l'Url. Pas sûr de savoir comment bien pris en charge c'est dans les différents navigateurs.
- 'la diffusion d'annonces sur ssl" les liens de la spec w3.org/TR/cors/#access-control-allow-origin-response-header qui ajoute une note, "En pratique, l'origine de la liste ou nulle de la production est limitée. Plutôt que de laisser un espace-liste séparée par des origines, c'est soit une origine unique ou de la chaîne de la valeur "null".
- Même s'il est important de noter que le détail, lorsqu'une spécification de la dit "En pratique", cela ne veut pas dire que c'est uniquement valide pour le faire de cette façon. Cela signifie que si vous le faites de cette façon, vous pourriez rencontrer des problèmes parce que la majorité des réalisateurs, soit mettre en œuvre la spécification incorrecte ou incomplète. La spécification ne permet pas pour un espace-liste séparée par des origines, que vous pouvez voir ici, dans l'EBNF sous origin-list: tools.ietf.org/html/rfc6454#section-7.1
InformationsquelleAutor Bob Aman
0

Si vous essayez donc de nombreux exemples de code comme moi pour le faire fonctionner à l'aide de la SCRO, il vaut la peine de mentionner que vous avez à effacer votre cache d'abord à essayer si cela fonctionne réellement, semblables à des questions comme quand les vieilles images sont toujours présents, même si il est supprimé sur le serveur (parce que c'est toujours enregistrées dans la mémoire cache).

Par exemple CTRL + MAJ + SUPPR dans Google Chrome pour supprimer le cache.

Cela m'a aidé à l'aide de ce code après avoir essayé de nombreux pure .htaccess solutions et cela semble être le seul à travailler (au moins pour moi):
```
    Header add Access-Control-Allow-Origin "http://google.com"
    Header add Access-Control-Allow-Headers "authorization, origin, user-token, x-requested-with, content-type"
    Header add Access-Control-Allow-Methods "PUT, GET, POST, DELETE, OPTIONS"

    <FilesMatch "\.(ttf|otf|eot|woff)$">
        <IfModule mod_headers.c>
            SetEnvIf Origin "http(s)?://(www\.)?(google.com|staging.google.com|development.google.com|otherdomain.com|dev02.otherdomain.net)$" AccessControlAllowOrigin=$0
            Header add Access-Control-Allow-Origin %{AccessControlAllowOrigin}e env=AccessControlAllowOrigin
        </IfModule>
    </FilesMatch>
```
Notez également qu'il est largement répandue que de nombreuses solutions dites que vous avez ce type de Header set ... mais il est Header add .... Espérons que cela aide quelqu'un ayant les mêmes problèmes depuis quelques heures maintenant, comme moi.

InformationsquelleAutor AlexioVay
0

- Dessous de la réponse est spécifique à C#, mais le concept devrait être applicable à toutes les plates-formes différentes.

Pour permettre l'Origine de la Croix-Requêtes à partir d'une api web, Vous devez l'Option autoriser les demandes de votre Application et Ajouter annotation ci-dessous au niveau du contrôleur.

[EnableCors(UrlString,L'En-Tête De La Méthode)]
Maintenant, les origines peuvent être passées uniquement une chaîne. DONC, si vous voulez passer plus d'une URL dans la demande de laissez-passer comme une séparation par virgule de la valeur.

UrlString = "https://a.hello.com,https://b.hello.com"

InformationsquelleAutor sakshi agrawal

Une seule origine peut être spécifié pour l'Access-Control-Allow-Origin-tête. Mais vous pouvez en définir l'origine dans votre réponse en fonction de la demande. Aussi n'oubliez pas de définir l'en-tête Vary. En PHP, je voudrais faire ce qui suit:

    /**
     * Enable CORS for the passed origins.
     * Adds the Access-Control-Allow-Origin header to the response with the origin that matched the one in the request.
     * @param array $origins
     * @return string|null returns the matched origin or null
     */
    function allowOrigins($origins)
    {
        $val = $_SERVER['HTTP_ORIGIN'] ?? null;
        if (in_array($val, $origins, true)) {
            header('Access-Control-Allow-Origin: '.$val);
            header('Vary: Origin');

            return $val;
        }

        return null;
    }

  if (allowOrigins(['http://localhost', 'https://localhost'])) {
      echo your response here, e.g. token
  }

InformationsquelleAutor Simon

-2

Nous pouvons également définir ce Mondial.asax fichier pour Asp.net application.

protected void Application_BeginRequest(object sender, EventArgs e)
    {

    //enable CORS
    HttpContext.Current.Response.AddHeader("Access-Control-Allow-Origin", "https://www.youtube.com");

    }

InformationsquelleAutor sudhAnsu63

-6

La réponse semble être d'utiliser l'en-tête plus d'une fois. C'est, plutôt que d'envoyer
```
Access-Control-Allow-Origin: http://domain1.example, http://domain2.example, http://domain3.example
```
envoyer
```
Access-Control-Allow-Origin: http://domain1.example
Access-Control-Allow-Origin: http://domain2.example
Access-Control-Allow-Origin: http://domain3.example
```
Sur Apache, vous pouvez le faire dans une httpd.conf <VirtualHost> section ou .htaccess fichier à l'aide de mod_headers et cette syntaxe:
```
Header add Access-Control-Allow-Origin "http://domain1.example"
Header add Access-Control-Allow-Origin "http://domain2.example"
Header add Access-Control-Allow-Origin "http://domain3.example"
```
L'astuce est d'utiliser add plutôt que append comme premier argument.
- Le truc a l'air prometteur, mais il ne fonctionne pas dans FF 3.6.13. Ce que j'observe, c'est que deux en-têtes avec le même nom sont regroupés en un seul, avec des valeurs séparées par une virgule -- et ça ne fonctionne pas, que l'OP posté. J'ai observé les en-têtes dans LiveHTTPHeaders et FireBug.
- Vous voyez, quand je l'ai fait, je l'ai fait "en-Tête set ..." plutôt que "en-Tête ajouter ..." - semble fonctionner pour moi. Firefox 3.6.16
- ce qui a fonctionné pour vous? Header set ou Header add?
- Ce n'est pas autorisé et ne fonctionne pas dans FF - bugzilla.mozilla.org/show_bug.cgi?id=671608
- il y a une variation sur ce qui semble fonctionner: stackoverflow.com/questions/9466496/...
- Je viens de passer deux heures à essayer de résoudre un problème lié à la SCRO et il s'avère que c'était à cause de multiple Access-Control-Allow-Origin-têtes. J'ai enlevé le multiple Access-Control-Allow-Origin-têtes et il a commencé à travailler. Donc ce n'est pas la bonne réponse, malgré le nombre de votes. Utiliser cette méthode plutôt que de prendre en charge plusieurs domaines: stackoverflow.com/a/1850482/123545
- Vous allez en effet avoir un message d'erreur dans le journal à partir de la dernière navigateur google Chrome à partir de maintenant, vous dire que c'est en ignorant le Access-Control-Allow-Origin-tête parce qu'il y a plusieurs valeurs.
- Nope. À partir de developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS : "Une ressource retournée peut avoir un Access-Control-Allow-Origin-tête" .. et à partir de w3.org/TR/cors/#access-control-allow-origin-response-header : "Plutôt que de laisser un espace-liste séparée par des origines, c'est soit une origine unique ou la chaîne de caractères "null" (première fois que j'ai entendu parler de "null" ici d'ailleurs)
- Ce n'est pas une réponse correcte.
- Le spécifications clairement dire que les multiples valeurs de la cause de la SCRO algorithme échoue. Donc ce n'est pas correct.
- Aussi, confirmant ce qui est incorrect. L'utilisation de ce servir CSS à quatre domaines, j'ai un message d'erreur dans google Chrome, journal "[...] en-tête contient plusieurs valeurs 'aaa.com, bbb.com, mais un seul est autorisé". Il n'a pas d'importance si vous le définir comme un en-tête ou à plusieurs, ou à l'aide de add vs set. Il ne fonctionne tout simplement pas.
InformationsquelleAutor Ben C. Forsberg

Vous devez vous connecter pour publier un commentaire.