Azure Web App/Azure APIにデプロイするとCORSヘッダーが見つからない

Question

OWINがホストされたWebAPI 2を作成しました。 APIを使用してクライアントとして機能するウェブアプリ（AngularJS）もあります。

にCORSの必要なコードを追加し、クライアントとは異なるポートでローカルIISにホストし、Cors問題を修正したことを確認しました。

私は両方のアプリケーションをAzureに配備しました（私はWebアプリケーションとしてAzureに両方を配置しましたが、現在はプレビューされているAzure APIにOWINを入れてみました）。応答にはAccess-Control-Allow-Originが存在しません）。

Q：私は知らないいくつかの具体的なアズールはありますか？どのようにOWINは配備時にこのヘッダーを提供していませんが、localhostで動作していますか？私はアプリのAzureブレード設定のプロパティウィンドウに何らの制約も見ません。

注：私が使用しているセットアップのいくつかの詳細について

：

• Owin、WebAPI2、Ninjectを使用して、SignalR
• カスタムトークンは、後続の各リクエストのヘッダに発行され、提供されカスタムフィルタで確認されます。また、私がサポートするために、web.configから次の行をコメントアウトしまし

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

  ：私は今のところしようとしています

• CORSは*

Startup.csの関連する部分であります私が行ったOPTIONS HTTPリクエスト（そうでない場合、それはHTTPエラー405を投げていた）最後に

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

Answer 1

もっと簡単な方法で - 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> 
... 

（許可-起源は、URLの末尾にスラッシュを持っていませんのでご注意！）

許可証の部分はSignalRを満たしていました。

誰かが、コード化された方法が機能していない理由を知っていたら、私は知りたいです！

Answer 2

実際、AzureウェブサイトはあなたのためにCORSを管理することになっています。私はあなたが便利AzureのWebサイトの刃を逃したと思う：私たち自身の理解が正しければ

は、このAzureのミドルウェアとの問題は、それはあなたが何もなく、許可の起源を設定しないことを可能にするである

。 「許可されたヘッダー」の管理可能な構成、URL単位の規則、およびその他の有用なCORS HTTPヘッダーが欠けています。さらに悪いことに、CORSに関連するすべてのヘッダーは、それが処理するすべての単一のHTTP応答から削除されます。そのため、独自のヘッダーは処理されません。

このミドルウェアを完全に無効にし、独自の手段でCORSを管理できることは、許可されたすべての起点（*を含む）をポータルのCORS設定ブレードから削除するだけです。次に、web.configまたはWeb APIを使用して、より具体的に処理することができます。 the documentationを参照してください：

1つのAPIアプリでWeb APIのCORSとアプリケーションサービスCORSの両方を使用しないでください。 App Service CORSが優先され、Web API CORSは無効になります。たとえば、App Serviceで1つのオリジンドメインを有効にし、Web APIコード内のすべてのオリジンドメインを有効にすると、Azure APIアプリはAzureで指定したドメインからの呼び出しのみを受け入れます。

がthis related issue参照：

だから、最終的な答えは次のとおりです。アプリケーションは非常に具体的なCORS管理を必要としない場合は、AzureのアプリケーションサービスCORSを使用することができます。それ以外の場合は、自分で処理して、WebアプリケーションのすべてのCORS設定を無効にする必要があります。

Answer 3

私はこれを紺碧のポータルに設定しましたが、クロームプリフライトはまだクロスドメイン要求に失敗しています。紺碧のドキュメントでは、プリフライトでOPTION http動詞が使用されています。クロムはGETだけを使用している可能性があるので、ヘッダー値はありません。

Answer 4

私もこの問題に遭遇しました。あなたはがデフォルトプリフライトresponses--を取り除くためにOPTIONSVerbHandlerを削除しなければならないの

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

：私は私が最終的にハンドラの変更のこの魔法の組み合わせでのAzureアプリケーションサービスで働いて、プログラムWebAPIののCORSを持っていると思いますweb.configでカスタムヘッダーを使用することで、ヘッダーがアプリケーションに届かないOPTIONS要求に確実に書き込まれるようにする別の方法が見つかりました。

キーは、OPTIONSリクエストを他のものが担当していることを確認しています。これは、動詞リストにOPTIONSを指定してExtensionlessUrlHandlerを再追加することによって実現されたと思います。私はIISに精通していないので、私はそのメカニズムについて推測していますが、うまくいくようです。 FWIWは、これは私がそうのようなApp_Start/WebApiConfig.csにWebAPIののCORS機能をスピンアップである：

MyCorsPolicyProviderはICorsPolicyProviderを実装するクラスである

config.EnableCors(new MyCorsPolicyProvider()); 

。