CORS and Web-Tier Secured Services

[StephenWay]

Hi Everyone!

I have a situation where my application will be required to access web-tiered services across different domains.

I have added the following to the web config of web adapter:

<customHeaders>

     <add name="Access-Control-Allow-Credentials" value="true" />

     <add name="Access-Control-Allow-Origin" value="http://sub.domain.com" />

</customHeaders>

However, when testing in chrome, I receive the following error in console:

XMLHttpRequest cannot load <url to secured service>. the Access-Control-Allow-Origin header contains multiple values 'http://sub.domain.com,http://sub.domain.com' .http://sub.domain.com is therefore   not allowed access.

I have checked everything, i have definitly only configured one header in the web.config.  I am using the testing tool available on the enable cors site.

Against an unsecured sevrice, it works fine as we don't have to set the allow credentials header, but with secured services, it is not working.

Have also tried firefox, and i do not have IE available in this environment.

Thanks for anyone who can help!

Steve

[RobertScheitlin__GISP]

Gert,

  I use to add '<add name="Access-Control-Allow-Origin" value="*" />' to an IIS root folder location on all three of my ArcGIS Servers, but no I only have <remove name="Access-Control-Allow-Origin" /> as Jeff recommended on all three in the web.config of the IIS root folder.

[BillGrow]

Could you look in the IIS logs to see which document is actually throwing the error, and where the request is being stopped?  It sounds more like an IIS configuration error, than an error in the widely distributed ESRI WebAdaptor.  

Also, if ArGIS Server is throwing the error, make sure you are using the most current .net resource proxy code from github.  I've had clients simply replace the contents of the folder with the current Master branch and problems are resolved.   This piece acts as a wrapper for your application, and if used properly, emulates a same-origin request.

[GertConradie]

I just need to confirm the following:

• The .Net resource proxy play no role when I experience the problem, but rather it can be used to bypass/fix my problem. I also use a very recent version for my secured services.
• There is no server side error logged/vissible. The problem arrise when the browser look at the headers to decide if it is allowed to display it to you or not. (i.e. you see the message in the console section of your browser)
• Something on the server add an additional header value for 'Access-Control-Allow-Origin' that contain the orgin domain value (it change from where I made the call) - which sort of proove that it is not a fixed configuration value, but rather a configuration in IIS/the web adaptor that tell the server/ArcGIS to always add the orgin host value, whatever it might be.
• It is definately not WAB - I could replicate the problem with a very basic Javascript API map that request a layer - it behave the exact same way as WAB.

Robert, I tried the '<remove name="Access-Control-Allow-Origin" />', but it have no affect. What I do know is that the 'add' in the same web.config file for the web adaptor is used - any changes to replace the '*' value become visible in the multiple header's listed in the browser.

For now, I will remove the '<add name="Access-Control-Allow-Origin" value="*" />' from the adaptor's web.config and research it a bit more. All the access methods will keep on working.

I do acknowledge it is very likely a configuration on my server that cause this though, i just dont have an idea on where it can be. (Other than the web.config's in the IIS app/folder tree)

Note my web adoptor version is: 10.4.0

[RobertScheitlin__GISP]

Gert,

   FYI, I use the remove as the only thing in the custom headers section of my web.config I do not have it and some add

[GertConradie]

Hi Robert, yes I had it like that.

I did another test now - if I add '<add name="Access-Control-Allow-Origin" value="gert" />' in the IIS root web.config, then it is indeed removed by the 'remove' in the web adaptor's web.config.

Just as long as there is no '<add name="Access-Control-Allow-Origin" value="*" />' in the web adaptor's web.config all is good.

It sort of proove that the "phantom" header value is being set AFTER the web.config's are parsed/applied.