0

ASP.NET MVCで、同じアカウントによる以前のログインセッションを「キック」するための新しいログインを許可したいと思います。

各ブラウザにセッションIDを表す料理を提供することはかなり明らかなようです。サーバー側のキャッシュで現在アクティブなセッションIDを追跡します。すでにアクティブなユーザーがログインしようとした場合は、ビジネスロジック（ユーザー名、パスワード、最後のアクティビティから15分以上経過している）を確認してから、サーバーにキャッシュされているアクティブなセッションIDを更新します。

今私の問題は、ブラウザが無効なセッションIDを保持していることです。このシナリオで拒否を挿入したり、サインインにリダイレクトしたりするのに最適なポイントは何ですか？

AuthorizeAttributeを変更することはできますが、Global.asaxイベントやコントローラーイベント（I '私のプロジェクトではすでにControllerを拡張しています）。

たとえば、PreAuthorizeが存在する場合は、有効なユーザー/セッションIDペアについてリクエストのCookieをテストするためのコードをそこに記述し、存在しない場合は、リクエストから認証Cookieを削除するだけで済みます。標準の不正なリダイレクト。

4

1 に答える 1

0

したがって、少し調べてみると、通常、カスタムのAuthorizeAttributeが正しいアプローチであるように思われます。ただし、私の場合は、カスタムロールプロバイダーがすでに実装されているため、そこで実行するのは1行のコードにすぎませんでした。これは、単一の役割に対してセッションの同時実行性のみが必要だったため、私にもメリットがありました。副作用として、ロールごとに静的ファイルへのアクセスを制御するためにweb.configを使用すると、セッションの同時実行性にも影響します。

于 2012-07-26T09:11:27.913 に答える