Thanks, all, for the responses. I guess I should have mentioned that I've used ACL before, for an intranet to allow a company's affiliates log in and access many types of files. The requirement was that each group be shown (and be able to download) only certain folders/files. I used ACL and a tree structure (it was, essentially, a directory structure) and a record-level protection model. After *a lot* of frustration (my first stab at ACL), it worked very well. I should really get around to writing an article for the Bakery, as I don't think anyone else has published anything on doing this with Cake.
That said, I'm leaning away from ACL for this project. The issue for me is not so much access control but modeling different user types. I've decided to store the model name & association_key in the users table, which is an approach that's worked well for me in similar (non- user) situations. Then I'll have separate Member, Affiliate, and Administrator models. Auth will keep that info in the session, so I can use that for access control after authentication has proceeded. On Mar 17, 3:33 pm, Martin Duris <[email protected]> wrote: > one of the key to understand is to know how ACL works - tree structure > - than its just question of time, to get everything work > > 2010/3/17 Alejandro Gomez Fernandez <[email protected]>: > > > I'm new usign cake, but not designing information systems in different > > platforms, even web. > > I think the solution to your dilemma is using ACL. Yes, I know is at the > > beginning difficult to understood and implement, but it was designed > > speciffically to solve this problem. It permits you to assign differents > > roles to any person and to change this persons' role in any moment without > > any aditional work (more than select the roles in the ACL admin). > > Obviously there are many other workarounds to solve your specific problem, > > but the idea behind cake is re-usability. When you adjust an ACL (maybe at > > the beginning almost copy and paste from any book or tutorial) you can > > re-use it in any other project. When many more times you practice to > > develop/implement any technic, more close you are of master it. > > I hope this comment serves you to decide how to approach this problem. > > > Regards, > > > Alejandro Gomez Fernandez. > > > El 16/03/2010 15:44, cricket escribió: > > > I'm just starting on a site that will have several types of users and > > am uncertain of the best approach to take. I'd like to hear from > > others who have done something similar. > > > The site will have the following user types: > > > Administrators > > Members > > Affiliates > > > Admins may or not be Members. Affiliates will not be Admins nor > > Members, but the fields for Affiliates and Members are quite similar. > > However, they may diverge further down the road. > > > All should be able to log in, so I plan to, at least, have a users > > table with the passwords. But I'd prefer not to have every possible > > field stuffed in there and instead use separate models for each type. > > This seems like a good fit for role-based authentication, using > > Groups, but I think it would make more sense to have separate Member, > > Affiliate, and Administrator models. > > > But, in that case, how should I go about registering what a newly- > > logged-in User is? One idea I had was to include "model" & > > "association_key" fields in the users table, then loading the info as > > needed (because it will be stored Auth's session array). > > > So, how have others approached this? ExtendableBehavior? > > InheritableBehavior? PolymorphicBehavior? Something else? > > > Check out the new CakePHP Questions sitehttp://cakeqs.organd help others > > with their CakePHP related questions. > > > You received this message because you are subscribed to the Google Groups > > "CakePHP" 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 > > > Check out the new CakePHP Questions sitehttp://cakeqs.organd help others > > with their CakePHP related questions. > > > You received this message because you are subscribed to the Google Groups > > "CakePHP" 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 > > Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups "CakePHP" 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
