部署在Azure Web App/Azure API上时缺少CORS标头

Question

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

我已经添加了必要的代码CORS到Startup.cs,并主持它本地IIS比客户的不同端口上,并确认其修复Cors问题.

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

问:我不知道Azure的某些特定内容吗？为什么OWIN在部署时没有提供此标头,但是它正在使用localhost？我没有在应用程序的Azure刀片设置的属性窗口中看到任何约束.

笔记:

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

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

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

另外,web.config为了支持OPTIONSHTTP请求,我已经注释掉了以下行(否则,它会抛出HTTP错误405)

<system.webServer>
   <handlers>
     <!--<remove name="OPTIONSVerbHandler" />-->
     ...

Answer 1

实际上,Azure网站应该为您管理CORS.我想你错过了一个方便的Azure网站刀片:

如果我们自己的理解是正确的,那么这个Azure中间件的问题是,它允许您配置除允许的起源之外的任何内容.它缺少"允许标头"可管理配置,每URL规则和其他有用的CORS HTTP标头.更糟糕的是:它会在设置自己的每个HTTP响应之前丢弃所有与CORS相关的标头,因此它甚至不能让你处理它没有的内容.

好处是您可以完全禁用此中间件并通过自己的方式管理CORS,您必须*从门户中的CORS设置刀片中删除每个允许的来源(包括).然后,您可以使用web.config或Web Api来更具体地处理它.查看文档:

不要尝试在一个API应用程序中同时使用Web API CORS和App Service CORS.App Service CORS优先,Web API CORS不起作用.例如,如果在App Service中启用一个源域,并在Web API代码中启用所有源域,则Azure API应用程序将仅接受来自您在Azure中指定的域的调用.

另见相关问题:

因此,最终的答案是:如果您的应用程序不需要非常具体的CORS管理,则可以使用Azure App Service CORS.否则,您需要自己处理它并禁用Web应用程序中的所有CORS配置.

Answer 2

最后我采用了更简单的方法 - 删除了所有代码处理CORS并简单地将标头放入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 在 url 末尾没有斜杠！）

允许凭证部分是为了满足 SignalR 的要求，也许没有它也可以。

如果有人找到编码方式不起作用的原因，我想知道！