Re: ACL, Auth, and terminology.
Yes, a scenerio where User HABTM Role you'd have to iterate through all the roles, but this can be cached once the user logs in. Once the user is logged in, they would have a cached list of areas they have access to. I don't see that is too much of a problem. I think a system can become extremely more flexible by having roles and groups. A question many people always have when reading those ACL tutorials is... "How do I make it so a user only edits his own post"? or "How do I make it so a user only edits certain posts"? This is where groups would come in. The user would belong to a group and whatever rights the group has for an object, then the user has those rights too. By also having roles, it also creates a hierarchy of user access rights. John as a "manager"(role) and member of the group "Yellow Team" has the right to create, edit, delete posts AND moderate comments. Bill as a "contributer" (role) and member of the group "Yellow Team" may only have the right to create, edit, and delete posts. If Bill tries to access /posts/moderate_comments/25/, then he will be denied.. even if he has access to the resource Post.25. On Jun 11, 6:01 am, Michał wrote: > On 11 Cze, 08:58, CMNAJS wrote: > > > But Why we need roles and groups both? Isn't either of them is > > enough.. and fulfill the requirement.. > > As We can have users under groups in AROs and assign certain ACOs to a > > group so that the usres of that group have access to those ACOs.. > > IMO there's one problem with both of these approaches. Having a User > HABTM Role would require to iterate through all Roles the user has to > determine if the Role has access. > The User as ARO approach has another problem - you can't have a User > in multiple Groups, thus you can't have a User be 'Post Admin' _and_, > say, 'Comment Admin'. You have to either create a separate group 'Post > and Comment Manager' or assign permissions directly to the user. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com 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?hl=en -~--~~~~--~~--~--~---
Re: ACL, Auth, and terminology.
Well, I see a difference between roles and groups and therefore I think it would actually be easier to separate them. Roles are very basic and only define the user's "level" of access. ie: the areas the user can access. Groups, however, can be more informative. They are not only an entity which has many objects, but depending on your application, they can be an entity other users interact with. For example, you may have feature where users can become "fans" or "friends" of the group "Yellow Team". "Yellow Team" may have it's own profile, avatar, etc. I don't see the same type of functionality being defined for roles. Thus, I think it's actually more clearer and simple to make the distinction between the two. On Jun 11, 2:58 am, CMNAJS wrote: > That makes things bit clear.. > > But Why we need roles and groups both? Isn't either of them is > enough.. and fulfill the requirement.. > As We can have users under groups in AROs and assign certain ACOs to a > group so that the usres of that group have access to those ACOs.. > > What you think?? > > And I am a bit worried about the management of all this... > Any idea for simplicity --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com 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?hl=en -~--~~~~--~~--~--~---
Re: ACL, Auth, and terminology.
On 11 Cze, 08:58, CMNAJS wrote: > But Why we need roles and groups both? Isn't either of them is > enough.. and fulfill the requirement.. > As We can have users under groups in AROs and assign certain ACOs to a > group so that the usres of that group have access to those ACOs.. IMO there's one problem with both of these approaches. Having a User HABTM Role would require to iterate through all Roles the user has to determine if the Role has access. The User as ARO approach has another problem - you can't have a User in multiple Groups, thus you can't have a User be 'Post Admin' _and_, say, 'Comment Admin'. You have to either create a separate group 'Post and Comment Manager' or assign permissions directly to the user. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com 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?hl=en -~--~~~~--~~--~--~---
Re: ACL, Auth, and terminology.
That makes things bit clear.. But Why we need roles and groups both? Isn't either of them is enough.. and fulfill the requirement.. As We can have users under groups in AROs and assign certain ACOs to a group so that the usres of that group have access to those ACOs.. What you think?? And I am a bit worried about the management of all this... Any idea for simplicity --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com 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?hl=en -~--~~~~--~~--~--~---
Re: ACL, Auth, and terminology.
To expand on this, the relations would look like this: User belongs to Group and Role (you can to HABTM, but lets keep it simple) Both Group and Role are AROs ACOs can either be areas (/posts/index/) or resources (Post.232 + CRUD permission) When a user access the following area - /posts/edit/232/ the following would happen 1) Does this user belong to a role that allows him/her to be here? If No - STOP, else proceed 2) Does the user belong to a group that allows him to edit this resource? If no - STOP, else proceed. Yay or nay? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com 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?hl=en -~--~~~~--~~--~--~---
ACL, Auth, and terminology.
I've read a few CakePHP ACL + Auth tutorials online and they all seem to use the terms "groups" when they should really be using "roles". Maybe I'm not understanding ACL correctly, but the way I see it being used is to allow/deny access to certain areas (as opposed to records). To me, the term "role" is more appropriate for this usage of ACL. I understand ACL can be used as both Model and Controller level, but I rarely see it used at the model level and when being used at the control level it's making use of the term groups. The term group, should be used the way unix uses it, to mean what resources you have access too. Example : Jim has the role "Manager" and belongs to the group "Yellow Team" Jim, as a manager, can add, edit, and delete posts. Joe is also a member of the "Yellow Team" group and therefore has access to all objects/records that belong to this group. To me this makes more sense. A role defines areas you have access to and group is something that a bunch of objects/records belongs to. Thoughts? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com 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?hl=en -~--~~~~--~~--~--~---
