I'm rebuilding the admin part of a legacy application which has
multiple account types and multiple levels of authority and I’m
thinking using ACL and seeking some advice. Here are some background:
The application needs to handle 4 types of accounts
1-Administrators
2-ContentManagers
3-SiteModerators
4-Authors
and several types of resources:
- Content
- Report
Levels of accounts and rules are as followed:
Administrators
-Admin1
-Admin2
-ContentManagerX
-Author1
-Author2
-SiteModeratorA
-Author3
-Author4
-SiteModeratorB
-Author5
-Author6
-SiteModeratorC
-Author7
-Author8
-Author9
-Author10
Each account logs into the admin interface using username and
password.
Each Admin, ContentManager, SiteModerator and Author has ONE account
to create/manage
+ their own accounts/profiles and accounts/profiles of lower level
accounts'.
+ the content items created by themselves and by lower level accounts'
Example:
A ContentManagerX can create many SiteModerators (e.g SiteModeratorA,
SiteModeratorB, SiteModeratorC) and can manage
+ accounts/profiles of SiteModeratorA,B,C and content
items created by of SiteModeratorA,B,C
+ account/profiles of Authors (3,4,5,6,7,8) - created by
SiteModerators
+ account/profiles and content items of Authors (1,2) -
created by ContentManagerX itself
Administrator can create/manage many ContenManagers (X,Y,Z).
Except for admin users, an user account at any level should NOT have
access to accounts/profiles and content items not under its authority.
For example SiteModeratorA should NOT have access to SiteModeratorB's,
Author5's and 6’s accounts/profiles and their content items
ContentManagerY (not shown on the figure) should NOT have access to
accounts and resources that belongs to ContentManagerX
There are potentially a couple of millions of content items
There are potentially 50K of accounts
Most tutorials on the net offer solutions where users belong to fixed
groups (e.g Admin / Managers /Users) but my case is a bit different.
Levels of accounts are nested. Accounts are also dynamic, meaning I
have an unknown number of accounts of ContentManager (X,Y,Z ect.) and
those accounts can give birth to an unknown number of SiteModerator
(A,B,C etc.). An Author (end user) can be created by/at any level.
Authors can register themselves as well (eg. Author 9, 10)
The profiles structure are completely different from one account type
to another; in order to normalize tables I probably won't put profiles
in one single table with parent_id linking entries as found in
traditional ‘users’ and ‘groups’ tables.
Questions:
---------------
1 - Naturally, to provide protections at record level I might have to
create ARO, ACO and AROs_ACOs entries for all existing accounts /
content items. Not only that requires a large amount of work but I am
worrying about the performance . How can I avoid this? What is the
solution to keep aros, acos and aros_acos table light. (most tutorials
including the one on IBM site suggest adding aros/acos for every
account and resource item - not sure if it is always a practical
approach)
2 – What is the consideration if I use ‘actions’ mode for Auth (e.g
Auth::authorize = ‘actions’), I know this mode requires me make an
inventory of all controller/action to create acos.
3– Or should I use ‘crud’ mode (e.g Auth::authorize = 'crud'? ) in
conjunction with Auth::actionMap
4- would it be better to create an 'users' table to store just
accounts (username / password) or they can be spread out into the
tables for different account types (content_managers, site_moderators,
authors ).
5- Is it easier and more flexible to just use Auth::authorize =
‘controller’ and put all permission checking logic in
Controller::isAuthorize() ?
Any suggestion is appreciated ( and welcome comments from aranworld,
lemoncake, mark_story, francky06l and AD7six - Many thanks to each
of you for excellent tutorials on ACL)
Zonium
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"CakePHP" group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to
cake-php+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---
