1

アプリケーションを MVC に移植する際のユーザー ログオンの処理について質問があります。

  • 「古い」WebForm の時代には、開発者は単純に SessionState オブジェクトを使用してユーザーをログオン状態に設定しました。たとえば、ユーザー オブジェクトを SessionState に入れるだけでした (そして、このユーザー オブジェクトは、name/lastlogon/などの単純なプロパティを保持します)。

  • これは私たちにとって非常にうまく機能し、多くのアプリケーションがそのように機能しているのを見てきました

  • はい、このMembershipProvide-thingyがあることは知っていますが、使用したことはありません

さて、MVC では、「これに SessionStat を使用するのはよくない」、「そのように作成されたアプリは設計に欠陥がある」、「セキュリティ リスクが山ほどある」などと誰もが言います。

私がこの方法を使用したのは、非常に信頼性の高いアプリで機能し、実装が簡単で、必要なものすべてをカバーしていたからです。

(確かに、Web ワーカー プロセスをリサイクルしてセッションを空にすることはありますが、アプリは専用のマシンで国ごとに実行されるため、私たちの場合は問題ありません)

私はチュートリアルを読んで、DBにそのようなものを入れるように言って、-注意- DBにリクエストを行って、各リクエストごとにユーザーがログインしているかどうかを確認しましたか? しかし：DBリクエストを最小限に抑えたいので、これは実行可能な方法ではありません。

だから私の質問は：

A) 新しい MVC アプリでもこの方法を使用すると何が問題になりますか?

B) 新しく構築された MVC アプリでこのシナリオを処理する最良の方法は何ですか?

DB内のセッションのアイデアについて：これを行う代わりに、ネットワーク経由でクエリを取得する「セッションマネージャー」のような追加のサービスを評価者に設定しますが、そのような単純なリクエストはDBに送信されるべきではありません-そうではありませんいい考えじゃない？

任意のアイデア、ヒント /etc. このシナリオは私を本当に混乱させているので、高く評価されています:-X

4

1 に答える 1

2

A)

asp.net mvc フレームワークの基本原則は、そのステートレスです。データは http リクエストを使用して渡され、viewmodel のビューに送信されます。Web フォームは、ビューステートなどで状態を維持しようとしました。これが、セッション アプローチでログインしているユーザーを見た理由です。セッションがasp.net mvcで完全に使用されるべきではないと言っているわけではありません.セッションが役立つ状況がいくつかあります. 最後のステップで永続化する必要がある 3 ステップのフォーム プロセスを維持するようなものです。しかし、一般的には、ユーザーのログインを処理するための推奨される方法が既にあり、それがフォーム認証です。

B)

ユーザー オブジェクトにアクセスするために、IPrincipal インターフェイスを実装するカスタム IDを作成し、必要なユーザー フィールドを追加できます。次に、カスタム ID をグローバル フィルターに設定し、アクションの結果でアクセスします。リクエストごとにデータベースにクエリを実行したくない場合は、最初のリクエストでそれを呼び出してから、ユーザーが更新されるまで結果をキャッシュしてから、オブジェクトをリロードしてカスタム ID に再度設定してください。

于 2013-03-20T17:11:36.423 に答える