I’m blogging this as it wasted about 3 hours of my time. I ended up debugging the Microsoft.AspNetCore.Cors library, and that takes time.
I was having issues with cross-domain AJAX requests (with AngularJS). Firefox was pretty shit at telling me the problem. The developer tools just show the failed request. IE was pretty verbal:
SEC7122: Credentials flag was set to true, but Access-Control-Allow-Credentials was not present or was not set to “true”.
Right on the spot. So using Fiddler, I spent some time reviewing HTTP packets (of course it is difficult with HTTPS and debugging) and IE was pretty much right. The response did not include Access-Control-Allow-Credentials: true
I tested it locally and it works fine. Debugging runtime in Azure is difficult (I would’ve lost another 3 hours probably) so I ended up guessing. It turns out that configuring CORS on the Azure Web Site overrides stuff in the underlying layers. Even though that ASP.NET Core is doing the right thing, somewhere (most likely on packet exit) Azure CORS takes control. So, if you want to use CORS in ASP.NET, avoid this:
Solution: remove all of them, including a “*” if you have one.
Unfortunately (for me), this is also documented (I went to document it myself, but it was already there!). All I had to do was find it 🙂
https://azure.microsoft.com/en-gb/documentation/articles/app-service-api-cors-consume-javascript/#app-service-cors-versus-web-api-cors clearly states:
“Don’t try to use both Web API CORS and App Service CORS in one API app. App Service CORS will take precedence and Web API CORS will have no effect. For example, if you enable one origin domain in App Service, and enable all origin domains in your Web API code, your Azure API app will only accept calls from the domain you specified in Azure.”
And even further, there is something on StackOverflow:
Ouch, painful, lesson learnt. Hope this helps you and saves you time.
For the record, Microsoft.AspNetCore.Cors ignores everything if the Origin header is not present:
