2

Webアプリに役割ベースのセキュリティを実装しようとすると、データベースに、アクセス許可、役割、ユーザー、およびUserRole（つまり、ユーザーの役割への割り当て）のテーブルがあります。

各役割には一連の権限があります。アクセス許可は、0、1、2、4などの値を持つC＃フラグ列挙型として定義されます。

データベースでは、役割テーブルには、役割の結合された権限フラグを格納するintフィールドがあります。（このようにして、個別のパーミッションテーブル（それは良いか悪いか？）とRolePermissions用の1対多のテーブルを持つことを避けます。

コードでは、ユーザーに割り当てられている役割の有効なアクセス許可を計算して、ユーザーがアクセスできるかどうかを確認します。.NETでは、列挙型フラグに対して論理演算を実行することで、これを行うのは非常に簡単です。

だから私の質問は：

この方法で行うことには不利な点がありますか（パーミッションテーブルとRolePermissionリンクテーブル（ロールに与えられたパーミッションごとに1つのレコードが含まれる）とは対照的ですか？

4

3 に答える 3

1

プロジェクトで3年前に説明したように、フラグ列挙型を使用しました。私の考慮事項：

  • レイヤーを作成して使用を簡素化しないと、フロント エンドのコードが煩雑になります
  • 「新しい開発者」にとっては直感的ではありません。他の誰かがこのコードを保守する場合は、アイデア全体を見落とし、複雑さやバグが増える可能性があることに注意してください...

追伸:

各役割には一連の権限があります。アクセス許可は、0、1、2、4 などの値を持つ C# フラグ列挙型として定義されます。

フラグ列挙型で 0 を使用しないでください...

于 2011-10-20T12:21:28.013 に答える
1

差し迫った 3 つの欠点:

  • フラグには、使用可能なビットと同じ数のアイテムのみを含めることができます。
  • データベースからのクエリが少し面倒になりました。SQL を手動で使用している場合に限ります (メンバーシップを決定するためにロール テーブルに結合すると、より適切に読み取れます)。
  • データをフラグとして表示しない場合、4 番目のビットの 1 の値が何を意味するか覚えている人はいますか?

生活を楽にして、別のリストを使用してください。はコレクション内で に割り当てられ、非常にうまくまとめることができmyPermissions.Contains(new Permission("CanEdit"))ます。次に、さまざまな変換ルーチンを使用して、列挙型や文字列などのハードコードされた値をアクセス許可のオブジェクト表現に変換して、達成することができますmyPermissions.Contains("CanEdit")。

これは、個別のテーブルに対してフラグを選択する際にパフォーマンスに影響があると言っているわけではありません。また、その逆も同様です。

于 2011-10-20T10:41:10.003 に答える
1

唯一の欠点は、パーミッションをチェックするために、より多くのコードを書くことになることです。ユーザーロールを含む別のテーブルを用意すると、ロールの決定が非常に簡単になります。

  • 利点: ストレージ スペースを節約します (しかし、このシナリオでは誰がこれを気にしますか?)
  • 欠点: コードがより複雑になります。
于 2011-10-20T10:48:27.390 に答える