ActionFilter内でAdalExceptionをテストする必要がありますか？

Question

GitHubのいくつかのAzureサンプルでは、​​ADALを使用して保護されたWeb APIリソースにアクセスする例があります。努力は私がようように、コードをまとめますAdalException

探しのtry/catchにより保護されています

try 
{ 
    //pseudo code... configure a client to use an access token.. 
    var token = ADAL.AcquireTokenAsync... 
    var httpClient = new HttpClient(baseUri, token); 

    // use the token for querying some protected API 
    var result = //await HttpClient to return data... 

    return View(result); 
} 
catch (AdalException) 
{ 
    // do something important with the exception, 
    // e.g. return an error View w/login link 
} 

だから、私は「ADAL-access_tokenは使用するように私のMVCコントローラを肉付けし始めとして、私は本当にこのすべてのコントローラでtry/catchビジネスをしたいのですか？

ActionFilterを作成することは意味がありますか？このスニペットは、コードに触発された私はthis Azure Sampleで見た

​​

マイコンテキスト：私は、彼らが生成された時点でEntityFrameworkを中心とした足場MVCコントローラのではなく、均質なセットを取っている ..しかし、今私の新しいAutoRestクライアントを介してWeb APIにアクセスするために再度ツールを使う必要があります

Answer 1

@vibronetは良い点を作った - あなたのWebAPIエンドポイントのためにそれを行います。ベアラ認証で呼び出され、自動的にサインインプロセスにリダイレクトされるべきではありません。資格情報が無効であることを示す401を戻し、それを放置します。

しかし、MVCアプリケーションの場合、ユーザーは対話的に使用していますが、いくつかの制約がありますが、これは妥当な考え方です。

1. フィルタは、一致するものについて非常にタイトであることを確認してください。つまりの例外を処理できることを確認してください（アクセス拒否の問題と比較して）認証の問題に合理的に確実に当てはめることができます。おそらくラッピングロジックによって投げられるカスタム例外、またはそれを超えたいくつかの余分な条件がADALExceptionであり、再度ログインすることで問題が解決できるかどうかを確認します。
2. リクエストごとにこの処理が必要な場合を除き、コントローラーまたはアクションレイヤーでグローバルにではなく添付してください。
3. エラーが発生する可能性のある「ループ」問題を見つけ、再度ログインするようにユーザーに指示したり、エラーを取得したり、再度ログインさせたりします。ログインをトリガーするときに、またはログインプロセスで、またはそのようなものです。ユーザーのブラウザを無限リダイレクトループに陥らせるよりも、エラーメッセージを表示する方が良いでしょう。 （もちろん、これは手動で処理する例外の場合にも当てはまります）

希望するものがあります。

Answer 2

このアプローチには2つの問題があります。

1. あなたが言及するサンプルコードとフィルタ実装は、Web APIではなくWebアプリケーション用です。それは重要な違いです。 Web APPは、認証のためにユーザと対話するためにブラウザに依存することができます。 Web APIは、クライアントがどのUXを持っているかを知ることができません（つまり、UXがあっても）。したがって、エラーの動作は根本的に異なります。
2. コントローラは複数のAPIを呼び出す可能性があります。独立して成功し、異なるプロバイダーに接続します。コントローラによって、異なるリソースが呼び出されることがあります。エラーに対する反応は異なる場合があります。プロトタイピングされたフィルタのようなフィルタは、非常に狭いケースの場合にのみ役立ちます。 したがって、コントローラがすべて同質のロジックを実行することが期待されない限り、上記のようなフィルタは必要な柔軟性を提供しません。