2

組み込みの ASP.NET メンバーシップとロール プロバイダーを使用して、認証された各ユーザーが表示および編集できる内容を制限するシステムを作成したいと考えています。

このソフトウェアには、「アイテム」と「グループ」という概念が既にあります。各アイテムはグループに属します。

システムのユーザーは、実際には同じグループに属しています。これは現在、私のドメイン モデルでは表現されていません。

これらのユーザーに拡張したい権限には、表示と編集の 2 つのレベルがあります。グループに所属している場合は、そのグループ内のアイテムを表示できるようにしてほしい。彼らがそのグループの編集権限を持っている場合、そのグループのアイテムを編集できるようにしてほしいです。

通常、ユーザーは 1 つのグループに属しますが、ある時点で複数のグループに属する場合があります。ユーザーが複数のグループに対して表示権限を持っている可能性がありますが、表示できるグループの 1 つ (またはいくつか) に対してのみ編集権限を持っています。

これに対処する方法がわかりません。Group1View、Group1Edit など、グループごとに (asp.net ロール プロバイダーを使用して) 2 つのロールを作成するだけでよいのでしょうか。または、aspnet_Users テーブルと Groups テーブルの間の関係を作成する別のテーブルを作成し、3 番目の列で特権レベルを識別する必要がありますか?

最終的には、Steve Smith がブログで書いたものと似たような権限チェックを実装したいと思います: http://stevesmithblog.com/blog/favor-privileges-over-role-checks/

ご意見をお寄せいただきありがとうございます。

4

1 に答える 1

2

これを実装するカスタム メンバーシップとロール プロバイダーを作成し、参照しているこのセキュリティ コンポーネントをラップします。メンバーシップとロールが提供するものは、必要な最小限のリクエストを処理するためだけに使用し、アプリケーション全体のセキュリティに依存することはありません。

ロール プロバイダーは、階層が複雑なカスタム セキュリティのニーズにうまく適合しません。あなたが言及したことは(名前で)機能し、カスタムロールプロバイダーは、あなたが言及したコンポーネントからもユーザーがアクセスできるロールの名前を派生させることができます。ただし、組み込みのフレームワーク機能 (ログイン コントロール、サイト マップ コントロール、または使用するものすべて) を処理するためにのみ使用し、それ以外の場合は独自のセキュリティ設定を使用します。

ロール プロバイダーは、長期的にはニーズに対して制限が厳しすぎることになります。

HTH。

于 2011-07-28T20:00:27.483 に答える