Problème CORS ArcGIS 10.1 IIS (partage des ressources d'origine croisée)


11

ArcGIS 10.1 est installé avec l'adaptateur Web pour IIS. J'ai ajouté un fichier de configuration à la racine d'IIS7 pour activer le partage de ressources d'origine croisée (CORS) selon cette page. J'ai poussé le serveur ArcGIS activé cors dans la liste des serveurs cors par défaut selon cette page:

esri.config.defaults.io.corsEnabledServers.push("vmagstenone")). 

Cependant, lorsque mon application JavaScript hébergée sur vmagsten fait une demande au serveur SIG (vmagstenone), j'obtiens l'erreur

"Origin http://vmagsten is not allowed by Access-Control-Allow-Origin.". 

Modifier: Et la couche d'entités ne parvient pas à charger. J'ai également essayé de charger une couche dynamique et cela échoue également avec la même erreur _557 (voir image)

Edit: je ne devrais pas voir cette erreur car les étapes ci-dessus devraient signifier que le serveur prend en charge l'origine croisée. Cette déclaration d'esri que cette erreur peut être ignorée ne s'applique pas dans ce cas car ce serveur doit prendre en charge les cors. Cela signifie que la première erreur sur le serveur ESRI peut être ignorée.

entrez la description de l'image ici!

Modifier: voici un exemple de réponse à une requête sur cette couche montrant que la réponse a Access-Control-Allow-Origin

entrez la description de l'image ici!


3
Vous voudrez peut-être définir CORS, afin qu'il soit clair que nous parlons de partage des ressources d'origine croisée et non d'une station de référence fonctionnant en continu , qui est utilisée pour le GPS.
Kirk Kuykendall

2
Vous êtes-vous assuré que votre IIS renvoie les en-têtes requis pour CORS?
Devdatta Tengshe

@DevdattaTengshe J'ai édité le post ci
David Wilton

Réponses:


4

Vous mentionnez que vous obtenez l'erreur, mais le service ne parvient-il pas à se charger?

Je demande, car j'ai repéré ce post sur les forums Esri qui dit:

Cette erreur peut être ignorée en toute sécurité. Il existe des cas où l'API n'enverra pas de demande à // rest / info et sont les suivants: Le navigateur ne prend pas en charge CORS Le serveur est déjà répertorié dans esri.config.defaults.io.corsEnabledServers esri.config.defaults.io .corsDetection est false JSON est utilisé à la place de JSONP dans les cas suivants: La ressource en cours de récupération est sur le même domaine que l'application La ressource en cours de récupération se trouve sur un serveur qui prend en charge CORS

Je suppose que cela se produit également dans d'autres consoles de navigateur?

Sinon, pouvez-vous lancer un journal Fiddler ou un fichier .HAR en ligne quelque part (ou m'envoyer un e-mail), et modifier cette réponse en conséquence.


Désolé, j'aurais dû mentionner que je l'ai vu. Le service ne parvient pas à charger. Je publierai l'erreur depuis Firefox. Il n'échoue pas dans IE
David Wilton

Je pense que vous avez probablement raison de dire que les deux premières erreurs doivent être ignorées car ESRI dit que celles-ci sont attendues. Cependant, l'erreur _557 provenant du framework semble être le problème. Je reçois la même erreur dans les versions 3.3 et 3.4
David Wilton

1
J'ai également essayé d'utiliser une couche dynamique plutôt qu'une couche d'entités et qui a le même problème. Si le site est hébergé sur le même serveur que les données, il n'y a pas d'erreur. En utilisant chrome.exe --disable-web-security (n'applique pas la stratégie cors), les demandes sont correctes. C'est ce qui m'amène à croire que c'est un problème avec Coors et la demande.
David Wilton

2

Bien que la réponse contienne un en- Access-Control-Allow-Origin: *tête, elle contient également des en X-Frame-Options: SAMEORIGIN- X-XSS-Protection: 1; mode=blocktêtes et . Ce sont des en-têtes de préfixe X, qui ne sont pas standard , donc je ne suis pas sûr à 100% si votre navigateur les respecte par-dessus l'en-tête d'autorisation.

Vous pouvez utiliser un outil comme Fiddler pour ajouter et supprimer des en-têtes des demandes du navigateur; cela pourrait vous aider à suivre ce qui se passe.


2

Voici ce qui a fonctionné pour moi dans IIS 8.0. Cela peut être différent sur d'autres versions d'IIS.

Supprimez le customHeadersdans le web.configfichier du répertoire racine du site Web ou supprimez web.configcomplètement le fichier.

Basculez ensuite vers le ApplicationHost.configdans le Gestionnaire de configuration IIS pour l' arcgisapplication et ajoutez le Access-Control-Allow-Originnom et la *valeur au customHeaders.

Éditeur de configuration IIS 8.0

CustomHeaders


1

Je ne connais pas le partage des ressources d'origine croisée.
J'utilise la politique interdomaines.
politique interdomaines
L'avez-vous également configuré?


1
Oui, j'ai les deux fichiers crossdomain.xml clientaccesspolicy.xml configurés par l'installation du serveur ArcGIS. Cependant, je crois comprendre que ces fichiers concernent des applications Flex et Silverlight (lien). Je vais modifier la question pour qu'il soit clair que je parle uniquement de JS resources.arcgis.com/en/help/install-guides/arcgis-server/10.1/…
David Wilton

1

Ce qui a finalement fonctionné pour moi, c'est d'ajouter ce qui suit au site ROOT et NON à l'application pour l'adaptateur Web . Est-ce que ça fait du sens? Pas à moi. Mais ça a marché pour moi.

EDIT: Cela devrait aller dans le fichier proxy DotNet appelé Web.config.

<configuration>
  <...rest of file...>
    <system.webServer>
      <httpProtocol>
       <customHeaders>
         <add name="Access-Control-Allow-Origin" value="*" />
       </customHeaders>
      </httpProtocol>
    </system.webServer>
  </...rest of file...>
</configuration>

entrez la description de l'image ici


C'ÉTAIT la réponse qui a fonctionné pour moi ... J'édite votre réponse afin de clarifier ce qui doit être ajusté.
randomblink
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.