認証が必要なエリアがあるサイトがあります。現在、その領域のすべてのコントローラーでロール属性を使用し、クエリを実行してそのユーザー ID とそのすべての設定を取得しています。
その領域のコントローラーがロードされるたびにユーザーIDと設定を取得しているのは、コードまたはデザインの匂いのように思えますか? セッションを使用する必要があるかどうか、または ASP.Net MVC 2.0 がこれを処理するための独自の方法を提供するかどうかはわかりません。もう 1 つの懸念事項はセキュリティです。
全体として、どの方向に曲がればよいかよくわかりません。設計上、ユーザーがエリアにログインしたときに userId と設定を一度だけ取得したいと考えています。現在、コントローラーがロードされるたびに userId を取得し、必要に応じて、その都度データベースにクエリを実行して設定を確認しています。
セキュリティに関するルールの 1 つは、自分でやろうとしてはならないということです。抜け穴やバックドアを残さずに認証システムを正しく実行するには、多くの落とし穴があります。したがって、その点で、.NET に付属する SqlMembershipProvider を検討することもできます。MVC で使用でき、ロールと現在のセキュリティ コンテキストを取得する手段を提供し、セットアップと構成が簡単で、独自のロールよりも安全です。
SQL Server を使用していない場合は、いくつかの選択肢があります。1 つの解決策は、SQL Server Express や SQL Server Compact Edition などを使用して資格情報を維持することです。もう 1 つの解決策は、SqlMembrershipProvider データベース スキーマを模倣し、そのスキーマと通信するカスタム プロバイダーを作成することです。
最後の選択肢は、カスタム MembershipProvider クラスを作成することです。これはまだ独自のものですが、MembershipProvider の構造に強制的に組み込まれるため、後で別のもの (ActiveDirectoryMembershipProvider など) に交換できます。たとえば、資格情報とログインを操作するための共通のインターフェイスが提供されます。組み込みの Login コントロールを簡単に使用できます。
既に MembershipProvider を使用していて、追加のユーザー固有のデータを保存することについて質問している場合は、SqlMembershipProvider について上で述べたすべての注意事項を備えた SqlProfileProvider をお勧めします。ProfileProvider は、現在ログオンしているユーザーのユーザー固有のデータを維持するための構造を提供します。
詳細については：
カスタム ID を実装することもできます。それらは実装が非常に簡単で、必要なユーザー情報を Identity に保存できます。これは、Identity が配置する Cookie に保存されるため、その情報を取得するために毎回 DB にアクセスする必要はありません。
GenericIdentity から継承する新しいクラスを作成するだけで、すぐに使用できます。
もちろん、Cookie に含まれているため、そこに入れる情報の量には注意する必要がありますが、通常、ここで話している場合のユーザー関連の情報はそれほど大きくありません。
カスタム ID を使用して、ユーザーに関するいくつかの情報を保存していますが、これは非常にうまく機能しています。
必要なすべてのユーザー情報を保持するオブジェクトをセッションに格納できます。ユーザー情報/プロファイルを取得するコントローラー、ビュー、またはその他の基本クラスにプロパティを追加する必要があります。これは、認証情報（フォーム認証など）ではなく、認証情報になります。
私たちは過去にこれをかなりの回数行ってきました。Thomasが言及しているのと同様に、私たちが一般的に行っていることは、これを行うためにMicrosoftSQLMemberhsipプロバイダーに基づく新しいメンバーシッププロバイダーを実装することです。基本のMembershipUserクラスから継承し、ユーザーオブジェクトに必要なカスタムプロパティを追加します。GetUser実装でメンバーシッププロバイダーのデータベース読み取りを実装する必要があるため、必要な追加のプロパティをそのデータベース読み取りに統合できます。
SQLサーバーを使用している場合、Microsoftはその2.0コードをリリースしています。詳細については、ScottGuのブログをご覧ください。
http://weblogs.asp.net/scottgu/archive/2006/04/13/442772.aspx
ゼロから始めたい場合は、MSDNにも優れたリソースがあります。
http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx
と
http://msdn.microsoft.com/en-us/library/6tc47t75.aspx
プロバイダーを実装したら、メンバーシップユーザーを現在のWebコンテキストのItemsコレクションに追加して、コードからプロバイダーにアクセスできます。基本基本ユーザークラスの非拡張プロパティも、通常のように要求スレッドで使用できます。
ソースコードの2.0バージョンのMicrosoftリリースにより、再発明に関して存在するいくつかの懸念を軽減するのに役立つことがわかりました。実装について考慮すべきもう1つのことは、シナリオに基づいています。一部のコードの実装をバイパスできます。この例は、すでに資格情報を持っているバックエンドシステムにアクセスしている場合のCreateUserコードです。
「Windows Identity Foundation」を試してみてください。私はしばらくの間、私のプロジェクトの1つでそれを使用しています。これにより、「クレームベース認証」が可能になります。これは基本的に、ユーザーがログオンしたときにユーザーを説明する一連の情報である「クレーム」を指定できることを意味します。
ログオンすると、フィールドからユーザーのクレームを読み取ることができますHttpContext.Current.User。ロール ベースの認証スキーマとシームレスに統合する "Role" クレームを使用することもできます。つまり、ユーザーに「マネージャー」ロールの要求を与えてから、`if (User.IsInRole("manager")) を使用できます。
追加のボーナスとして、WIF を使用すると、ログイン画面を他のアプリケーションで簡単に再利用できます。
全体として、非常に柔軟ですが、ドキュメントは非常に貧弱です。StackOverflow の「Windows Identity Foundation」について、いくつかの質問と回答をしてきました。
認証プロセスには比較的満足しているようですが、セッション/設定の他のオプションを検討したいと考えています。
私の提案は、設定のみに関係しています (役割、設定など)。
私の意見では、UI からビジネス層、DB 層、DB へとテクノロジ スタック全体を横断する必要があるのは、少しやり過ぎです。セッション中に変更される可能性が低いデータの場合、これにより多くのオーバーヘッドが追加されます...いくつかのデータ変換が発生する可能性があります (DB (リレーショナル形式) -> ORM -> Web サービス XML シリアライゼーション -> Web 層デシリアライゼーション) .
負荷の高い RDBMS システムや ASP.NET キャッシング / セッション モデルに依存しないセッション システムを検討することもできます。非常にパフォーマンスが高く、拡張性に優れたオプションがあります。
Ayende Rahien (Built for .NET) によるRavenDBを使用できます。その主な目標は、スキーマのない JSON ドキュメントへの低レイテンシで高性能なアクセスを提供することです。
このソリューションを使用すると、データへのアクセスが非常に高速になるように、Web 層に ravenDB をセットアップできます。初めて認証して設定を取得するときに、ユーザー ID と設定情報をこのセッション DB に保存します。その後、コントローラーをロードするたびに、RDBMS に戻らなくても設定データにアクセスできます。この DB は、他の Web 関連データのキャッシュにも使用できます。
セキュリティに関しては、使用する方法に関係なく、設定データは Web 層になります。このソリューションは、他のオプションよりも安全性が高くも低くもありません (暗号化されていない Cookie よりも安全です)。必要に応じて、セッション データを暗号化することもできますが、それによってオーバーヘッドが再び増加します。
考慮すべき数百万のオプションの 1 つにすぎません。
幸運を、
あなたが決めたことを私たちに知らせてください！
パトリック。