ASP.NET MVC における CORS 対応と、基本認証と、プレフライトと

ASP.NET MVC で実装しているとある Web アプリのとあるアクションメソッドにおいて、"CORS (Cross-Origin Resource Sharing)" 対応する必要に迫られた。

CORS 対応とは、平たく言ってしまえば、異なる Web サイト間での "AJAX" 要求 ( XMLHttpRequest オブジェクトによる要求) は、"同一オリジンの原則" というセキュリティ上の措置から既定では阻止されるのが Web ブラウザ実装の仕様なので、これを許可するように仕込むことだ。

今回の案件では、自前の Web アプリへの、よその Web サイト上の JavaScript からの AJAX 要求を受け付けるようにする必要があった。
それで "CORS" 対応、というわけ。
今回の CORS 対応とは、自前の Web アプリの HTTP 応答に、"クロスドメインなアクセス、OKっすよ!" 的意味を表す所定のカスタムヘッダを追加してやることになる。

詳しくは下記など参照されたし。

CORS(Cross-Origin Resource Sharing)について整理してみた
http://dev.classmethod.jp/etc/about-cors/

どうやって実装する?

ASP.NET MVC のアクションメソッドを CORS 対応にする Microsoft 公式実装は存在しない。
NuGet で探すと Microsoft.AspNet.Mvc.Cors というパッケージが見つかるが、これは来る ASP.NET5 用のもので、2015年1月にベータ版として公開されたばかりであり、2015年9月時手ではまだ ASP.NET5 自体がベータ段階である。
今回の要件ではベータ版の採用は不可だったので、この NuGet パッケージを使うわけにはいかない。

WebAPI なら標準サポートがあるけど MVC で頑張ることに

ちなみに、ASP.NET MVC ではなく、ASP.NET WebAPI であれば Microsoft 公式実装の CORS 対応がある。

しかし CORS 対応のためだけに OWIN Startup クラスやらルーティング登録やらコードが膨らむのもうざかったし、責務が近しいのに MVC のコントローラと API のコントローラの2つにコードが分割されてしまうのも気に入らなかった。

ということで、ASP.NET MVC のアクションメソッドを CORS 対応させることで頑張ってみることにした。

EnableCors 属性を自作していたもんね

nuget.org を探せば、いいライブラリがあるかもしれないが、下記のとおり、2014年1月作の自前のコードの作り置きがあったので、これを使ってみることにした。

https://github.com/jsakamoto/tellmewys/blob/master/TellMeWYS/Code/EnableCorsAttribute.cs

上記ソースコードを今回案件のプロジェクトに追加し、ASP.NET MVC アクションメソッドに「EnableCORS(...)」属性を付けてやれば一丁上がりだ。
ほかの Web アプリでの実績もあるし、楽勝である。

[HttpPost, EnableCors(methods: "POST")]

public ActionResult Foo(MyDataType data){

....

}

と思ったのもつかの間、これがどうにもうまく機能せず、泥沼にはまってしまった。

実は Basic 認証つきだったという罠

実はこのアクションメソッド、Basic認証で保護してある。

ということで、このアクションメソッドにデータを POST する JavaScript コードは jQuery を使った場合だと、下記のとおりとなる。

$.ajax({

  method: 'POST',

  url: '本件の対象アクションメソッドへのURL',

  data: {}, // 送信する何かデータ

  username: 'bob',

  passwrd: 'password'

});

ところがこれが、"Invalid Access Error" という JavaScript 側のエラーになるのだ。

Basic 認証と CORS 対応は相性が悪い?

ネットで検索してみたところ、どうやら Basic 認証と CORS アクセスとの両立は簡単ではないようだ。

まずサーバー側の応答内容だが、Allo-Access-Origin 応答ヘッダの値が '*' だとだめらしい。
しかし今回の要件ではアクセス元はどこからであっても問わない '*' 指定とする必要があった。
そこで、要求の Origin ヘッダの値をそのまま Allo-Access-Origin 応答ヘッダ値とするよう、サーバー側コードを組み直した。

さらに、「Access-Control-Allow-Credentials: true」という応答ヘッダも必要とのこと。
このヘッダも付けて応答するよう、サーバー側コードに追加した。

そして次はクライアント側 (JavaScript コード側) である。
こちらは XHR オブジェクトの「withCredentials」プロパティに true を設定しておく必要があるとのこと。

以上の措置を済ませて、Google Chrome で動作確認してみると、ようやく期待どおり動作するようになった。

だがしかし、IE...

と思ったら、IE だとこれが機能しない。
相変わらずクライアント側で "Invalid Access Error" である。

そしてよりによって、今回の案件は IE 対応は必須なのであった。

いろいろ試行錯誤したり stackoverfllow を探し回ったりしたが成果は上がらず。
IE のこの振る舞いは、何かセキュリティ上の判断による仕様なのだろうか。

幸い、今回の案件は「パスワードで認証する程度の保護」が必要というだけで、その実現手段は問わない、すなわち Basic 認証必須ではなかった。
（単に、当初の目論見では、Basic 認証にしておけば簡単にプログラムが仕上がるだろうと考えて、Basic 認証を採用したにすぎないのであった)

そこで代わりに、要求ヘッダにオレオレカスタムヘッダとしてパスワード付けて XHR 送信してもらう仕様に方針転換した。

Basic 認証はやめてオレオレ認証で回避

JavaScript 側コードを下記のとおり変更。
サーバー側では送られてきたカスタムヘッダ値を見て、パスワード照合して処理継続の可否判定をすればよい。

$.ajax({

  method: 'POST',

  url: '本件の対象アクションメソッドへのURL',

  data: {}, // 送信する何かデータ

  {headers:{

    "X-Password":"bar"

  }}

});

ようやくこれでどうにかなる...

と思ったものの、なんとこれでもまだ機能しない。
ただし今度はちょっと状況が変わっており、サーバー側から HTTP 404 Not Found が返ってきている。

何が起きているか一瞬わからなかったが、やがて気が付いた。
忘れてたけど、プレフライト (preflight) だ。

プレフライト...!

すなわち、方針転換により "X-Password" などというカスタムヘッダを要求に追加したせいで、プレフライト発動のフラグを立ててしまったのだ。

プレフライトとは、正味の HTTP 要求の前に送信される「クロスドメインアクセスが可能か確認する」要求である。
いくつかの条件がそろっていると、プレフライト要求は発生しない。
だが、カスタムヘッダが追加された要求の場合はプレフライトが発生するという規約になっているのだ。

そのため、本旨の POST 要求の前に、プレフライトととしての OPTIONS 要求が送られてきており、しかしサーバー側実装には OPTIONS 要求に対応する用意はなかったので、それで HTTP 404 を返していたのだ。

ということで、プレフライトの OPTIONS 要求に応答するためだけに、もうひとつ同名の (但し引数違いによるオーバーロード版の) アクションメソッドを追加実装した。

[HttpOptions, EnableCors(methods: "POST,Options")]

public ActionResult Foo(){

....

}



[HttpPost, EnableCors(methods: "POST,OPTIONS")]

public ActionResult Foo(MyDataType data){

....

}

これでようやく、本当に、IE でも Chrome でも、(自前の認証機構による)パスワード保護付きの CORS アクセスが機能するようになった。

プレフライトに応答するためだけに、同名のメソッドが生えているのが気に食わないが、もう疲れ果てたので、ここまでの実装で改善はあきらめた。

なお、規格上はプレフライトに使う動詞は OPTIONS とは決められていないようなので、これで安定稼働するかどうかは一抹の不安が残ったままである...。

まとめ

Basic 認証と CORS アクセスとの両立でひっかかるとは予想できず、ずいぶんと苦労してしまった。

今回はプログラムの完成を急いだために、上記のとおり紹介した方法で半ば力技的に対処した格好である。
しかし今振り返るともっとましな実装があったのではないかと思ったりもする。
素直に ASP.NET WebAPI で実装しておけばプレフライト対応とか楽だったりするのだろうか（実はよくわかっていない）。

コメント欄や Twitter 上などでツッコミいただければ幸いである。