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: The cors functionality baked in web api will only work if your sitting behind a controller. Unfortunately the token functionality in web api isn't behind a controller its in an owin component. So essentially you use the core cors functionality baked in web api for "most" things. Unfortunately you then you have to use Microsoft.Owin.Cors for the token service. While i agree with you that you could implement a "second" token service you really shouldn't "have" to. This adds complexity that really shouldn't have to be added. A service should be able to take care of its own security. I don't want to go down the path of trying to use an external STS service :). Please be aware this is according to how i understand things currently. I could be incorrect. So don't be shy to correct me if i mispoken.
```
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: The cors functionality baked in web api will only work if your sitting behind a controller. Unfortunately the token functionality in web api isn't behind a controller its in an owin component. So essentially you use the core cors functionality baked in web api for "most" things. Unfortunately you then you have to use Microsoft.Owin.Cors for the token service. While i agree with you that you could implement a "second" token service you really shouldn't "have" to. This adds complexity that really shouldn't have to be added. A service should be able to take care of its own security. I don't want to go down the path of trying to use an external STS service :). Please be aware this is according to how i understand things currently. I could be incorrect. So don't be shy to correct me if i mispoken.