2

これはトリッキーな質問です。私たちはこの問題についてしばらく (数日間) 話し合ってきましたが、説得力のある良い解決策が見つかりませんでした。これは状況です：

  • ユーザーとグループがあります。ユーザーは多くのグループに所属できます (多対多の関係)
  • アクセス制御が必要なサイトの特定の部分がありますが、次のとおりです。
  • アクセス制御が必要な特定のテーブルの特定の行があります。特定のユーザー (または特定のグループ) が特定の行を削除できないようにする必要がありますが、同じテーブルの他の行では、そのユーザー (またはグループ) に対して別のアクセス許可が設定されている可能性があります。

これを達成する簡単な方法はありますか？何か不足していますか？

これを Python で実装する必要があります (それが助けになる場合)。

4

4 に答える 4

2

この問題は新しいものではありません。基本的には、承認とアクセス権/制御の一般的な問題です。

各ユーザーがそれぞれの可能な方法でアクセスできるオブジェクトの完全なグラフをモデル化して維持する必要がないようにするには、(アプリケーションの動作に基づいて) 乗法スケール ファクターで支配を開始する方法について決定を下す必要があります。まず、ユーザーはどこで権利を取得しますか? 各ユーザーに個別に権限が割り当てられている場合、ユーザーを追加したり、ユーザーを変更したりする必要がある人に、継続的な管理上の大きな課題を課すことになります。

おそらく、ユーザーは自分がメンバーになっているグループから権限を取得できます。これで、管理を簡素化し、システムを理解しやすくするスケール ファクターが得られました。グループを変更すると、メンバーであるすべてのユーザーの有効な権限が変更されます。

さて、これらの権利はどのように見えるでしょうか？オブジェクト単位でターゲット オブジェクトに権利を割り当てることは、おそらく賢明ではありません。したがって、おそらく権利は一連の抽象的な「アクセス カード」と考えるべきです。システム内のオブジェクトは、読み取りには「青」アクセス、更新には「赤」アクセス、削除には「黒」アクセスが必要であるとマークできます。これらの抽象的な権利は、ある種のトポロジーに配置される可能性があります。たとえば、「黒」アクセスを持つことは、暗黙的に「赤」と「青」も持つことを意味するか、またはそれらがすべてバラバラであることを意味します。それはあなた次第であり、アプリケーションがどのように機能するかはあなた次第です。(また、オブジェクト タイプ (必要に応じてテーブル) には、少なくとも「作成」のために独自のアクセス ルールが必要になる場合があることを考慮する必要があることに注意してください。

システム内のアクターをアクターが操作するオブジェクトに関連付けるグラフ ピクチャに収集ポイントを導入することで、スケールの問題を処理し、承認の複雑さを制御できます。しかし、それは決して簡単なことではありません。また、顧客の要望を声に出しても、決してうまくいかず、実際に顧客 (彼女が考える) が望んでいるものを実際に達成することは決してないという結果になることがよくあります。

実装言語は、必要なアーキテクチャ上の決定とはあまり関係がありません。

于 2010-07-24T23:24:38.617 に答える
1

1) 削除、更新などの権限を持つテーブルを作成する

2）権限テーブルに3方向ピボットテーブルを作成します。行レベルのアクセスが必要なテーブルと、アクセス権の単位（グループまたはユーザー）を含むテーブルです。

3) 操作を続行する前に、ピボット テーブルで関係を確認してください。

権利テーブルは次のようになります。

ID   RIGHT
1    DELETE
2    UPDATE

行レベルのアクセス制御が必要なテーブルは次のようになります (ブログなど):

ID  TITLE           CONTENT
1   blog entry 1    This is a blog entry
2   blog entry 2    This is another blog entry

ユーザーテーブルは次のようになります。

ID   NAME
1    Bob
2    Alice

次に、ピボットテーブルは次のようになります

ID USER_ID RIGHT_ID BLOG_ID
1  1       2        1
2  2       1        1
3  2       2        1
4  2       1        2
5  2       2        2

つまり、Bob はブログ エントリ 1 のみを更新できますが、Alice はいずれかのブログ エントリを更新または削除できます。

編集: ユーザーまたはグループから権限を取得する場合は、テーブルごとに 2 つのピボット テーブルが必要です。1 つはユーザー用、もう 1 つはグループ用です。また、操作を許可または禁止する前に、ユーザー レベルの権限とグループ レベルの権限を確認するために、データベースにクエリを実行する必要があります。

EDIT2: これは David のソリューションよりも複雑ですが、事前に permission_classes を構成する必要はありません: 必要なグループ レベルとユーザー レベルのアクセス許可を組み合わせて一致させることができます。

于 2010-07-25T00:28:38.730 に答える
0

セットアップについて、および異なるユーザーが異なる行に対して異なるアクセス許可を持つ必要がある理由について詳しく知らずに、特定することは困難です。しかし、一般的に、コードでデータベース内のデータにアクセスするときはいつでも、現在のユーザーとグループ、および挿入/更新/削除/その他の行を調べる承認チェックを前に行う必要があります。操作を許可するかどうかを決定します。カプセル化された方法でシステムを設計することを検討してください。たとえば、データベースに直接アクセスするすべての関数を 1 つのモジュールに配置し、それぞれに適切な承認チェックが含まれていることを確認できます。(それらをすべて 1 つのファイルにまとめることで、見逃す可能性が低くなります)

permission_class表に列を追加し、どのユーザーまたはグループがどの権限クラスを持つかを指定する別の表を作成すると役立つ場合があります。次に、許可チェックでは、現在の行の許可クラスの値を取得し、許可テーブルにその許可クラスと現在のユーザーまたはそのグループのいずれかとの関連付けが含まれているかどうかを確認する必要があります。

于 2010-07-24T23:29:16.463 に答える
0

行を分類する追加の列「カテゴリ」または「タイプ」をテーブルに追加します (または、行を分類する場合はグループ化/クラスター化します) - 次に、(rowCategory、userGroup 間のアクセス制御を定義するピボット テーブルを作成します)。 ）。したがって、各行について、そのカテゴリによって、どの userGroups がアクセス権を持っているか (およびどのような種類のアクセス権があるか) を引き出すことができます。

于 2010-07-25T02:11:29.987 に答える