WorldWindEarth / explorer

WorldWindExplorer: A 3D virtual globe geo-browser app framework based on WorldWindJS, Bootstrap and KnockoutJS. Includes 3D globe and 2D map projections, imagery, terrain, markers, plus solar and celestial data.
https://worldwind.earth/explorer
MIT License
75 stars 24 forks source link

Access-Control-Allow-Origin header contains multiple values but only one is allowed #127

Closed emxsys closed 6 years ago

emxsys commented 6 years ago

CORS (Cross Origin Resource Sharing) Issue

Multiple Access-Control-Allow-Origin headers were returned when attempting to add an ArcGIS WMS server to the Explorer (the origin domain and "*"). This caused an error in the browser and thus the WMS GetCapabilities response was not loaded.

Error reported by Chrome

Failed to load http://.../arcgis/services/.../WMSServer?service=WMS&request=GetCapabilities&vers: 
The 'Access-Control-Allow-Origin' header contains multiple values 'http://explorer.worldwind.earth, *', but only one is allowed.
Origin 'http://explorer.worldwind.earth' is therefore not allowed access.
emxsys commented 6 years ago

I contacted the system administrator for the ArcGIS/IIS server that was generating the CORS error. I shared the http://www.test-cors.org site as a vehicle for generating cross-origin requests.

She investigated and resolved the issue by removing the IIS configuration that was adding the "*" Access-Control-Allow-Origin header, leaving ArcGIS with the responsibility to echo back the origin's domain in the sole Access-Control-Allow-Origin header.

She was kind enough to share what she did so others could gain from this experience.

Solution

Hi Bruce,

For posterity, this is what I did to fix the issue.

I did a search for access-control-allow-origin-header arcgis server. Most articles weren't terribly helpful, but one mentioned making a change in the web.config file.

So on our production server, I did a search for web.config. I found several under different sub folders of our website, but the one I edited was saved on the web root of our IIS webpage. Since I had made no changes on our test server to the IIS configuration, there was no web.config file so our [test] WMS services could be used by Worldwind.

The web.config file at the web root our our IIS website of our production server had the following text:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <!--<httpProtocol>
            <customHeaders>
                <add name="Access-Control-Allow-Origin" value="*" lockItem="false" />
                <add name="Access-Control-Allow-Headers" value="Content-Type" />
                <add name="Access-Control-Allow-Methods" value="POST,GET,OPTIONS" />
            </customHeaders>
        </httpProtocol>-->
        <defaultDocument>
            <files>
                <clear />
                <add value="index.htm" />
                <add value="Default.htm" />
                <add value="Default.asp" />
                <add value="index.html" />
                <add value="iisstart.htm" />
                <add value="default.aspx" />
            </files>
        </defaultDocument>
    </system.webServer>
</configuration>

You can see that I have commented out the httpProtocol segment that contains the Access-Control-Allow-Origin variables that were causing the CORS issues. Once those were commented out, the issue was resolved.

I felt confident that commenting out the httpProtocol segment would not break our server since we have a mirror server of this production server that also had a web.config file at the web root. It did not have the httpProtocol segment and our mirror production server was running as expected.

So that was the fix. I am not certain why that httpProtocol was put in place to begin with. It may have been done by our [web app] developer when the site was being built. Our sites seem to be functioning with out it just fine. If I find we have some missing functionality, I'll have to revisit this issue to find a better solution.