CORS headers missing when deployed on Azure Web App / Azure API

Question

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:

• Using Owin , WebAPI2 , Ninject , SignalR
• Custom token is issued and provided in headers on each subsequent request, and is verified with a custom filter.
• Cors I'm attempting for now is *

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" />-->
     ...

Answer 1

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.

Answer 2

In the end I went with easier way - removed all code-handling of CORS and simply put the headers in the web.config :

<configuration>
 <system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="Access-Control-Allow-Origin" value="http://my-client-website.azurewebsites.net" />
      <add name="Access-Control-Allow-Methods" value="*" />
      <add name="Access-Control-Allow-Headers" value="accept, content-type, x-my-custom-header" />
      <add name="Access-Control-Allow-Credentials" value="true" />
    </customHeaders>
  </httpProtocol>
 ...

(note that allow-origin doesn't have a slash at the end of the url!)

The allow-credentials part was to satisfy the SignalR, probably it could do without it.

If someone finds a reason as to why the coded way isn't working I'd like to know!

Answer 3

I've run into this issue, too. I think I've finally got programmatic WebAPI's CORS working in an Azure App Service with this magic combination of handler changes:

  <remove name="OPTIONSVerbHandler" />
  <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
  <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,POST,PUT,DELETE,HEAD,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />

You do have to remove the OPTIONSVerbHandler to get rid of the default preflight responses--by using custom headers in the web.config, you just found another way to ensure those headers get written to those OPTIONS requests that never reach your app.

The key is making sure that something else is in charge of OPTIONS requests, and I believe that's achieved by re-adding the ExtensionlessUrlHandler specifying OPTIONS in the verb list. I'm not well versed in IIS, so I'm speculating about the mechanism, but it does seem to work. FWIW, this is with me spinning up WebAPI's CORS functionality in App_Start/WebApiConfig.cs like so:

config.EnableCors(new MyCorsPolicyProvider());

Where MyCorsPolicyProvider is a class that implements ICorsPolicyProvider .

Answer 4

I set this on azure portal, but chrome preflight still fails for cross domain request. In azure document, the preflight uses OPTION http verb, I guess chrome may just use a GET, so there is no header value for that.

Answer 5

我的问题是我不小心将http而不是https放入Azure AD B2C自定义页面配置刀片......更改为https后，它就像一个魅力。

Answer 6

try this command on AZURE cloud shell

Azure cloud shell

az resource update --name web --resource-group ***1*** --namespace Microsoft.Web --resource-type config --parent sites/***2*** --set properties.cors.allowedOrigins="['http://localhost:5000']" --api-version 2015-06-01

****1**** = Your resource group name

****2**** = Your App name