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: Yes it does seem broken. We are going to take a look. Here are a few interesting alternatives: 1. Fork the pipeline // For more information on how to configure your application, visit http://go.microsoft.com/fwlink/?LinkID=316888 var builder = app.New(); var config = new HttpConfiguration(); builder.UseWebApi(config); var appFunc = (AppFunc)builder.Build(typeof(AppFunc)); app.Map("/token", subApp => { subApp.UseCors(CorsOptions.AllowAll); subApp.Use(new Func<AppFunc, AppFunc>(next => appFunc)); }); app.Use(new Func<AppFunc, AppFunc>(next => appFunc)); 2. Use MapWhen, and pass in a predicate, now you can look at the request itself and no just the path 3. Cleanup the double headers on the way out (though they could be completely different, and that will probably just be the wrong answer). Either way, let me know if any of these work for you
```
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: Yes it does seem broken. We are going to take a look. Here are a few interesting alternatives: 1. Fork the pipeline // For more information on how to configure your application, visit http://go.microsoft.com/fwlink/?LinkID=316888 var builder = app.New(); var config = new HttpConfiguration(); builder.UseWebApi(config); var appFunc = (AppFunc)builder.Build(typeof(AppFunc)); app.Map("/token", subApp => { subApp.UseCors(CorsOptions.AllowAll); subApp.Use(new Func<AppFunc, AppFunc>(next => appFunc)); }); app.Use(new Func<AppFunc, AppFunc>(next => appFunc)); 2. Use MapWhen, and pass in a predicate, now you can look at the request itself and no just the path 3. Cleanup the double headers on the way out (though they could be completely different, and that will probably just be the wrong answer). Either way, let me know if any of these work for you