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("*", "*", "*");
config.EnableCors(cors);
```
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)
{
app.UseCors(CorsOptions.AllowAll);
........
```
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
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.0
Access-Control-Allow-Origin: http://localhost:14880 <--added by Microsoft.Owin.Cors
Access-Control-Allow-Credentials: true
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"?
Comments: Hi, i decided to try your last option and it worked perfectly. You still might want to consider though changing how that works. I'm sure there will be more people in the future that hit this problem. Anyways, thanks for your help :).
```
public static class WebApiConfig
{
public static void Register(HttpConfiguration config)
{
var cors = new EnableCorsAttribute("*", "*", "*");
config.EnableCors(cors);
```
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)
{
app.UseCors(CorsOptions.AllowAll);
........
```
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
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.0
Access-Control-Allow-Origin: http://localhost:14880 <--added by Microsoft.Owin.Cors
Access-Control-Allow-Credentials: true
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"?
Comments: Hi, i decided to try your last option and it worked perfectly. You still might want to consider though changing how that works. I'm sure there will be more people in the future that hit this problem. Anyways, thanks for your help :).