Access Control Allow Origin - Portal + Hosting Server

[AllenScully]

This @#$# issue is making me crazy.

We have a Portal instance, using the distributed model:

1 Portal machine, with Web Adaptor

1 Federated and hosting server with Web Adaptor. - the federation validates successfully, and I see items published there directly in my content in Portal)

1 server for Datastore (not really in play for this issue, I don't think)

I published a bunch of layers as REFERENCED feature layers through the hosting server (we need the data to be live).

These layers will not draw on a map - 'Access-Control-Allow-Origin' has no value.  So, on the Portal server, I go in to IIS, at the web adaptor level, and add 'Access-Control-Allow-Origin' with a value of * - it then says this is not allowed either if credentials are being passed (I think that's what the message means) - 

I'm about to give up, move to the country, make an honest living.  The Access Control Allow Origin issue comes up from time to time, and I simply cannot find a real solution.  

I have tried adding the header at all levels of IIS (default website, web adaptor level, machine name level) - currently, for testing, there are no entries on IIS on either the hosting server or the Portal server, and no custom headers in the webconfig file at wwwroot.  

We are enforcing HTTPS only in the portal site, certificates all in place and bound in IIS, plus the root/intermediate ones uploaded into Portal/Server Admin pages, and neither Portal nor Server are using the default self-signed certs - both using the same wildcard domain certs that are our standard.

I'm at a complete loss to make this work, much less know where to look for what the best practice is.  

Any insight is hugely appreciated.

Thanks - 

Allen

[AngusHooper1]

What version of ArcGIS? I would not apply CORS handling at the iis tier for 10.6+ in my experience. Have you added any servers to the trusted server list in Portal? Are the CORS errors happening across all clients & domains, or only a subset? In he response headers, you want to be seeing access-control-allow-credentials set to true and access-control-allow-origin the appropriate FQDN.

[RandallWilliams]

Don't add CORS headers at the web tier. CORS is supported at the GIS Server and Portal tier. By default allowed origins are set to allow *.

[AllenScully]

 - We're using 10.6.1

 - No trusted servers added - my understanding is that is only needed in cases where Portal needs to access map/feature services from ArcServer machines that use web-tier security, which is not in play here.

Interesting development - when I share these layers that were throwing the 'layers cannot be added to map' errors in Portal (and showing the CORS blocking/Access-Control-Allow-Origin error in dev. tools) with everyone, they draw on the map.  What's odd about this is that I am both the owner of these items in Portal as well as an administrator, so sharing shouldn't make a difference in what I can and can't access for these particular layers - they are in my content after all.  

This makes me think it's an issue with security, and passing credentials between the federated/hosting server and the Portal server.  This is frustrating because typically I have seen that federation should handle this seamlessly.  

Thanks Angus and Randall for your input.

[SeanO_Neill]

Hi Allen, did you ever find a solution to this?  I too am ready to move to the country and make an honest living due to the same issue...

[DeanHowell1]

We are having the same issue in 10.8.1. Did you find out the issue?