-1

ログインフォームを使用してユーザーを認証しています。

FormsAuthentication機密性の高いユーザー/ロールのメンバーシップをクライアント側の Cookie または URL 内に保存するため、これは適切です。URL 内は大きなセキュリティ リスクであるため、ここでは触れません。Cookie を使用する FormsAuthenticationと、次のような問題が生じます。a) クライアントが自身の役割を指示する立場にある場合のセキュリティ。b) Cookie に保存されているデータが多すぎる。セキュリティによって得られるものは何もなく、ユーザー データ ストレージのサイズで大きな時間を失っているので、むしろセッションで作業したいと思います。

FormsAuthenticationすべての基本的なログイン フォーム処理機能のようなものを再利用したいと思います。しかし、クライアント側ではなく、おそらくセッションにユーザーデータをサーバー側に保存して、すべてを単一のCookieに詰め込みたいと思います。ある種のセッショントークンに対して認証するだけです。

データベースがなく、ユーザー データのローカル ディスク ストレージが禁止されています。私はサード パーティの認証サービス プロバイダーに依存しており、要件として、このサービスでのおしゃべりを減らす必要があります。したがって、ユーザー情報を一時的に保存するためのセッション。ひどいですが、それは必ずしも私が求めている問題ではありません。また、ビューにユーザー情報を表示するために、AuthorizeAttribute などで後で使用するために、HttpContext.user とおそらく Thread.CurrentPrincipal を設定/使用する必要があります。

そのため、クライアント側のすべてのユーザー データを Cookie にFormsAuthentication保存します。一方、Session はすべてのデータをサーバー側に格納し、単純なクライアント側のトークン Cookie に依存します。ただし、asp.net の起動および認証手順中は、どこでもセッションを使用できません。クライアント側ではなくセッションサーバー側にすべてのデータを格納する同等のフォーム「メンバーシップ」プロバイダーはありますか?

同等のセッションがない場合...

  1. HttpContext.userとThread.CurrentPrincipal をどこで設定して、他の MVC コンポーネントに干渉したり台無しにしたりせずに両方の値を両方の MVC アプリの残りの部分で使用できるようにしますか?
  2. #1 にかかっていますが、そのエントリ ポイントでセッションを利用できますか? そうでない場合、Session に格納されたデータを使用して Principle/Identity オブジェクトを作成できるようにするにはどうすればよいですか?
  3. これはおそらく固有の要件ではありません。これを処理するライブラリは既に利用可能ですか?
4

2 に答える 2

1

セッションは、クライアント側の Cookie にも情報を保存します! (または Cookie がない場合は URL 内)。

クライアントを認証したい場合、クライアントはある種の資格情報を提供する必要があります。通常、クライアントがログオンすると、Cookie 内の暗号化されたトークンが提供されます。クッキーでない場合、何を提案しますか?

FormsAuthentication を使用する必要があります。クライアント側の Cookie に保存されている機密情報は、Web サーバーだけが知っているキーを使用して暗号化されます。「暗号化方法が公開されている」ということは、適切な暗号化キーにアクセスせずにデータを復号化できるという意味ではありません。

「役割」と「サードパーティの認証プロバイダー」について言及しています。サード パーティもロールを提供している場合 (つまり、「承認プロバイダー」と「認証プロバイダー」)、プロバイダーから取得したロールをサーバーにキャッシュすることは合理的です。リクエストが承認されている間はセッションを使用できないため、最善の解決策はキャッシュ (System.Web.Caching.Cache) を使用することです。

個人的には、これをカスタム RoleProviderにカプセル化します。カスタム RoleProvider はGetRolesForUser、最初の呼び出しでサード パーティからロールを取得し、それらを Cache にキャッシュすることによって実装します。

于 2012-11-19T01:19:19.463 に答える
0

私が提案しようとしていることが気に入るかどうかはわかりませんが、次のことを行うことができます。

  • アプリケーションの状態を活用するかSystem.Cache、ユーザー資格情報のグローバル ストレージとして活用します。

  • 暗号化もできるInMemoryデータベース（RavenDbなど）を使用します（メモリ内であると思います）。

    比較的一般的/頻繁なものを保管する場所としてアプリケーション状態を使用することは、私が思うに素晴らしい場所ではありません。

    • スケーリング/ロックの問題? <--ただの直感です。
    • 永久データ？Web サイトのメモリにユーザーがいるとしたら、Web サイトがクラッシュしたり、リサイクルしたりします。そのデータはどうなりますか?
    • RavenDb は素晴らしいボールです - go.use.it.now.

ローカルに何も保存していないことを理解しています。そのため、ユーザーがシステムにアクセスするたびに、メモリ内キャッシュなどを更新する必要があります。お尻の痛みですが、それでも大丈夫です。（編集：データがメモリにキャッシュされていない限り..つまり）

とにかく、2つの提案。

プロのヒント:

おー！役割ベースのシズから離れて、クレーム ベースの IDの使用を開始します。はい、IPrincipal や HttpContext.User などで引き続き動作します。そのため、以前のコードはすべて壊れていません。しかし、今では .NET 4.5 に組み込まれています。

あなた、私、みんなのためのこれに関する素晴らしいビデオ！

最後に - ボーナスの提案

ここに画像の説明を入力

Facebook/Google/Twitter のいずれかで認証される素敵なパッケージ。あなたは、別のサイトでユーザーの資格情報を保持していると言いました (良い動きです!)。他のプロバイダーを使用している場合は、DNOA または SS を使用してください。

ＧＬ！

于 2012-11-19T02:15:03.373 に答える