0

役割ベースの ACL をどのように設計する必要があるか:

複数のチーム。各チームは 1 人のマネージャーと複数のメンバーで構成され、1 つの場所で作業します。各場所には複数のチームがあり、複数の場所があります。

各チームのマネージャーは、自分のチーム メンバーのデータのみを表示/編集できました。人は、場所に関係なく、複数のチームのメンバーになることもできます。

Location_1
-Team_1            -Team_2
 -Manager           -Manager
  -Member_1          -Member_1
  -Member_2          -Member_2

Location_2
-Team_1            -Team_2
 -Manager           -Manager
  -Member_1          -Member_1
  -Member_2          -Member_2

私の考え：私はそれを2つの部分に分けることを考えています. パート 1: 各チームに 1 つのグループが必要です。グループ メンバーシップのテーブルをデータベースに保持します。パート 2: これで、各ユーザーは任意のロールを持つことができます。ACL は、これらのロールに基づいて設計できます。ただし、データはパート 1 に基づいて取得されます。この方法では、コードを変更せずに新しいチームを追加できます。これは正しい方法ですか？

4

1 に答える 1

3

ここではかなりおしゃべりな答えのようなもので、ゆるい議論のみで、少なくとも今のところコードはありません。

独自のモデル/データ構造では、メンバー、場所、およびチームを考慮する必要があります。関係をかなり明確に説明したと思うので、それは簡単なはずです。関係的に考える: マネージャーを含むチーム メンバー用のテーブル。場所のテーブル。場所への外部キーとマネージャーを識別するメンバーへの外部キーを持つチームのテーブル。メンバーをチームにリンクする相互参照テーブル。あなたのメンバーモデルには、そのようなもののためisManagerOfTeam($team)のメソッドがあると思います。isMemberOfTeam($team)かなり簡単です。

しかし、これの多くは関係をモデル化するだけであり、おそらくアクセス制御とは無関係です。

アクセス制御の場合、場所は関係ないようです。鍵となるのは、チームメンバーシップとチーム管理です。

また、アクセス制御しようとしているデータ (最終的には「リソース」になるもの) は、「所有」メンバーを識別するメンバー ID でタグ付けされるようです。そのため、そのデータのモデルにはメソッドgetMember()またはgetMemberId().

Zend_Acl_Assert_Interfaceそのため、インスタンスを使用してロール ($member) とそれらのリソースとの関係を動的に調べる ACL ルールがいくつか見られます。

  1. My_Acl_Assertion_BelongsToSelf
  2. My_Acl_Assertion_BelongToMemberUnderManagement

次に、assert()メソッドは、渡されたロールとリソースで関連するモデル メソッドを呼び出して、チームと管理の関係をチェックできます。

私が言ったように、ちょっと緩い答えですが、それがいくつかのアイデアに役立つことを願っています.

于 2011-05-08T07:18:00.143 に答える