Re: Going back to school: ACL

[zuha]

Hey Eric, 
Not sure what else I could explain other than posting some code (which 
isn't 100% tested quite yet).  Basically we use prefix routing just to get 
the $this->request->params['prefix'] variable filled, then reroute getting 
rid of the prefix from the method.  (a call which would normally go to 
admin_index()  becomes a a call to index() method)  

If you want more info, I would suggest starting a new thread with a 
question, because it would steer this original post way too far off topic.  

-- 
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+unsubscr...@googlegroups.com For more options, visit this group at 
http://groups.google.com/group/cake-php

Re: Going back to school: ACL

[alaxos]

You're welcome Eric ! :-)

As I wrote above, I think it worths to dive into ACL, even if it has
some limitations. But it was also immediately obvious to me that it
would be usable only with a graphical interface to manage the
permissions. That was the reason to write this plugin. And it is
probably obvious to many other users of ACL, since the plugin has been
downloaded many thousands of times since it is online.

Regarding a CakePHP 2.0 version, it is already available here:
http://www.alaxos.net/blaxos/posts/view/20 The reason to be still in
'beta' is that I haven't used it a lot so far. But it has been
downloaded a few tens of times already, and it seems to work quite
well. Feel free to try it and give me a feedback.


On Oct 30, 11:35 am, Eric Blanpied  wrote:
> Jeremy,
>
> 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  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
> >  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.organdhelp 
> >> > others with their CakePHP related questions.
>
> >> > To unsubscribe fr

Re: Going back to school: ACL

[rchavik]

On Friday, October 28, 2011 4:08:42 PM UTC+7, alaxos wrote:
>
> As far as I know, the core ACL does not support multiple groups per 
> user. 
>

I believe ticket 
770has
 some discussion about this and a patch for 1.3.  However, I don't think 
that patch addresses the requirement where a user changes their group 
within a session.

-- 
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+unsubscr...@googlegroups.com For more options, visit this group at 
http://groups.google.com/group/cake-php

Re: Going back to school: ACL

[Eric Blanpied]

Jeremy,

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  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
>  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+unsubscr...@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+unsubscr...@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+unsubscr...@googlegroups.com For more options, visit this group at 
http://groups.google.com/group/

Re: Going back to school: ACL

[alaxos]

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
 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+unsubscr...@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+unsubscr...@googlegroups.com For more options, visit this group at 
http://groups.google.com/group/cake-php

Re: Going back to school: ACL

[zuha]

Ha you've hit pretty close to a change I've made in the way Cake works in 
order to address the prefix in what I think is a better way.  In our app we 
keep prefix routing but get rid of the method routing.  So we still get the 
$this->params->params['prefix'] but route the user to the index() method 
instead of the admin_index() method.   We then leave it up to ACL 
completely to decide whether your role has access to the index function.   
This allows us to get rid of 50% of the view files and 50% of the 
controller methods. 

We can have different views for different user roles in that we assign view 
prefixes to user roles.  So we can have an admin view, and all users in the 
admin user role would see /Posts/View/Posts/admin/index.ctp instead of 
/Posts/View/Posts/index.ctp if and only if the admin view exists.  We could 
do the same thing for managers, users, etc, and leave it up to each app to 
decide whether managers would see the admin view or the manager view or the 
guest view. 

-- 
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+unsubscr...@googlegroups.com For more options, visit this group at 
http://groups.google.com/group/cake-php

Re: Going back to school: ACL

[Jeremy Burns | Class Outfit]

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 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+unsubscr...@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+unsubscr...@googlegroups.com For more options, visit this group at 
http://groups.google.com/group/cake-php

Re: Going back to school: ACL

[zuha]

#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 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+unsubscr...@googlegroups.com For more options, visit this group at 
http://groups.google.com/group/cake-php

Going back to school: ACL

[Jeremy Burns]

I have never implemented ACL in a CakePHP app. Not sure why; partly
because I never really took the time to get it, partly because the
control freak in me comes out (I can see the permissions code I write
but [because of my lack of understanding] the ACL and its tables are
dark) and partly because what I already do works. So I've taken the
time to go through the 2.0 tutorial to try and make that leap. I get
how it works but I have a couple of (possibly dumb) conceptual
questions because, right now, I am still not convinced.

(1) A user is in a Group. ACL can define permissions for that Group
and even to that user. How is this different to using prefix routing
where you can test for the presence of the prefix and membership of
the group?

(2) What if permissions are role based and a user can be in more than
one group? For example, a user can be a teacher, and a board member
(not all board members are teachers and not all teachers are board
members) and maybe even a student too. Their interaction with the app
'at that time' defines the role you should be checking for. I can see
how I'd program that; can I do many-to-many users-groups in ACL? How
would that work? If the answer is to apply individual permissions to
users, that's a lot of admin on a large system.

(3) By checking permissions against a database, is there not a
(however small) performance hit with the extra db query that is not
needed when permissions are defined in code?

Don't leap all over me for asking stoopid questions because I bet I
have asked what others are thinking! Sell me ACL!

-- 
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+unsubscr...@googlegroups.com For more options, visit this group at 
http://groups.google.com/group/cake-php