I have created an OWIN hosted WebAPI 2
. There's also a web app (AngularJS
) that's using the API and acting as a client.
I've added the necessary code for the CORS
to the Startup.cs
, and hosted it in local IIS on a port different than the client and confirmed that it fixes the Cors
issue.
Then, I deployed both apps to Azure (I've put both on the Azure as Web App, and I also tried putting the OWIN to the Azure API that is currently in preview) but - the preflight request now fails (no Access-Control-Allow-Origin
present in the response).
Q: Is there some specific of Azure I'm not aware of? How come that OWIN isn't serving this header when deployed but it's working on localhost? I don't see any constraints in the properties window on Azure blades settings for the apps.
Notes:
About some specifics of the setup I'm using:
Owin
, WebAPI2
, Ninject
, SignalR
*
The relevant part of Startup.cs:
public void Configuration(IAppBuilder appBuilder)
{
appBuilder.UseCors(CorsOptions.AllowAll);
HttpConfiguration config = new HttpConfiguration();
config.Formatters.JsonFormatter.SerializerSettings.ReferenceLoopHandling = ReferenceLoopHandling.Ignore;
//bind IClientsNotifier with method returning singleton instance of hub
var ninjectKernel = NinjectWebCommon.GetKernel();
ninjectKernel.Bind<MySignalRHub>().ToSelf().InSingletonScope();
ninjectKernel.Bind<QueryStringBearerAuthorizeAttribute>().ToSelf();
GlobalHost.DependencyResolver = new NinjectSignalRDependencyResolver(ninjectKernel);
appBuilder.Map(
"/signalr", map =>
{
map.UseCors(CorsOptions.AllowAll);
var hubConfiguration = new HubConfiguration();
map.RunSignalR(hubConfiguration);
});
config.MapHttpAttributeRoutes();
config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional }
);
config.Formatters.Remove(config.Formatters.XmlFormatter);
config.Filters.Add(new NoCacheHeaderFilter()); //the IE9 fix for cache
var resolver = new NinjectDependencyResolver(NinjectWebCommon.GetKernel());
config.Filters.Add((System.Web.Http.Filters.IFilter)resolver.GetService(typeof(WebApiAuthenticationFilter)));
appBuilder.UseNinjectMiddleware(NinjectWebCommon.GetKernel);
appBuilder.UseNinjectWebApi(config);
}
Additionally, I've commented out the following line from the web.config
in order to support the OPTIONS
HTTP request (otherwise, it was throwing HTTP error 405)
<system.webServer>
<handlers>
<!--<remove name="OPTIONSVerbHandler" />-->
...
Actually, Azure website is supposed to manage CORS for you. I think you missed a handy Azure website blade:
If our own understanding is correct, the problem with this Azure middleware is that is allows you to configure nothing but allowed origins. It lacks an "allowed headers" manageable configuration, per-URL rules, and other useful CORS HTTP headers. Worse: it drops all CORS related headers from every single HTTP response it processes, before setting its own, so it doesn't even let you handle what it doesn't.
The good thing is that you can completely disable this middleware and manage CORS by your own means, you juste have to remove every single allowed origin (including *
) from the CORS settings blade in the portal. Then you can use web.config or Web Api to handle it more specifically. See the documentation:
Don't try to use both Web API CORS and App Service CORS in one API app. App Service CORS will take precedence and Web API CORS will have no effect. For example, if you enable one origin domain in App Service, and enable all origin domains in your Web API code, your Azure API app will only accept calls from the domain you specified in Azure.
See also this related issue:
So the final answer is: If your application does not need a very specific CORS management, you can use Azure App Service CORS. Otherwise you will need to handle it yourself and disable all CORS configuration in the web app.