I have an implementation like this... ACOs Admin Clients + Company::1 + + Company::1.login + + Company::1.users + + Company::1.transactions + + (... one for each controller) + Company::2 + + (...) + (...) Users + User::1 + User::2 + (...)
AROs Admin + User::1 Users + User::2 + User::3 + (...) Each User::n aro has access to User::n aco. The ARO admin group has access to ACOs Admin, Clients, Users... And, each Company::n ACO can be accessed by selected users... If an user has access to the Company::n matrix, he access everything below it... If an user has write access to Company::n.users, he can manipulate wich registered users can access what and he can register users. (Users cannot self-registrate). Just my 2 cents for your references... =) Regards On Aug 7, 9:43 pm, Langdon Stevenson <[EMAIL PROTECTED]> wrote: > Hi Alteczec > > I have a similar issue with a manufacturing process management > application. My solution was to create generic "data" ACOs for various > groups. Like this: > > - Company A > -- admin data > -- manufacturing data > - Company B > -- admin data > -- manufacturing data > > etc > > When a user is registered, they are given permissions on their companies > ACOs > > When a record is saved a reference to the ACO group that the data > belongs to is saved in one field. Now I can tell which ACO a record > belongs to > > When a user logs in I get (using the ACL system) a list of ACOs that the > user has access to and store it in their session. > > When querying data from the database I limit the data set with a "WHERE > [field.name] IN ([list, of, ACOs])" clause. This means that each user > can only retrieve the data that they have permission to see. It won't > matter how they hack the URL, or form values, the application will just > filter out what they don't have access to. > > I think that this is a reasonably flexible solution that results in the > smallest number of ACOs for data, the best performance at the user end > and the smallest possible system load. > > Regards, > Langdon > > <snip> > > > But this brings up a few questions: > > > A) Do I create a parent ARO (group) to hold all of the admins and > > editors of a store? > > B) Do I create a parent ACO (group) to hold all of the products and > > categories? > > - Doing A and B would allow me to say group A ARO's can access group > > A ACO's - > > Is this the best way to implement the authorization component of the > > application? Would it be better to ignore the grouping of ARO's and > > ACO's? > > > I'm concerned about the scalability of implementing this. If I have > > 1000 products and 100 categories that would be 1100 ACO's for one > > store. Not to mention that if I had 3 editors for that store I would > > have 3 x 1100 AroAco's? This is where I was hoping the grouping of > > ACO's under a parent would come in. You could just grant editor A > > access to group A ACO's - right? If you have 300 stores this quickly > > grows... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
