在Azure Web App/Azure API上部署时缺少CORS标头 [英] CORS headers missing when deployed on Azure Web App / Azure API

问题描述

我创建了一个由WebAPI 2托管的OWIN.还有一个Web应用程序(AngularJS)使用API​​并充当客户端.

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.

我已将CORS的必要代码添加到Startup.cs，并将其托管在本地IIS上与客户端不同的端口上，并确认它已解决了Cors问题.

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.

然后，我将两个应用程序都部署到了Azure(我都将它们作为Web应用程序放在了Azure上，并且我还尝试将OWIN放入当前处于预览状态的Azure API中)，但是-预检请求现在失败了(没有响应中出现Access-Control-Allow-Origin.

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).

问::我是否不知道某些特定的Azure?为什么OWIN在部署时不提供此标头，但在localhost上运行呢?我在应用程序的Azure刀片服务器设置的属性窗口中没有看到任何约束.

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.

注意:

关于我正在使用的设置的一些细节:

About some specifics of the setup I'm using:

• 使用Owin，WebAPI2，Ninject，SignalR
• 发出自定义令牌，并在每个后续请求中将其提供在标头中，并使用自定义过滤器进行验证.
我现在尝试的
• Cors是*

• 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 *

Startup.cs的相关部分:

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);
}

此外，为了支持OPTIONS HTTP请求，我从web.config注释掉了以下行(否则，它抛出HTTP错误405)

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

推荐答案

最后，我采用了更简单的方法-删除了CORS的所有代码处理，只需将标头放在web.config:

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

(请注意，allow-origin在网址末尾没有斜杠！)

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

allow-credentials部分是为了满足SignalR，如果没有它，可能可以做到.

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!

这篇关于在Azure Web App/Azure API上部署时缺少CORS标头的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！