Just wanted to make everyone aware of a potential issue with a possible conflict between the CORS functionality in Web Api V2 & Microsoft.Owin.Cors (v 2.1 Pre-Release). I needed CORS functionality in Web Api Service so i turned CORS functionality on
for Web Api:
public static class WebApiConfig
public static void Register(HttpConfiguration config)
var cors = new EnableCorsAttribute("*", "*", "*");
I also needed to utilize the token service for security in web api v2 and since its not a controller the above code doesn't work. So ended up having to use Microsoft.Owin.Cors.
public void ConfigureAuth(IAppBuilder app)
The problem this caused was two "Access-Control-Allow-Origin" headers to be added to the response when going through the controllers:
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Access-Control-Allow-Origin: http://localhost:14880 <--added by Microsoft.Owin.Cors
Access-Control-Allow-Origin: * <-- added by Web Api Cors Functionality.
IE11 was fine with this but latest Version of Chrome/Firefox were not. Here is the error from Chrome:
XMLHttpRequest cannot load http://localhost:1987/api/account/register. The 'Access-Control-Allow-Origin' header contains the invalid value 'http://localhost:14880, *'. Origin 'http://localhost:14880' is therefore not allowed access.
This had me questioning why they didn't use the same CORS mechanism but what if they needed different access security: Only Gets for the Token Service & Everything for the controllers. Should the token functionality be implemented in a controller? Should
both of them be checking if there already exists an "Access-Control-Allow-Orgin"?