6

ASP.NET MVC のキャッシュと承認について混乱しており、明確にする必要があります。

自作の認可属性は から継承していAuthorizeAttributeます。コントローラーアクションに属性を設定しても、オーバーライドさAuthorizeCoreれたメソッドは毎回実行されます。[OutputCache]私はその部分を理解しています。

今、私にとってのマインドベンダー：実際に出力キャッシュを行い、ページがキャッシュから提供さAuthorizeCoreれると、毎回失敗します。その理由は、リクエストがキャッシュされるとき、httpContext.Session指定されたAuthorizeCore! null? 簡単なコードを次に示します。

protected override bool AuthorizeCore(HttpContextBase httpContext) {
    return (Session["userId"] != null)
}

httpContext.Sessionである場合null、これは明らかに毎回失敗します。セッションにアクセスする必要がありますが、リクエストが承認されているかどうかを確認するにはどうすればよいですか? これは意味がありません。これが本来あるべき方法である場合、キャッシュされたページを ASP.NET MVC の認証と一緒に使用することはできません。ヘルプ？

4

1 に答える 1

13

2つの別々の質問があります：

  1. 認証はMVCのキャッシュで機能しますか？
  2. セッションは、キャッシュに直面して認証前に機能しますか（認証されていないユーザーでも、うまくいけば一意のセッションがあります）？

答えは、それぞれ「はい」と「いいえ」です。認証はキャッシュで正常に機能します。SQLまたはドメインメンバーシッププロバイダーで試してみてください。わかるでしょ。

ただし、キャッシングは認証モジュールの前に実行できます。（ボーナスポイントの場合：なぜですか？）認証は、（AuthorizeAttributeのように）キャッシュを具体的にフックする場合にのみ呼び出されます。セッションはユーザー固有であるため、AuthorizeCore内でセッションが行われる保証はありません。

その他のボーナスポイント：キャッシュ構成でvaryByUserを指定した場合、これはどのように変化しますか？

残念ながら、あらゆる種類のセキュリティ権を取得することは難しいため、認証権を取得することは困難です。Microsoftは、メンバーシッププロバイダーAPIを使用してこれを簡単にしようとしています。カスタム認証を実装する場合は、これを使用することを強くお勧めします。また、可能な限り書き換えるのではなく、組み込みのプロバイダーを使用して拡張することをお勧めします。

もう1つのポイント：ASP.NETセッションプロバイダーとASP.NETメンバーシッププロバイダーは完全に分離されています。さまざまなメンバーシップユーザーがセッションを共有（！）できます。もちろん、この方法でサイトを攻撃できます。セキュリティ関連の情報をセッションに入れることは決して安全ではありません。セキュリティは難しいです。

于 2009-09-18T01:49:09.010 に答える