Edizione CORS ArcGIS 10.1 IIS (Condivisione delle risorse tra le origini)

Ho ArcGIS 10.1 installato con l'adattatore web per IIS. Ho aggiunto un file di configurazione alla radice di IIS7 per abilitare la condivisione delle risorse di origine incrociata (CORS) secondo questa pagina. Ho inserito il server ArcGIS abilitato cors nell'elenco dei server cors predefiniti come da questa pagina:

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

Tuttavia, quando la mia applicazione JavaScript ospitata su vmagsten invia una richiesta al server GIS (vmagstenone), ricevo l'errore

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

Modifica: il layer delle funzionalità non viene caricato. Ho anche provato a caricare un livello dinamico e anche questo non riesce con lo stesso errore _557 (vedi immagine)

Modifica: non dovrei vedere questo errore poiché i passaggi precedenti dovrebbero significare che il server supporta l'origine incrociata. Questa affermazione di esri che questo errore può essere ignorato non si applica in questo caso poiché questo server dovrebbe supportare cors. Significa che il primo errore sul server ESRI può essere ignorato.

!

Modifica: ecco una risposta di esempio da una query su questo livello che mostra che la risposta ha Access-Control-Allow-Origin

!

Dici di avere l'errore, ma il servizio non si carica effettivamente?

Chiedo, come ho visto questo post sui forum Esri che afferma:

Questo errore può essere tranquillamente ignorato. Ci sono casi in cui l'API non invierà una richiesta a // rest / info e sono i seguenti: Il browser non supporta CORS Il server è già elencato in esri.config.defaults.io.corsEnabledServers esri.config.defaults.io .corsDetection è falso JSON viene utilizzato al posto di JSONP nei seguenti casi: La risorsa da recuperare è sullo stesso dominio dell'applicazione La risorsa da recuperare è su un server che supporta CORS

Suppongo che accada anche in altre console del browser?

In caso contrario, puoi lanciare un registro di Fiddler o un file .HAR online da qualche parte (o inviarmi un'e-mail) e modificare questa risposta di conseguenza.

Mentre la risposta contiene Access-Control-Allow-Origin: *un'intestazione, contiene anche X-Frame-Options: SAMEORIGINe X-XSS-Protection: 1; mode=blockintestazioni. Queste sono le intestazioni del prefisso X, che non sono standard , quindi non sono sicuro al 100% se il tuo browser le sta onorando sull'intestazione consentita.

Puoi usare uno strumento come Fiddler per aggiungere e rimuovere le intestazioni dalle richieste del browser; questo potrebbe aiutarti a rintracciare ciò che sta accadendo.

Ecco cosa ha funzionato per me in IIS 8.0. Questo potrebbe essere diverso su altre versioni di IIS.

Rimuovere il file customHeadersnella directory principale del sito Web web.configo eliminare web.configcompletamente il file.

Quindi passare a ApplicationHost.configin Gestione configurazione IIS per l' arcgisapplicazione e aggiungere Access-Control-Allow-Originnome e *valore a customHeaders.

Non ho familiarità con la condivisione delle risorse tra le origini.
Uso la politica interdominio.

Hai configurato anche quello?

Ciò che alla fine ha funzionato per me è l'aggiunta di quanto segue al sito ROOT e NON l'applicazione per l'adattatore web . Ha senso? Non a me. Ma ha funzionato per me.

EDIT: questo dovrebbe andare nel file proxy DotNet chiamato 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>