Extend the AuthComponent sounds nice, but I think it´s a feature that
needs to be added to the core, not just to my app. I´m thinking of
opening a new enhancement ticket for next release of the framework.
Cheers,
mbavio
On Jun 9, 4:36 am, XuMiX <[EMAIL PROTECTED]> wrote:
> Just extend AuthComponent
>
> On Jun 9, 7:19 am, aranworld <[EMAIL PROTECTED]> wrote:
>
> > In the context of the AuthComponent, you cannot use anything but the
> > alias in the second param. The logic for this is in the
> > Auth::action() method.
>
> > -Aran
>
> > On Jun 8, 9:52 am, mbavio <[EMAIL PROTECTED]> wrote:
>
> > > The question is: can I use the same syntax for ACOS instead of alias.
> > > I mean the second param...
>
> > > Cheers,
> > > mbavio
>
> > > On Jun 7, 9:11 am, aranworld <[EMAIL PROTECTED]> wrote:
>
> > > > For some reason, I thought the AuthComponent used the username in it's
> > > > call to check but I can now see that in it's first parameter it is
> > > > using the array representing data from the User model. For some
> > > > reason I thought that it used to use only the username alias?
>
> > > > On Jun 6, 12:30 pm, mbavio <[EMAIL PROTECTED]> wrote:
>
> > > > > Aran,
>
> > > > > I agree with your opinion about "crud" being cleaner, but, why do you
> > > > > say what only with:
>
> > > > > check('username', 'CamelCaseController', 'crudmappedaction');
>
> > > > > will work? You can use:
>
> > > > > check(array('model' => 'Model', 'foreign_key' => 'anID'),
> > > > > 'CamelCaseController', 'crudmappedaction');
>
> > > > > and complement it with Acl Behavior, that not set Alias by default.
>
> > > > > Just my two cents.
>
> > > > > Cheers,
> > > > > mbavio
>
> > > > > On May 27, 11:29 am, aranworld <[EMAIL PROTECTED]> wrote:
>
> > > > > > The Auth component has very specific rules for how it checks access.
> > > > > > In 'actions' mode, it will do:
> > > > > > check( 'username', 'CamelCaseController/action', *);
>
> > > > > > In 'crud' mode it will do:
> > > > > > check('username', 'CamelCaseController', 'crudmappedaction');
>
> > > > > > In light of this, your schema looks like it is meant to go with
> > > > > > 'actions' mode and you would have to have a controller X with
> > > > > > actions
> > > > > > like approve_member, post_forum, remove_member, which sounds messy
> > > > > > to
> > > > > > me, becuase the controllers are starting to just become catch-all
> > > > > > function repositories rather than Classes.
>
> > > > > > One thing you could do is have acos like this and use 'crud' mode:
>
> > > > > > ClubXForums
> > > > > > ClubXMembers
> > > > > > ClubYForums
> > > > > > ClubYMembers
> > > > > > ClubZForums
> > > > > > ClubZMembers
>
> > > > > > These would all map to controllers with the standard add, edit,
> > > > > > delete, view, index actions. However, they would actually all be
> > > > > > empty controllers and would merely extend a more generic Forums and
> > > > > > Members controller.
>
> > > > > > So you have Tristan, who is a member of ClubX, but participates in
> > > > > > the
> > > > > > admin of ClubY:
>
> > > > > > Acl->grant('Tristan', 'ClubXForums', array('read', 'create');
> > > > > > Acl->grant('Tristan', 'ClubXMembers', array('read');
> > > > > > Acl->grant('Tristan', 'ClubYForums', *);
> > > > > > Acl->grant('Tristan', 'ClubYMembers', *);
>
> > > > > > I have tried both crud and actions mode, and found that in the long
> > > > > > run it is much easier to manage crud mode, due to the reduced number
> > > > > > of ACO nodes.
>
> > > > > > -Aran
>
> > > > > > On May 27, 3:04 am, dmadruga <[EMAIL PROTECTED]> wrote:
>
> > > > > > > Hi folks!
> > > > > > > I'm trying to come up with a descent schema for the ACL of a
> > > > > > > tennis
> > > > > > > association website.
> > > > > > > Basically there are several tennis clubs, each club has several
> > > > > > > regular members and a committee of 3 to 5 members responsible for
> > > > > > > managing the club and accepting/rejecting new members. One person
> > > > > > > may
> > > > > > > be a member of several clubs, and may be in different positions in
> > > > > > > each one (for ex: Tom's a member of the club's X committee and a
> > > > > > > regular member of the club Y).
> > > > > > > The web system will centralize the management of all the clubs
> > > > > > > related
> > > > > > > to the association.
> > > > > > > A Guest will be allowed to sign up to the association and become a
> > > > > > > Member.
> > > > > > > A Member will be allowed to join a club.
> > > > > > > A Member of the committee will be allowed to edit information
> > > > > > > related
> > > > > > > to his club, approve/reject new members requests, among other
> > > > > > > operations.
> > > > > > > As soon as a new member is accepted to a club he'll be able to
> > > > > > > view
> > > > > > > information related to this club, post messages in the club's
> > > > > > > forum,
> > > > > > > and so on...
>
> > > > > > > The ACL schema that first came to my mind was something like this:
>
> > > > > > > _AROs_
> > > > > > > Admin (the group of site admins, those who will have full access
> > > > > > > to
> > > > > > > everything)
> > > > > > > Guests
> > > > > > > Members
> > > > > > > ---> Bob
> > > > > > > ---> Tom
> > > > > > > ---> John
>
> > > > > > > _ACOs_
> > > > > > > create_account (maps to the create_account method in the users
> > > > > > > controller)
> > > > > > > join_club (maps to the join_club method in the clubs controller)
> > > > > > > club
> > > > > > > ---> X
> > > > > > > --- ---> view
> > > > > > > --- ---> edit
> > > > > > > --- ---> delete
> > > > > > > --- ---> approve_member
> > > > > > > --- ---> post_forum
> > > > > > > --- ---> remove_member
> > > > > > > ---> Y
> > > > > > > --- ---> view
> > > > > > > --- ---> edit
> > > > > > > ...
> > > > > > > --- ---> remove_member
> > > > > > > ---> Z
> > > > > > > ...
>
> > > > > > > (X, Y, and Z are the clubs).
>
> > > > > > > As far as I understood I'll be able to allow an specific user (say
> > > > > > > Bob) to perform an specific operation (say club/Y/approve_member).
> > > > > > > Am I wrong?
> > > > > > > Then, in the method that performs this operation I can check if
> > > > > > > Bob
> > > > > > > (the logged user) is allowed to perform the operation for the
> > > > > > > current
> > > > > > > club (say .../clubs/approve_member/<club_id>).
> > > > > > > Right?
>
> > > > > > > I also though about creating a different ARO group for each club,
> > > > > > > but
> > > > > > > the problem I found is that I can't associate a Member to more
> > > > > > > than
> > > > > > > one group. I could create a new ARO each time a member joins a
> > > > > > > club,
> > > > > > > but it seems to me more complex than the previous solution. Am I
> > > > > > > wrong?
>
> > > > > > > The last thing... I'm using the Auth component and I realized
> > > > > > > that it
> > > > > > > has a strong interaction with the ACL component. If I use this
> > > > > > > non-
> > > > > > > standard approach to construct my ACL will I mess Auth's work?
>
> > > > > > > Thanks a lot!!!
> > > > > > > Daniel Madruga.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
