You might find prefixes useful for your solution. You can set
prefixes for actions and then only allow users of that group to access
those actions. That wouldn't require the ACL and might be what you're
after (separation of group logic).
In 1.3 you'd set different prefixes in your core.php file (admin,
affiliate, member) then you'd define your actions so that only those
with that access level could view them:
admin_edit() ... affiliate_edit() ... member_edit()
In your beforeFilter() you'd just check what action the user is
attempting to use and check if they are in the right group. Something
like:
function beforeFilter(){
if(strpos($this->action,"admin") !== false){
return ($this->Auth->user('group') == 'admin');
}
if(strpos($this->action,"affiliate") !== false){
return ($this->Auth->user('group') == 'affiliate');
}
if(strpos($this->action,"member") !== false){
return ($this->Auth->user('group') == 'member');
}
return false;
}
Just an idea. However, I would still suggest going with ACL in your
case. I'm with WebbedIT -- ACL is too complex for my needs most of
the time, but from your description it sounds like your system could
become unwieldy without it. I'd give ACL a look-see if I were you.
Hope that helps,
Nick
On Mar 17, 4:57 pm, cricket <[email protected]> wrote:
> 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.organdhelp 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.organdhelp 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
