Re: ACL - How to handle multiple nested levels of accounts
i guess the theoretical limit on a 32bit system is 4,294,967,296 (2^32), but my first question would be do you need unlimited groups, or unlimited roles? roles being the classification of user where actual ACL permissions are attached (role "a" can access the users::add method, but role "b" is not, etc)... a user could have an unlimited amount of roles. On Apr 10, 12:49 pm, zonium wrote: > Thank you jmcneese for showing me an alternative to the cake's ACL. > Your articles help me understand weaknesses of ACL when used to > safeguard records. It's was interesting to see immediate attentions/ > reactions from the core developers on those articles as well. > > One problem (in my case) with the solution you presented is that > groups are powers of two.This limits the number of groups to the > number of bits in an integer. I have unlimited numbers of "groups". > > Besides, in my case, "groups" are not in one table where I can use > parent_id linking entries for tree behavior to work. > > I am still looking for advice. Would like to hear from any one who has > dealt with a similar situation as mine. > > On Apr 7, 7:09 am, jmcneese wrote: > > > would this help? > > >http://jmcneese.wordpress.com/2009/04/05/row-level-model-access-contr... --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: ACL - How to handle multiple nested levels of accounts
Thank you jmcneese for showing me an alternative to the cake's ACL. Your articles help me understand weaknesses of ACL when used to safeguard records. It's was interesting to see immediate attentions/ reactions from the core developers on those articles as well. One problem (in my case) with the solution you presented is that groups are powers of two.This limits the number of groups to the number of bits in an integer. I have unlimited numbers of "groups". Besides, in my case, "groups" are not in one table where I can use parent_id linking entries for tree behavior to work. I am still looking for advice. Would like to hear from any one who has dealt with a similar situation as mine. On Apr 7, 7:09 am, jmcneese wrote: > would this help? > > http://jmcneese.wordpress.com/2009/04/05/row-level-model-access-contr... > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: ACL - How to handle multiple nested levels of accounts
would this help? http://jmcneese.wordpress.com/2009/04/05/row-level-model-access-control-for-cakephp/ On Apr 7, 1:06 am, zonium 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 -~--~~~~--~~--~--~---
ACL - How to handle multiple nested levels of accounts
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 -~--~~~~--~~--~--~---
