topic Re: Yet another CORS issue in ArcGIS JavaScript Maps SDK Questions

Yet another CORS issue

AdrianMarsden — Sun, 12 Dec 2021 03:35:17 GMT

I thought I had seen the last of these. However, I am trying to retrieve the EXIF metadata of attached images using this code jseidelin/exif-js · GitHub - it works when I run the example page and load in the full URL of the images returned via a " featureLayer.queryAttachmentInfos" command.

However, the AGS server being a different domain to my site hits CORS issues - which I thought I had sorted by changes to web.config and adding the server name in with a "esri.config.defaults.io.corsEnabledServers.push"

However, when I try to retrieve the data using a simple function

        for (index = 0; index < attachmentPath.length; ++index) {
            var image = new Image();
            image.src = attachmentPath[index];
          




            image.onload = function () { // always fires the event.




                EXIF.getData(this, function () {
                    console.debug(this)
                    var make = EXIF.getTag(this, "Make"),
                        model = EXIF.getTag(this, "Model");
                    alert("I was taken by a " + make + " " + model);
                });
            };
           ....do stuff with the info returned
        }

I get

XMLHttpRequest cannot load http://<<server name>>/arcgis/rest/services/test/emap2/MapServer/22/2009/attachments/8. Request header field If-Modified-Since is not allowed by Access-Control-Allow-Headers.

All other requests to resources using the server name seem fine.

I'm stumped. All I want to do is to know which way up to display the attachments!

Re: Yet another CORS issue

JeffJacobson — Wed, 25 Mar 2015 16:29:34 GMT

Are you sure that CORS is enabled on your ArcGIS Server? (Older versions of ArcGIS Server did not have CORS enabled by default.)

Re: Yet another CORS issue

AdrianMarsden — Thu, 26 Mar 2015 09:30:31 GMT

I'm using 10.2.2 and I believe it is all enabled - the same results occur when I strip the code out and have no AGS component.

OK - also tested it in IE - it gave me an alert about loading stuff outside of control, but loaded OK (failed elsewhere, but that my problem)

Firefox gave

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://<<server name>>/arcgis/rest/services/test/emap2/MapServer/22/2006/attachments/6/index.html. This can be fixed by moving the resource to the same domain or enabling CORS.

So, assuming I haven't got CORS enabled - how do I? I have read about this for several years now, and yet found a simple answer.

I have

</customHeaders>

In my webconfig.

Cheers

ACM

Re: Yet another CORS issue

AdrianMarsden — Thu, 26 Mar 2015 16:30:18 GMT

Also, I think I am confused over what server needs what, or rather what part of the same server needs what.

I have my AGS component. That runs on the default website of IIS . It has a web.config and settings in IIS.

Then there is my application. On the same server, but a different site in IIS. That also has its settings and (potentially) a web.config.

I have tried all sorts of combinations of edits to web.config and either the page fails totally with a http 500, it fails with

The 'Access-Control-Allow-Origin' header contains multiple values 'http://applicationservername, *', but only one is allowed.

Or the other error above.

I am really bashing head against wall here.

Re: Yet another CORS issue

GaryBushek — Wed, 03 Jun 2015 15:33:22 GMT

Having the same issue. Were you able to resolve this? I set the response header to enable Cors on the server and added esriConfig.defaults.io.corsEnabledServers to the code but no luck.

Thanks

Re: Yet another CORS issue

AdrianMarsden — Wed, 03 Jun 2015 15:37:06 GMT

Things are a lot better now. I stripped things right back, removed any CORS related stuff from any web.config files (I had a few at different levels of the site) and ensured that the settings were only specifed in one location - I can't pinpoint what I did, as it was a case of trying loads of stuff at random. I still don't know which part of the server was rejecting it, the calling page or the site being called.

Re: Yet another CORS issue

AndrewRay1 — Tue, 07 Jun 2016 14:27:10 GMT

I just ran into a similar issue with the Access-Control-Allow-Headers not including the "pragma" header, for some reason a client applicaiton was adding that header to the request and then when my server did not echo it back as an acceptable header in the response header "Access-Control-Allow-Headers" the browser (google chrome) would fail the preflight and not perform the "get" operation.

does the web adapter or server handle the response for CORS requests or if this something i need to do inside my web.config.

note: i am running 10.3.1 portal on windows + web adapter in IIS