ここでも同様の質問に回答していますが、私の場合は回答がうまくいかないようです。
JWT認証を使用しているWebApiで認証/承認プロセスをテストしたいと思います。
私の認証はMessageHandler、私が自分に追加したカスタムを通じて処理されますHttpConfiguration。[Authorize]アクセスを制限したいコントローラー/メソッドの単純な属性によって処理される承認。
認証中にトークンから抽出したプリンシパルを次のように設定しています（カスタムでMessageHandler）：
Thread.CurrentPrincipal = principal;
if (HttpContext.Current != null)
{
HttpContext.Current.User = principal;
}
ローカルIISで手動でテストすると、このプロセス全体が正常に機能しています。
しかし、ここのようなインメモリホスティングでテストする場合ApiController.User認証に使用されるプリンシパルを格納するプロパティは、認証中に設定されたものではなく、呼び出しテスト（現在のセッションのWindowsプリンシパル）で[Authorize]取得しThread.CurrentPrincipalます。Thread.CurrentPrincipalnullに設定すると、悪いリクエストしか受け取れません。
TL; DRメモリ内ホスティングで認証/承認パイプラインをテストするにはどうすればよいですか？ApiController.User値をThread.CurrentPrincipalテストの値に設定し、認証中に正常に設定した値を取得できないためです。
ではなくを[Authorize]取得するカスタム属性を実装することで回避できると思いますが、それは避けたいと思います。Thread.CurrentPrincipalApiController.User
前もって感謝します。
明確にするための編集：このすべてのパイプライン（認証、承認）は、実行中のIISで正常にホストされています（メモリ内ホスティング中はHttpContextがnullです）。私はメモリホスティングでそれをテストしようとしています（可能であれば）。インメモリホスティングでテストしている間、カスタムにブレークポイントを設定するMessageHandlerと、Thread.CurrentPrincipalが適切に設定さ[Authorize]れていることがわかりApiController.Userます。ApiControllersではプロパティがすでに私のThread.CurrentPrincipal値の値に設定されているため、それは気にしないようです。私のテスト（私のローカルWindowsセッションプリンシパル）
「ASP.NETを使用した進化可能なWebAPIの設計」の第15章の「現在のプリンシパルの取得と割り当て」セクションにリストされているガイダンスに従って成功しました。
ASP.NET Web APIバージョン2.0では、新しいHttpRequestContextクラスを使用してこの問題を解決できます。まず、現在のIDを取得して、静的プロパティではなく、現在のリクエストオブジェクトに割り当てる必要があります。次に、異なるホストが異なるHttpRequestContext実装を使用できます
つまり、メッセージハンドラーで、現在のスレッドとHttpContextのプリンシパルを設定する代わりに、次のようにします。
request.GetRequestContext().Principal = principal;
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加