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

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.

!

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

!

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.

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.

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.

Je ne connais pas le partage des ressources d'origine croisée.
J'utilise la politique interdomaines.

L'avez-vous également configuré?

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>