hottowel - ホットタオルは認証とパーソナライゼーションをどのように処理しますか?

Question

私はホット タオルの背後にあるコンセプトがとても気に入っています。何が起こっているのかをよく理解するために、Pluralsight のコースを数回見ました。

ホット タオルの 1 つの側面は、私には理解できません。さまざまなユーザー ロールを要求するアプリケーションにどのように使用できるのでしょうか。認証とパーソナライゼーションのトピックはコースでは扱われておらず、フレームワーク自体を変更してこれを達成する簡単な方法はないようです。

Answer 1

Pluralsight のコースを初めて見たときと同じ質問があり、認証と承認を実行する必要があるアプリケーションの作業を開始しました。

問題はホット タオル テンプレートに固有の問題ではなく、一般的に Web API を使用する場合の問題のようです。ASP.NET の Web API の概要をざっと見てみると、多くの情報が得られます ( http://www.asp.net/web-api/overview/security/authentication-and-authorization-in-aspnet-web-api )。カスタム RoleProvider と ProfileProvider をプラグインすると、Authorize()属性を再利用できるようになります。

REST と Web API を使用する場合、API はステートレスでなければならないため、セッションが存在しないことに注意してください。Session[]変数をアクティブにするための回避策を提供する記事を見つけましたが、使用しないことにしました。オブジェクト キャッシュを使用して同じ結果を得ることができます。

Authorize()属性が適切でない場合は、独自の承認フィルターを作成できます。このSO の質問は、より多くの情報を提供できます (クロス サイト リクエスト フォージェリの防止に焦点を当てていますが、カスタム AuthZ を実行する場合のフィルターの基本構造と使用方法は同じです)。

Javascript コードは攻撃者によってブラウザー側で変更される可能性があるため、アプリケーションの JS で提供される保護に依存するだけでは十分ではなく、Web API レイヤーで保護を提供することが必須です。認証と承認は Web API の保護に要約され、シナリオに適応できる外部向けの Web サービスを保護するために利用できる情報がたくさんあります。