Disable CORS Discussion

[MatthewLawton]

I've been ignoring the "Origin is not allowed by Access-Control-Allow-Origin" errors (aka the CORS error) in my apps for many months now, like a good ArcGIS JS API developer. I haven't paid much attention to CORS, but finally decided to devote a little time to researching it. I get the error because I package some Esri services onto my map. If I understand the error correctly, it is getting thrown because I am using web services in my app from an external server that either:

a) Doesn't like that my server is connecting to it because my server has not been whitelisted by CORS

or

b) My server doesn't like that I am connecting to the Esri server because it hasn't been whitelisted by CORS

I'm not sure exactly which scenario is correct, but nonetheless I get the error.

In reading, I stumbled across Kelly Hutchins's post from June 2012 here:

http://forums.arcgis.com/threads/59988-Issue-Upgrading-to-version-3.0?p=207055&viewfull=1#post207055

I've probably read that post a half dozen times over the last 10 months, but I stopped to actually understand what it was telling me. There is a parameter called "esri.config.defaults.io.corsDetection", that has apparently existed since JSAPI 3.0, that can be set to "false". So I went ahead and added this line to my Init function and *poof!*, no more CORS error.

So why don't I see this as a solution in the various CORS related posts on these forums? Instead I see Esri staff saying "just ignore the error". Is it bad to disable the CORS detection? Is it doing something that I don't want?

I understand the idea behind CORS, that it is to provide more secure access between dynamic data services, etc., but it seems to be slow to adoption, so why wouldn't I just disable it for now? Has everybody else known about this solution and I am just now figuring it out?

[derekswingley1 · Accepted solution]

I've not recommended this previously for a couple of reasons.

When we added support for CORS, and subsequently saw the errors everyone is now familiar with, the reasoning at the time was that they would be temporary since the basemap services which were causing all those errors were at ArcGIS Server 10.0 and slated to be upgraded to 10.1 (which has CORS enabled by default). The 10.1 upgrade never came and no one pushed to manually enable CORS on those servers so those errors have been around for much longer than we imagined.

We didn't add CORS support to the API so that we could tell people to turn it off, we want it to be used. Once you start turning it off, being that we copy/paste and/or use templates quite a bit, how likely are you to re-evaluate that decision and turn it on when it can be used? Another option is to use corsDetection = false and manually populate corsEnabledServers but that's more work and error prone.

[MatthewLawton]

Thank you for the clarification, Derek.

So it sounds like what is happening in my apps is option B described above. If services.arcgisonline.com was upgraded to 10.1 and CORS enabled then I would not get this error, right?

And if I am reading you right, the danger with setting "esri.config.defaults.io.corsDetection = false" in my apps is that I am now not checking ANY server I connect to with CORS, and with the big idea that everybody should be enabling CORS on their servers, this is not a good thing.

I'm sure it is out of your control, but if my second assumption is true, then Esri really should be upgrading services.arcgisonline.com, especially with it now two versions out of date. But I don't blame you guys, the upgrade from 10.0 to 10.1 is really a pain.

Next time we get asked by our rep why we are not on 10.2 (or why it took over a year to get to 10.1), I will point them to services.arcgisonline.com 😉

[derekswingley1]

So it sounds like what is happening in my apps is option B described above. If services.arcgisonline.com was upgraded to 10.1 and CORS enabled then I would not get this error, right?

Correct. You can confirm by taking a closer look at the error�?? the URL that failed the CORS test is right there in the message. Here's an example of a CORS error from the create a map sample:

XMLHttpRequest cannot load http://services.arcgisonline.com/ArcGIS/rest/info?f=json. Origin http://developers.arcgis.com is not allowed by Access-Control-Allow-Origin. (ind

And if I am reading you right, the danger with setting "esri.config.defaults.io.corsDetection = false" in my apps is that I am now not checking ANY server I connect to with CORS, and with the big idea that everybody should be enabling CORS on their servers, this is not a good thing.

Yes, corsDetection = false disables CORS testing for all services used in an app. The hope and promise of CORS was that everyone would be using it, but in practice, servers with CORS enabled are relatively rare, at least in my experience.

I'm sure it is out of your control, but if my second assumption is true, then Esri really should be upgrading services.arcgisonline.com, especially with it now two versions out of date. But I don't blame you guys, the upgrade from 10.0 to 10.1 is really a pain.

Next time we get asked by our rep why we are not on 10.2 (or why it took over a year to get to 10.1), I will point them to services.arcgisonline.com 😉

I figured you'd say something like that ;). I'm not in a position to give an estimate as to when our basemap services will be upgraded and use CORS, but I do know those plans are still in the works.