階層を持つユーザーのアクセス許可を管理する

Question

組織がビジネスに関する情報を入力するシステムを構築しています。一部のユーザーが組織の統計にアクセスできるだけのレベルのユーザーは、レポートを利用できるようにする必要があります。上位レベルのユーザーは、個々の組織の統計情報だけでなく、上位レベルのエンティティの集計統計情報にアクセスできます階層）。

• 自治体内の1つの以上の組織があります。 1つの以上の状態
• があります状態
• 内の1つのまたは複数の郡があるでしょう郡
• 内の1つのまたは複数の自治体があります
• 機関、地方自治体、郡、および状態を追加することができます
• システムに組織、自治体、郡が追加されると、その状態を閲覧する権限を既に持っているユーザーは、明示的に管理者を必要とせずに新しい組織/自治体/郡のレポートを自動的に表示できます許可を与える。地方自治体および郡レベルの下にある新しいエンティティが階層に追加されるたびに、レポートを市区町村レベルで表示する権限を持つユーザにも同じことが適用されます。

いくつかの例：

ユーザー1：は唯一の組織の＃のためのレポートを表示することができます1

ユーザー2：は自治体の＃の下のすべての組織のためのレポートを表示することができます2

ユーザー3：市町村のすべての組織のレポートを表示できます＃&＃2

ユーザー4：は郡＃下のすべての組織のためのレポートを表示することができます3

ユーザー5：私の質問は、私はこれをどのように整理するかされる3

状態＃下のすべての郡のレポートを表示することができますか？私は、個々の組織に許可を与えることなく、レポートに権限を割り当てる最良の方法が不明です。それは明らかに実用的ではありません。

ここでACLに対処するいくつかの質問がありますが、これには当てはまらないようです。そうであれば、それがACLにどのように関連するかについての説明も満足のいく回答であろう。

Answer 1

私は（oranisation、地方自治体、郡、州）

を一つの方法は、あなたが各エンティティに独自の許可IDをASSINGということであると考えていますので、あなたのテーブルが新しい列は、次の形式でpermission_idている必要があります 機関1は、許可ID M1 市2は、許可ID M2

などがありますがあります許可ID O2

市1を持っていますO1 組織2をpermission_idています。唯一Organisation1 M1のためのpermisssion - - 市1 M1M2内のすべての組織の許可 - の権限の許可列が O1のようなものになります

次に、あなたが権限テーブルを作ることができます（ID、id_user、パーミッション） 自治体1及び2

S1内のすべての組織 - 状態1

の許可これが私の意見です。ユーザーが自治体にアクセスできることを知っている限り、自治体の下にあるすべてのものにアクセスできる必要があります。 現在のエンティティからルートを取得できるphp関数の一部は、ユーザー権限と一致する可能性があります。

例。

あなたは自治体のページにいます。 M2。 S2への許可を持っているユーザで あなたの機能が引数として得られます。自治体のIDと関数は、ルートを作成します：M2、C3、S1。 S2とS1を比較すると、許可が拒否されます。この方法では、複雑さはO（n）であり、nはエンティティ（組織、地方自治体、郡および州、つまり4）の数です。

Answer 2

データベース内に1つ以上のユーザーアカウントレベルを持つ一連のユーザーグループを作成し、そのグループに階層型の値として整数を割り当ててから、個々のアカウントに対して同じ操作を行うことをお勧めしますグループ内のレベルは、このような何か（これは、リレーショナル構造であるが、使用のInnoDB）：権限のため

table: account_groups (Broader account groupings) 
Fields: 
-id_key - primary key, auto number 
-group - unique index 
-parent - index, foreign key=account_groups.group (this allows you to create group trees, so you can specify that a county group belongs to a state, and a municipality belongs to a county group, etc.) 
-group_hierarchy - integer (0 is highest permission group, each subsequent one step lower) 

table: account_levels (Account levels within a group) 
Fields: 
-id_key - primary key, auto number 
-account_level - unique index 
-group - index, foreign key=account_groups.group 
-account_heirarchy - integer (same as other table but denotes heirarchy within the group 

table: user_accounts (Individual user accounts) 
Fields: 
-id_key - primary key, auto number 
-account_id - unique index, user account name 
-account_level - index, foreign key=account_levels.account_level 

table: user_groups (denotes which tree(s) the user has access to) 
Fields: 
-id_key - primary key, auto number 
-account_id - index, foreign key=user_accounts.account_id 
-group - index, foreign key=account_groups.group 

そして：あなたは、その後の権限を反復処理するためにPHPを使用することができます

table: permissions (directory of permissions that could be applied) 
Fields: 
-id_key - primary key, auto number 
-permission - unique index, permission identifier 
-other stuff you need associated with the individual permissions, based on how you want them to hook into your program 

table: permissions_group_permissions (permissions applied at group level) 
Fields: 
-id_key - primary key, auto number 
-group - index, foreign key=account_groups.group 
-permission - index, foreign key= permissions.permission 

table: permissions_account_permissions (permissions applied at account level) 
Fields: 
-id_key - primary key, auto number 
-account_type - index, foreign key=account_levels.account_level 
-permission - index, foreign key=permissions.permission 

table: permissions_individual_permissions (permissions applied to individual accounts, if neccessary) 
Fields: 
-id_key - primary key, auto number 
-account_id - index, foreign key=user_accounts.account_id 
-permission - index, foreign key=permissions.permission 
-allow_or_deny - boolean (TRUE means permission is granted, FALSE means permission if revoked. This allows you to fine tune individual accounts, either granting custom elevated permissions, or revoking individual permissions for troublesome accounts without demoting them from the group. This can be useful in some special circumstances) 
-expiration - timestamp (allows you to set expiration dates for permissions, like if you want to temporarily suspend a specific action. Programmatically set default value of 00/00/00 00:00:00 as indefinite. You can do this at the account and group levels too by adding this field to those tables.) 

fiによる個人口座最初にアカウントレベルに関連付けられたグループを取得し、その後の各グループの配列を階層順に作成し、グループ内の現在のアカウントレベルから現在のグループの階層順（グループ配列に多次元配列として追加）を繰り返しますグループ内の最後の既存のアカウントレベルに変更します。次に、後続の各グループのすべてのアカウントレベルを取得し、最後にアレイに追加された各アカウントレベルのすべての関連するアクセス許可を取得します。個々のユーザーのアクセス許可を実装する場合は、個別に適用されたアクセス許可を使用してアクセス許可配列を追加し、最後にallow_or_denyフィールドがFALSEに設定されているアクセス許可をアレイから削除する必要があります。ユーザーが複数のツリーにアクセスする必要がある場合は、アカウントIDに一致するaccount_groupsテーブルにレコードを追加し、ツリーの最上位レベルが何であるかを示し、その後ツリー内のすべての後続グループを反復処理します。該当するすべての権限をアカウントに付与するには、user_groupsからaccount_idのすべてのグループ関連付けを取得し、前述のプロセスを各ツリーに対して実行します。 1つのツリーにしかアクセスできない場合は、user_groupsテーブルを使用する必要はありません。

an example of how the structure fits your model: 
group: USA, hierarchy = 0 
group: California, parent-> USA, hierarchy = 1 
group: Los Angeles, parent->California, hierarchy = 2 
group: Texas, parent->USA, hierarchy = 1 
group: Dallas, parent->Texas, hierarchy = 2 

アメリカのメンバーはすべてにアクセスできます。カリフォルニアのメンバーは、各アカウントのレベルはすべてを持っている

account levels: 
admin, hierarchy=0 
manager, hierarchy=1 
analyst, hierarchy=2 
staff member, hierarchy=3 

（彼らは別の親の枝であるため）、彼らは同じ階層値を持っているにもかかわらず、テキサス州のグループをカリフォルニアの階層に後続のすべてのグループにアクセスすることはできませんが、後続の各アカウントレベルのアクセス許可

user accounts: 
Bob, manager (likes to spam junk email to everyone) 

あなたはまだpermissions_individual_permissionsに電子メール許可を追加し、FALSEにallow_or_deny値を設定することで、ボブのために電子メールで送信する許可を取り消すことができます。これにより、ボブが管理から降格することなく、スパムを阻止することができます。