CORS EnableCorsAttribute parameters to accept all like previous nightlies?

Topics: ASP.NET MVC, ASP.NET Web API, General
Apr 26, 2013 at 9:25 PM
Now that it is required to pass the origin, headers and methods, how does one specify that you want to allow all origins, all headers and all methods?

Thanks!
Apr 26, 2013 at 9:38 PM
Edited Apr 26, 2013 at 9:38 PM
You can use "*" to allow all origins/headers/methods.
[EnableCors("*", "*", "*")]
Thanks,
Yao
Apr 28, 2013 at 11:08 PM
Thanks!

Wouldn't it be a good idea to have a parameterless constructor that did the same? Kind of redundant that way...
Apr 29, 2013 at 4:42 PM
Yes. In fact it was like that originally but after further security review, we've decided to make these settings explicit to prevent unintentional overexposure of your APIs across origins.

Thanks,
Yao
May 7, 2013 at 5:04 PM
Hi Yao,

I just upgraded to the latest nightly and bumped into the following problem.

I use the attribute as you suggest above, but with credentials support as I'm using WIF with Azure ACS.
[EnableCors("*", "*", "*", SupportsCredentials = true)]
And I get the following error on the browser:
Cannot use wildcard in Access-Control-Allow-Origin when credentials flag is true.

Any suggestions?

Thanks,

Bruno
May 7, 2013 at 5:23 PM
Update:

After digging a little more, I get this behavior when doing the following:
[HttpOptions("{id}/feed")]
[EnableCors("*", "*", "*", SupportsCredentials = true)]
public HttpResponseMessage OptionsFeed(string id)

[HttpGet("{id}/feed")]
[EnableCors("*", "*", "*", SupportsCredentials = true)]
public async Task<HttpResponseMessage> GetFeed(string id)
I tried this approach to avoid processing the whole request when the http method is OPTIONS.

I can make it work like this:
[HttpGet("{id}/feed")]
[HttpOptions("{id}/feed")]
[EnableCors("*", "*", "*", SupportsCredentials = true)]
public async Task<HttpResponseMessage> GetFeed(string id)
I think this might be related to the "OPTIONS" with attribute routing subject.

Any advice?
May 7, 2013 at 5:54 PM
Hi Bruno,
Yeah, normally I wouldn't expect something like "Cannot use wildcard in Access-Control-Allow-Origin when credentials flag is true" because there's a logic that checks when the SupportsCredentials is true, to echo back the request's origin instead of sending back the wildcard. Are you sending the GET request with custom headers? Does it fail when you send the GET request or the OPTIONS request? Can you provide me with a simple repro?
Thanks,
Yao
May 8, 2013 at 1:51 PM
Edited May 8, 2013 at 1:52 PM
Hi Yao,

You have the repro here.

I investigated a little bit more and got to the following facts.

If I set the attribute on the configuration and then set specific attributes on the controller methods that must support credentials
public static void Register(HttpConfiguration config)
{
    config.EnableCors(new EnableCorsAttribute("*", "*", "*"));
    config.MapHttpAttributeRoutes();
}

[HttpOptions("{id}/feed")]
[EnableCors("*", "*", "*", SupportsCredentials = true)]
public async Task<HttpResponseMessage> OptionsFeed(string id)
{
    ...
}

[HttpGet("{id}/feed")]
//[HttpOptions("{id}/feed")]
[EnableCors("*", "*", "*", SupportsCredentials = true)]
public async Task<HttpResponseMessage> GetFeed(string id)
{
    ...
}
I get the following error:
XMLHttpRequest cannot load http://localhost:57234/api/values/123/feed?_=1368020548758. Cannot use wildcard in Access-Control-Allow-Origin when credentials flag is true.
If I don't set the attribute in the configuration
    config.EnableCors();
I get these errors on the browser console:
OPTIONS http://localhost:57234/api/values/123/feed?_=1368020051027 405 (Method Not Allowed)
XMLHttpRequest cannot load http://localhost:57234/api/values/123/feed?_=1368020051027. Origin http://localhost:41580 is not allowed by Access-Control-Allow-Origin. 
Hope it's enough info. :)

Thanks,

Bruno
May 15, 2013 at 12:06 AM
Hi Bruno,
Thanks for the repro. This does look like a bug and I've opened issue #1050 to track.

Yao
May 15, 2013 at 9:21 AM
Hi Yao,

Thanks!

Bruno
Nov 13, 2013 at 1:07 AM
Edited Nov 13, 2013 at 1:08 AM
Hi Yao

I am running into the same issue and I can't figure it out. What I am trying to do is register a user account and then log in. The setup....
  1. One solution containing an AngularJS single page app.
  2. Another solution containing only Web Api 2.
  3. I can successfully login (set up some accounts via Fiddler).
  4. Registering an account results in "Origin is not allowed by Access-Control-Allow-Origin. Strange that log in works but not registration.
  5. I do have Microsoft.AspNet.WebApi.Cors and Microsoft.Owin.Cors packages installed in the Web Api solution.
  6. Visual Studio 2013
The preflight OPTIONS request returns 200. On the POST, I am not getting any response headers. Here is the Request Header
Request URL:http://localhost:60615/api/Account/Register
Request Headersview source
Accept:application/json, text/plain, */*
Access-Control-Allow-Headers:Accept, Content-Type
Access-Control-Allow-Methods:OPTIONS, POST
Access-Control-Allow-Origin:http://localhost:50493/
Cache-Control:no-cache
Content-Type:application/json;charset=UTF-8
Origin:http://localhost:50493
Pragma:no-cache
Referer:http://localhost:50493/
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36
Request Payloadview source
{userName:crisis130, password:Password01, confirmPassword:Password01}
confirmPassword: "Password01"
password: "Password01"
userName: "crisis130"
This is the strangest part. Even though Chrome shows that the POST was canceled, I can see the user I attempted to create in my local database. If you want to take a look things, here is a zip with the two solutions:

https://www.dropbox.com/s/yg7qdowd58la0db/CorsProblem.zip

Any help would be so very much appreciated. Have burned so many hours on this. By the way, there is some commented out code because I have been trying whatever I can to get things to work.
Nov 13, 2013 at 6:42 PM
Hi AvocadoRacher,

My name's Troy from Web API team. I haven't start investigating your sample, we will get there. However after glance at you request sample, I wondering why are follow three headers added to the request?

Access-Control-Allow-Headers:Accept, Content-Type
Access-Control-Allow-Methods:OPTIONS, POST
Access-Control-Allow-Origin:http://localhost:50493/ They're CORS response header (http://www.w3.org/TR/cors/#access-control-allow-origin-response-header). To request access of resource of a specific method you should instead use Access-Control-Request-Method. If your request contains customized header you should also use Access-Control-Request-Headers to gain access.

Regards,
Troy
Feb 13, 2014 at 7:31 PM
Hi Yao,

I am getting 302 status code (redirect to ACS ) during my preflight request to web api. I have configured allow users="?" in the web.config. THE preflight request will not send the authorization token, it gets redirected to ACS hence 302 status code.

what is the solution to over come the 302 redirect issue?
Coordinator
Feb 17, 2014 at 6:12 PM
Can modify your app to do authorization at the Web API layer using authorization filters (i.e. [Authorize]) instead of doing a blanket authorization check?