Cross-Origin Resource Sharing policy (CORS)

Hi,

I am trying to show maps that are loaded from ArcGIS Server that we locally host, and I keep having trouble with (CORS).

I have to mention that when I launch the program within the WebStorm, it works just fine and everything loads with no problem. But when I copy the files on the webserver, and having IIS deliver the pages I keep getting the following error:

Image from origin 'AddressRemoved' has been blocked from loading by Cross-Origin Resource Sharing policy: The 'Access-Control-Allow-Origin' header has a value 'http://localhost:63342' that is not equal to the supplied origin. Origin 'http://localhost' is therefore not allowed access.

* I change the first address to to "AddressRemoved

I have provided a web.config file with the following content:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
   <httpProtocol>
     <customHeaders>
       <remove name="Access-Control-Allow-Origin" />
     <add name="Access-Control-Allow-Origin" value="*" />
     </customHeaders>
   </httpProtocol>
</system.webServer>
</configuration>

The above line is supposed to fix this problem but some how it is not. Any help or idea?

mabou,

I had same issue but in my case google images were causing and i changed them to my domain.
From <Icon> <href>http://maps.google.com/mapfiles/kml/shapes/shaded_dot.png</href>
</Icon>
                                                          
to

<Icon> <href>http://mydomain.com/myfiles/kml/shapes/shaded_dot.png</href> </Icon>

It worked for me.

Thanks

Thank you for the reply.

However, it is not possible for me to move the data to the same server. The web server are hosted on one machine, and the data are coming from ESRI ArcGIS server located on another server. So, it is not possible to move them on a single machine.

I noticed that this problem only exists on Google Chrome running on windows. IE and Firefox are just fine, and Google Chrome on Mac also does not have any problem.

Also, when I am locally testing the software running WebStorm, it runs just fine on google chrome on windows too.

mabou,
But you can change path on run time too. Before loading kml to load function.
If path is the issue.

I am just saying ....

Thanks

Hi,

I’ve seen a number of servers starting to return a header like:

Access-Control-Allow-Origin: whatever.you.domain.you.requested.from.com

Instead of

Access-Control-Allow-Origin: *

As far as I can tell, this is completely silly behavior. But it happens, and then, to make matters worse, Chrome caches it. So you request a cross-origin resource from a site running on one hostname, and it works fine. Then you do the same from a site running on a different hostname, and Chrome pulls the previous response from cache. But the cached response has a CORS header that says only the first hostname can access it, so the CORS check fails and you see the error in your original email. Ugh.

Easy solution (at least during development): clear your browser’s cache when switching between sites hosted on different domains/ports.

Kevin

could you elaborate more on what you said?

So, This is the line I request data

            var loadedLayer=new Cesium.ArcGisMapServerImageryProvider({
                url : myGVars.mapServiceURL,
                layers: layer2Load.toString()
                });

myGVars stores all the global vars and mapServiceURL is the URL to the specific data set hosted on ESRI ArcGIS server on another machine with different address (using port 6080 to deliver).

When I get the CORS error, it is said to be on index.html:1 but then it is followed by couple of following error:

An error occurred in "": Failed to obtain image tile X: 3 Y: 0 Level: 2. Cesium.js:422

(the X,Y, and level changes, of courses).

Well, so CORS blocks data from loading and then Cesium produces those error.

Thank you. I will try this Tomorrow. From what I have read, this is also better in terms of security to allow access only to those URLs that are actually needed anyway.

thank you Kevin for your help. It resolved the issue.

So, the configuration that I posted above had fixed the solution, i.e. <add name="Access-Control-Allow-Origin" value="*" />.

All I needed was to clear the cache of Google Chrome.