5

概要

システムは、ネストされたカテゴリに編成された多くのアイテムを処理する必要があります (以下の視覚的な例を参照)。クライアントにパーミッション ルールを定義する機能を提供します (以下のパーミッション ルールを参照)。また、どの項目にも依存しないさまざまな一般的な権限を処理する必要があります (たとえば、「特定のページを表示できますか?」または「新しいメンバーを招待できますか?」)。

すべてのユーザーはグループに編成されます。各ユーザーには、自分が所属するメイン グループがありますが、追加のセカンダリ グループもある場合があります。

少数のユーザーをスーパー管理者として構成し、何でもできるようにする必要があります。

ユーザーが何かを実行できるかどうかを決定する場合、権限の継承は次のようになります。

  • メイングループの権限から始めます
  • ユーザーの追加グループのいずれかによって許可されたすべての権限を許可する
  • 定義されている場合は、ユーザー固有のアクセス許可を確認します (上記とは関係なく、許可または拒否します)。ユーザー固有のアクセス許可を定義する必要はありません。定義されていない場合、ユーザーはグループのアクセス許可からアクセス許可を継承するだけです。

グループ権限を定義するとき、クライアントは継承を使用して次のように言うことができます。

  • 許可されたユーザー ...
  • 編集者には、ユーザー+ ...のすべての権限があります。
  • モデレーターには、編集者+ ... - ...のすべての権限があります。
  • 管理者には編集者とモデレーターのすべての権限があります

注:現在のユーザーが編集/表示できるデータベースから最後の 10 個のアイテムを要求できる必要があります。各アイテムのアクセス許可はデータベースによって決定される必要があります。アプリケーション レベルでアクセス許可のためにアイテムをフィルター処理したくありません。データベースに保存されている情報に基づいて決定できれば。

許可規則

ルールは、アイテムの任意のプロパティ (アイテムの所有者のメイン グループ、作成時間、カテゴリなど) に依存する可能性があり、その情報はデータベースに保存されます。

ルールは、現在のユーザーの任意のプロパティ (サインアップ日、招待されたメンバーなど)、要求されたアクション (表示、リスト、名前の変更、削除の取り消しなど)、および実行時に既に利用可能なその他の情報 (URL パラメーターなど) にも依存する可能性があります。 、クォータ制限、アイテムのコンテンツ、サーバーの負荷など)、その情報は php スクリプトで利用できます。

以下のサンプル ルールを参照してください。

データベース スキーマの視覚的な例:

Category 1
   Nested Category A
      item x
   Nested Category B
      Deeply Nested Category
         item w
      item y
Category 2
   item z

現在、データベース スキーマは次のようなものですが、必要に応じて変更できます: (もちろん、これはスキーマの一部にすぎません。他のテーブルやフィールドもあります)

アイテム:

id | title  | owner_id | category_id
====================================
1  | item x | 2        | 3
2  | item y | 1        | 4
3  | item z | 3        | 2
4  | item w | 1        | 5

カテゴリ:

id | parents | title
=====================================
1  | null    | Category 1
2  | null    | Category 2
3  | 1       | Nested Category A
4  | 1       | Nested Category B
5  | 1/4     | Deeply Nested Category

ユーザー:

id | name | group | all_groups | is_super_admin
===============================================
1  | Tony | 5     | 5          | 1
2  | John | 5     | 5,8,6      | 0
3  | Mike | 4     | 4,7        | 0
4  | Ryan | 6     | 6          | 0

ルールの例

次のルールは、実装する必要がある実際のケースのサンプルにすぎません。

  • ユーザーは、送信から 5 分以内に自分のアイテムを編集できます ()
  • ユーザー 'John' は、'Category 1' 内のすべてのアイテムと、そのネストされたすべてのカテゴリを編集できます。
  • 編集者は、所有者がスーパー管理者としてマークされているアイテムを除くすべてのアイテムを編集できます。

これらのルールは、私の場合のほとんどのルールと同様に、データベース レベルで決定できることに注意してください。

実装

symfony のドキュメント、stackoverflow などを検索しました。セキュリティと ACL に関する興味深い記事や質問がたくさんありますが、そのようなシステムを処理する最善の方法を見つけることができませんでした。

定義されたルールに従って、データベースに格納された情報に基づいて行をフィルター処理するには、ある種の動的クエリ ビルダーが必要であることは明らかです。2番目のステップ（現在のサーバー負荷などのデータベースに保存されていない情報を含む）は、おそらく投票者（この記事またはこの質問の投票者の例を参照）、または場合によってはさらに単純な解決策（要求されたパスに依存するルール)。パーミッションを処理するために複数のものが含まれるソリューションの場合は、それらを統合して一緒に使用する方法についても説明してください。

質問

そのようなシステムを実装する方法を尋ねています。symfony のドキュメントへのリンクや、一般的なアイデアや一般的な単純なケースを含む他のリソースへのリンクで答えないでください。回答する前に、私のケースを読んで理解してください。

4

1 に答える 1

1

この質問は古いと思いますが、回答は Symfony 2.3 以降に適用されるため、ここに投稿します。

このアプローチでは、SecurityVotersなどを使用する必要があります。

セキュリティボーターを使用すると、想像できるアクセス制御のロジックを実装できます。

有権者は次のように機能します

$this->get('security.authorization_checker')->isGranted('update',$post);

Postエンティティを操作できるすべての有権者をチェックし（ドキュメントを参照）、投票を選択した戦略（肯定、コンセンサス、全会一致）と組み合わせて、現在のユーザーが投稿を更新する権限があるかどうかを判断します（最初のトゥールの例）

単一のアクションに対して複数の投票者を実装し、結果の投票を決定するための戦略を定義できます。

リポジトリに保存し、投票者内の教義でそれらを取得できるすべてのグループと権限。

また、セキュリティ作業を簡素化するためにカスタム ロール階層を定義することもできます

SecurityComponentのこれらのドキュメントもお読みください

于 2015-02-20T09:31:12.553 に答える