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
-~----------~----~----~----~------~----~------~--~---
