問題タブ [authorize-attribute]

Windows AzureMicrosoft.Web.DistributedCache.DistributedCacheOutputCacheProviderを MVC3 アプリの outputCache プロバイダーとして使用する。関連するアクション メソッドは次のとおりです。

このビューを Web ブラウザーからロードすると、次の例外が発生します。

[Authorize] 属性を削除すると、期待どおりにビューがキャッシュされます。これは、[Authorize] が必要なアクション メソッドに [OutputCache] を配置できないということですか? または、キャッシュの静的検証コールバック メソッドを使用するカスタム実装で AuthorizeAttribute をオーバーライドする必要がありますか?

更新 1

Evan の回答の後、IIS Express (Azure の外部) で上記のアクション メソッドをテストしました。OutputCache 属性の VaryByCustom = "User" プロパティのオーバーライドは次のとおりです。

サンプルのキャッシュ ページに me@mydomain.tld としてアクセスすると、ページの出力がキャッシュされ、ビューに「このページは 2011 年 12 月 31 日 11:06: 12 AM (UTC) にキャッシュされました」と表示されます。その後、サインアウトして another@otherdomain.tld としてサインインし、ページにアクセスすると、「このページは 2011 年 12 月 31 日 11:06: 38 AM (UTC) にキャッシュされました」と表示されます。me@mydomain.tld として再度サインインしてページに再度アクセスすると、キャッシュに「このページは 2011 年 12 月 31 日 11:06: 12 AM (UTC) にキャッシュされました」と再度表示されます。さらにサインイン/サインアウトを試みると、ユーザーに応じて異なる出力がキャッシュされて返されることが示されます。

これにより、出力がユーザーに基づいて個別にキャッシュされていると思われます。これは、VaryByCustom = "User" 設定とオーバーライドの意図です。問題は、Azure の分散キャッシュ プロバイダーでは機能しないことです。Evan さん、公開コンテンツのキャッシュのみが残っていることについてお答えいただけますか?

更新 2

ソースを掘り下げたところ、既製の AuthorizeAttribute には実際には非静的検証コールバックがあることがわかりました。からの抜粋は次のOnAuthorizationとおりです。

CacheValidationHandlerもちろんprotected virtual HttpValidationStatus OnCacheAuthorization(HttpContextBase)、これは静的ではありません。静的ではない理由の 1 つは、上記の IMPORTANT コメントで述べたように、 を呼び出すためprotected virtual bool AuthorizeCore(HttpContextBase)です。

静的キャッシュ検証コールバック メソッドから AuthorizeCore ロジックを実行するには、AuthorizeAttribute インスタンスの Users プロパティと Roles プロパティを知る必要があります。ただし、プラグインする簡単な方法はないようです。OnAuthorization をオーバーライドして、これら 2 つの値を HttpContext (Items コレクション?) に入れ、OnCacheAuthorization をオーバーライドしてそれらを元に戻す必要があります。しかし、それは汚いにおいがします。

OutputCache 属性で VaryByCustom = "User" プロパティを慎重に使用する場合、OnCacheAuthorization をオーバーライドして、常に HttpValidationStatus.Valid を返すことはできますか? アクション メソッドに OutputCache 属性がない場合、このコールバックが呼び出されることを心配する必要はありませんよね? また、VaryByCustom = "User" のない OutputCache 属性がある場合、どのユーザー要求がキャッシュされたコピーを作成したかに関係なく、ページがキャッシュされたバージョンを返す可能性があることは明らかです。これはどれほど危険ですか？

私が尋ねる理由は、もともとカスタムに次のコードがあったからですAuthorizeAttribute。

私は基本的に、このコードを StackOverflow の回答から少し前に貼り付けました。その後、このロジックをIAuthorizationFilter.

問題は、インターフェイスに切り替えることで、AuthorizeAttributeの の実装が失われたことですOnCacheAuthorization。ドキュメントによると、OnCacheAuthorization「キャッシュモジュールが承認を要求したときに呼び出されます」。これでは、このメソッドを実装するために何をする必要があるか、そもそもコールバックが必要かどうかさえわかりません。

質問

1. PreventPageFromBeingCached2行のコードだけで実際にページがキャッシュされないようにしますか、それとも と メソッド (および の実装) も含める必要がありcachePolicy.AddValidationCallback(CacheValidateHandler, null);ますCacheValidateHandler()かOnCacheAuthorization()?
2. 追加のコードが必要な場合、正確には何をしますか?
3. すべてが間違っている場合、ページがキャッシュされないようにするにはどうすればよいですか?

ユーザーを承認したいのですが、承認された場合は、ユーザーの役割と権限をユーザーに追加し、それをIPrincipleに追加します。

これを行うには2つの方法があります。1つはglobal.asaxApplication_AuthenticateRequestで行うことで、もう1つはAuthorizeAttributeから継承する属性を作成することです。

ここにキラリと光る良い選択はありますか？

ASP.NetMVCサイトがあるとします。HTTP_REFERERが自分のサイトを指すように、コントローラーメソッド（おそらくアクションの属性を使用）をロックするにはどうすればよいですか？

拡大するために：

コントローラーには、Cookieが設定されていない*ユーザーが入るのを防ぐために[承認]とマークされた多くのJSONアクションがあります。

卑劣な誰かが攻撃者のWebページを作成し、それを私のサイトにログインしているユーザーに電子メールで送信します。そのページには、JSONコントローラーアクションからフェッチするスクリプトが含まれています。これにより、ユーザーのブラウザはログインしたCookieを許可されたコントローラメソッドに送信し、そのユーザーのデータを攻撃者のWebページに戻し、攻撃者はそれを読み取って他の場所に渡すことができます。

HTTP_REFERERが自分のサイトを指すようにこれらのリクエストをロックできれば、JSONをリクエストするためのクロスサイト攻撃は防止されます。最も簡単な方法は何ですか？

明らかに、JSON、承認済み、またはすべてのリクエストをロックしたくないことに注意してください。ユーザーは引き続きサイトにリンクできる必要があります。ただし、承認されたJSONリクエストには、当サイトのページ以外からアクセスすることはできません。

*はい、私はこの言葉を作りました。

私は少し壁にぶつかり、誰かが私が間違っているところを指摘してくれることを望んでいました。

Ninjectを使用してカスタムActionFilterAttributesに注入してきましたが、これは正常に機能しています。

現在、カスタムのAuthorizeAttributeに挿入しようとしています。構文が正しいので、Role属性とカスタム属性を挿入します。

属性は正しく実行されており、ロールと年は正常に挿入されています。私の問題は、注入しようとしているサービスが常にnullであるということです。

通常のActionFilterAttributesでは、サービスは正常に注入されますが、ここではそうではありません。

どんな助けでもいただければ幸いです

カスタム AuthorizeAttibute (グローバルに登録) 内で、コントローラーのタイプと呼び出されるアクションに基づいて承認を適用する際に、セキュリティ上の問題や落とし穴の可能性はありますか?

例 (実際のコードではない)

Asp.Netの多くのことは、想定される知識に基づいていることがわかりました。たとえば、私はインターネット認証についてあまり知らず、初心者レベルでそれについて何かを見つけるのに苦労しています。

私を困惑させているのは、AuthorizeAttributeです。私はそれを使用する方法とそれが何をすべきかを理解していますが、あなたがカスタムログインシステムを持っている状況でそれが機能するかどうか疑問に思っています。

AuthorizeAttributeページの説明では、単純に When you mark an action method with AuthorizeAttribute, access to that action method is restricted to users who are both authenticated and authorized.

では、認証されたユーザーとは、どのようにして1人のユーザーを認証されるように設定するのでしょうか。独自のログインシステムを作成する場合、ログインしたユーザーがAuthorizeAttributeで十分に認証され、エントリを許可するように設定するにはどうすればよいですか？

現在、データベースからアクセス許可を取得できるように、[Authorize] フィルターの拡張に取り組んでいます。すべてが機能しますが、パフォーマンスの問題は確かです。データベースにクエリを送信して許可を求めるたびに、これを決定する最良の方法ではありません。そこで、これらのデータをセッションに入れることを考えました。データベースからのデータを、データベースだけでなく、私が尋ねることができるセッションオブジェクト（LINQ）に入れる最速の方法は何ですか。

これは次のようになります。

しかし、私はに変更したい

MySuperSessionSomethink は、データベースから一度だけ取得したデータを保持します。どうすればこれを行うことができますか？助けを求める送信。

より大きな画像

Ok。より大きな画像を表示します。全体のアイデアは、カスタム承認フィルターを作成することです。

これの目標は何ですか。すべての利点に加えて、権限に関する情報をデータベースに保持するなどの追加機能を持つ承認属性を作成します。

今私がしていることは次のとおりです。

この後、私は使用します

しかし、問題があります。データベースにアクセス許可について尋ねるたびに、この私見は最善の方法ではありません。今、私の考えは、1人のユーザーのすべての権限を取得し、承認されたときに彼をセッションに入れることです。たぶん私は間違っていて、この方法では問題が発生しますが、データベースに保管して、常にアクセス許可について尋ねるのも良い考えではありません:)。では、データベースに 1 つか 2 つの質問をしただけで、データを取得してコードで使用する方がよいのではないでしょうか?

私のサイトは誰でも利用できますが、ユーザーとパスワードを持つマネージャーのみが入力できるメソッドを備えたコントローラーがあります。ブール値を に保存IsManagerしていsessionます。
authorize 属性を使用して、誰でもブロックしたいと思いますIsManager == false。

各承認タイプにそれぞれ使用されるコントローラーのセットがあります。たとえば、クラス A の承認には、それぞれがクラス A の承認を必要とする一連のコントローラーがあります。[Authorize(Role="Class A")]各コントローラーを同じ属性で装飾することなく、これらのコントローラーのそれぞれに適用される1 つの属性をどこかに配置する方法はありますか?