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

Epner

Answer 1

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!

Epner

Answer 2

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.

Hyoscyamine

Nice find... but the list is already empty, and the code output of CORS headers is still dismissed... any clue as to why? (note that when CORS is in web.config everything works) – Epner

I only verified this behavior with web.config CORS headers. If no allowed origin is configured in the portal blade, the headers are kept. If at least one allowed origin is set, the web.config CORS headers are dismissed. It should be the same with your Web Api CORS code though (appBuilder.UseCors(CorsOptions.AllowAll);), that's strange... one of us probably missed something. – Hyoscyamine

Hi guys, I cannot get Azure Cors to work and it sounds like you were able to - please see my question here: #41542417 – Orenorenburg

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.

Aorangi

Answer 4

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

Spherulite

Answer 5

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.

Burletta

In web.config, under <system.webServer> look for <handlers>. If you have the <remove name="OPTIONSVerbHandler" /> you need to delete it so the service can send the options for CORS and it should start working. – Epner

Answer 6

My problem was that I accidentally put http instead of https into Azure AD B2C custom page config blade ... After change to https it works like a charm.

Horaciohorae