CORS-Ausgabe ArcGIS 10.1 IIS (Cross Origin Resource Sharing)

Ich habe ArcGIS 10.1 mit dem Webadapter für IIS installiert. Ich habe dem Stammverzeichnis von IIS7 eine Konfigurationsdatei hinzugefügt, um die Cross Origin Resource Sharing (CORS) gemäß dieser Seite zu aktivieren . Ich habe den cors-fähigen ArcGIS-Server in die Liste der Standard-cors-Server gemäß dieser Seite verschoben :

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

Wenn jedoch meine auf vmagsten gehostete JavaScript-Anwendung eine Anfrage an den GIS-Server (vmagstenone) sendet, wird der Fehler angezeigt

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

Bearbeiten: Der Feature-Layer kann nicht geladen werden. Ich habe auch versucht, eine dynamische Ebene zu laden, und auch dies schlägt mit demselben Fehler fehl _557 (siehe Bild)

Bearbeiten: Ich sollte diesen Fehler nicht sehen, da die obigen Schritte bedeuten sollten, dass der Server Cross-Origin unterstützt. Diese Aussage von esri, dass dieser Fehler ignoriert werden kann, gilt in diesem Fall nicht, da dieser Server cors unterstützen sollte. Dies bedeutet, dass der erste Fehler auf dem ESRI-Server ignoriert werden kann.

!

Bearbeiten: Hier ist eine Beispielantwort von einer Abfrage auf dieser Ebene, die zeigt, dass die Antwort Zugriffssteuerung-Zulassen-Ursprung hat

!

Sie erwähnen, dass Sie den Fehler erhalten, aber kann der Dienst tatsächlich nicht geladen werden?

Ich frage, als ich diesen Beitrag in den Esri-Foren entdeckte, in dem es heißt:

Dieser Fehler kann ignoriert werden. Es gibt Fälle, in denen die API keine Anforderung an // rest / info sendet und wie folgt lautet: Der Browser unterstützt CORS nicht. Der Server ist bereits in esri.config.defaults.io.corsEnabledServers esri.config.defaults.io aufgeführt .corsDetection ist false JSON wird in den folgenden Fällen anstelle von JSONP verwendet: Die abgerufene Ressource befindet sich in derselben Domäne wie die Anwendung. Die abgerufene Ressource befindet sich auf einem Server, der CORS unterstützt

Ich gehe davon aus, dass es auch in anderen Browserkonsolen passiert?

Wenn nicht, können Sie irgendwo ein Fiddler-Protokoll oder eine .HAR-Datei online stellen (oder mir eine E-Mail senden) und diese Antwort entsprechend bearbeiten.

Während die Antwort einen Access-Control-Allow-Origin: *Header enthält, enthält sie auch X-Frame-Options: SAMEORIGINund X-XSS-Protection: 1; mode=blockHeader. Dies sind X-Präfix-Header, die nicht dem Standard entsprechen . Daher bin ich mir nicht 100% sicher, ob Ihr Browser sie über den zulässigen Header hinweg berücksichtigt.

Sie können ein Tool wie Fiddler verwenden , um Header zu Browseranforderungen hinzuzufügen und daraus zu entfernen. Dies kann Ihnen helfen, das Geschehen aufzuspüren.

Folgendes hat in IIS 8.0 für mich funktioniert: Dies kann bei anderen Versionen von IIS anders sein.

Entfernen Sie entweder customHeadersdie web.configDatei im Stammverzeichnis der Website oder löschen Sie die web.configDatei vollständig.

Wechseln Sie dann ApplicationHost.configim IIS Configuration Manager für die arcgisAnwendung zu und fügen Sie dem Access-Control-Allow-OriginNamen und den *Wert hinzu customHeaders.

Ich bin nicht mit der gemeinsamen Nutzung von Ressourcen vertraut.
Ich verwende die domänenübergreifende Richtlinie.

Haben Sie das auch konfiguriert?

Was für mich schließlich funktioniert hat, ist das Hinzufügen von Folgendem zur ROOT- Site und NICHT der Anwendung für den Webadapter . Macht das Sinn? Nicht für mich. Aber es hat bei mir funktioniert.

BEARBEITEN: Dies sollte in der DotNet-Proxy-Datei mit dem Namen Web.config enthalten sein.

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