I've done a number of cakephp apps (1.1, 1.2, 1.3 - starting a 2.0,
too), and have also always been flummoxed by ACL and gone back to my
own code to deal with it. A current project (1.3) has *lots* of roles,
however, including enough overlap that a many-many groups-users setup
seemed like what I wanted. I persevered with ACLs this time, though,
and I'm ending up glad that I did. As others have said, pulling access
control out of most of the code is very, very nice, and the
flexibility to add new roles with mixed degrees of access via the
database is great. I'm experimenting with hierarchical groups to
handle some of the overlap (add a parent_id to your groups table).
One thing that's helped me is Alaxos' acl plugin (thanks, nIcO!) -
while it doesn't map to what I'm doing exactly, having some tools to
manage the tables is vital, and I'm sure glad I didn't have to write
any myself. One thing I'm curious about, nIcO, is the 2.0 story for
your plugin.
Zuha, can you explain a bit further about mixing prefix routing with
ACLs? Our setup is currently still using admin_ prefixes, but as far
as I can tell that's pretty redundant here, unless it could provide a
second angle of access control.
Thanks, everyone!
-eric
On Fri, Oct 28, 2011 at 11:08 AM, alaxos <alaxos@gmail.com> wrote:
> Hi Jeremy,
>
> As far as I know, the core ACL does not support multiple groups per
> user.
>
> Before using ACL, I used myself a home made component that allowed to
> grant/deny access based on roles membership and action prefixes like
> you do. It used to work :-) and it also supported many-to-many users-
> groups. But since I have changed my habit, and I now use ACL. As
> mentionned by zuha, I prefer the idea to have the possibility to grant/
> deny specific permission to someone or some people without having to
> update the code. Even if it now does not support many-to-many users-
> groups anymore, I think it is more flexible. But I also have to admit
> that I never developped an application with a lot of different
> profiles (so far 4-5 max).
>
> nIcO
>
> On Oct 27, 6:48 pm, Jeremy Burns | Class Outfit
> <jeremybu...@classoutfit.com> wrote:
>> Thanks Richard.
>>
>> Your point about flexibility and extensibility is a good one. You'd define specific views to do specific functions and then restrict them with permissions rather than a prefix. That also means one view can be used by more than one group (although I guess you could equally do that with $this->render).
>>
>> My second question is the one that puzzles me most. I've designed some systems where this is very typical; members of staff are department heads, managers, subordinates, team members, committee members and so on. So one person changes his role (group) throughout a single session. I'd be interested to see what others have to say too.
>>
>> I have some SQL that could speed up the acl table reads if you are using Innodb.
>>
>> Jeremy Burns
>> Class Outfit
>>
>> http://www.classoutfit.com
>>
>> On 27 Oct 2011, at 17:32, zuha wrote:
>>
>>
>>
>>
>>
>>
>>
>> > #1 : Would require a prefix for every role. admin_index, manager_index, user_index, guest_index, etc. With ACL being database driven you can have unlimited user roles and not be required to add new prefixes every time you add a role.
>>
>> > #2 : I don't know, interesting question. It sounds kind of a-typical to me though. You would probably add a 3rd group in that rare case called something like, "board-teachers".
>>
>> > #3 : Yes and its not small. It can be large and a major slow down.
>>
>> > ACL is very flexible but the flexibility comes with the downside of speed performance. I'm quite sure there are caching solutions to get around it, but I have not gotten that far yet (even after 2 years of using ACL extensively).
>>
>> > --
>> > Our newest site for the community: CakePHP Video Tutorialshttp://tv.cakephp.org
>> > Check out the new CakePHP Questions sitehttp://ask.cakephp.organd help others with their CakePHP related questions.
>>
>> > To unsubscribe from this group, send email to
>> > cake-php+unsubscribe@googlegroups.com For more options, visit this group athttp://groups.google.com/group/cake-php
>
> --
> Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
> Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
>
>
> To unsubscribe from this group, send email to
> cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php
>
--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php
No comments:
Post a Comment