In my API, I have the following code:
public class CustomOAuthProvider : OAuthAuthorizationServerProvider
{
public override Task MatchEndpoint(OAuthMatchEndpointContext context)
{
if (context.OwinContext.Request.Method == "OPTIONS" && context.IsTokenEndpoint)
{
context.OwinContext.Response.Headers.Add("Access-Control-Allow-Methods", new[] { "POST" });
context.OwinContext.Response.Headers.Add("Access-Control-Allow-Headers",
new[] {
"access-control-allow-origin",
"accept",
"x-api-applicationid",
"content-type",
"authorization"
});
context.OwinContext.Response.Headers.Add("Access-Control-Allow-Origin", new[] { "*" });
context.OwinContext.Response.StatusCode = (int)HttpStatusCode.OK;
context.RequestCompleted();
return Task.FromResult<object>(null);
}
return base.MatchEndpoint(context);
}
// ... even more code, but not relevant
}
When I connect to this API from Chrome, everything works perfect. When I connect from the same computer to the same API, but only from a different browser, Internet Explorer 11, I get the following error:
SEC7123: Request header x-api-applicationid was not present in the Access-Control-Allow-Headers list.
I debugged the code, and I see the headers are added to the response. Even IE shows the headers:
What does IE expect?
Update
If I change the order of the headers from
new[] {
"access-control-allow-origin",
"accept",
"x-api-applicationid",
"content-type",
"authorization"
}
to:
new[] {
"content-type",
"accept",
"access-control-allow-origin",
"x-api-applicationid",
"authorization"
}
The error message changes to:
SEC7123: Request header access-control-allow-origin was not present in the Access-Control-Allow-Headers list.
So it always gives an error on the third header.
No need to remove
MatchEndPoint
Instead of adding array element just add Comma-Separated value as first array element in Access-Control-Allow-Headers
Instead of
use
Make sure it's not as simple as a misspelling of the content-type header in your AJAX. I was getting this with an OPTIONS preflight with an
application/x-www-form-urlencoded
content-type, which doesn't necessitate a preflight, but I hadcontent-type: application/x-www-form-urlencoded
instead of
application/x-www-form-urlencoded
as my
contentType
option.WRONG:
RIGHT:
I've found a piece of code here which fixed it for me.
I removed the
MatchEndpoint
method from my CustomOAuthProvider.cs