would this help? http://jmcneese.wordpress.com/2009/04/05/row-level-model-access-control-for-cakephp/
On Apr 7, 1:06 am, zonium <zon...@gmail.com> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
