Problem with deny deletion when using ACL
I entered the ACL recipe in the "CakePHP 1.3 Application Development Cookbook". I have a user "andy" belonging to a group "user" and I have a category table on which I try to deny delete and update: cake acl create aco controllers Categories cake acl deny Group.3 controllers/Categories delete cake acl deny Group.3 controllers/Categories update "Group.3" is the plain "user" group and has an entry on the ARO table. However when I log on as the user andy and go to the URL localhost/ blogtest/delete/7 for example the delete is allowed. Do I need to add any code to the Categories files? What am I missing? Thanks. -- 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: Using Acl on plugins HOWTOs
Hi Bryan, This won't answer your question precisely, as I'm not sure where you can find such a tutorial, but I have written a plugin that may help you in your application: it is a plugin that allows to manage ACL roles and users permissions on controllers' actions. And it supports plugins' controllers as well (see at the bottom of the roles' permissions list in the demo). If interested, you can find it here: http://www.alaxos.net/blaxos/pages/view/plugin_acl nIcO On 16 sep, 22:08, Bryan de Asis wrote: > Hello, > > Is there any tutorial the can teach us to use the acl to set > permissions to plugins? > > Let say... > > Role 1 > Role 2 > > Role1 access > - plugin 1 > - plugin 1 / controller 1 > - plugin 1 / controller 1 / action 1 > - plugin 1 / controller 1 / action 2 > - plugin 1 / controller 2 / action 1 > - plugin 1 / controller 2 / action 2 > > - plugin 2 > - plugin 2 / controller 1 > - plugin 2 / controller 1 / action 1 > - plugin 2 / controller 1 / action 2 > - plugin 2 / controller 2 / action 1 > - plugin 2 / controller 2 / action 2 > > - plugin 3 > - plugin 3 / controller 1 > - plugin 3 / controller 1 / action 1 > - plugin 3 / controller 1 / action 2 > - plugin 3 / controller 2 / action 1 > - plugin 3 / controller 2 / action 2 > > Role 2 access > - plugin 1 > - plugin 1 / controller 1 > - plugin 1 / controller 1 / action 1 > - plugin 1 / controller 2 / action 2 > > - plugin 3 > - plugin 3 / controller 1 > - plugin 3 / controller 1 / action 1 > - plugin 3 / controller 2 / action 1 > - plugin 3 / controller 2 / action 2 > > anyone can help me... please i need your help... i'm creating a > scalable app.. > > Thanks, > > Bryan Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. 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
Using Acl on plugins HOWTOs
Hello, Is there any tutorial the can teach us to use the acl to set permissions to plugins? Let say... Role 1 Role 2 Role1 access - plugin 1 - plugin 1 / controller 1 - plugin 1 / controller 1 / action 1 - plugin 1 / controller 1 / action 2 - plugin 1 / controller 2 / action 1 - plugin 1 / controller 2 / action 2 - plugin 2 - plugin 2 / controller 1 - plugin 2 / controller 1 / action 1 - plugin 2 / controller 1 / action 2 - plugin 2 / controller 2 / action 1 - plugin 2 / controller 2 / action 2 - plugin 3 - plugin 3 / controller 1 - plugin 3 / controller 1 / action 1 - plugin 3 / controller 1 / action 2 - plugin 3 / controller 2 / action 1 - plugin 3 / controller 2 / action 2 Role 2 access - plugin 1 - plugin 1 / controller 1 - plugin 1 / controller 1 / action 1 - plugin 1 / controller 2 / action 2 - plugin 3 - plugin 3 / controller 1 - plugin 3 / controller 1 / action 1 - plugin 3 / controller 2 / action 1 - plugin 3 / controller 2 / action 2 anyone can help me... please i need your help... i'm creating a scalable app.. Thanks, Bryan Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. 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: using ACL in model
I think that would best be left to the controller. Think of what the C in ACL stands for. To avoid repeating code, create a protected method _changeStatus() and check there if the User is allowed. On Mar 8, 3:39 pm, sawa wrote: > Hi, > I was wondering if it's possible to use ACL in model instead of the > controller. > Let's say I have fat models and I have model method change_status. > Now, in my controllers I may invoke $mymodel->change_status on couple > of places and I don't want to check if user is authorized to do > change_status everywhere. Instead of that I want to check if user is > authorized in the model, so when I invoke that method in my > controllers I don't have to worry about forgetting to check user > privileges for that operation. > > Any ideas? Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. 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
using ACL in model
Hi, I was wondering if it's possible to use ACL in model instead of the controller. Let's say I have fat models and I have model method change_status. Now, in my controllers I may invoke $mymodel->change_status on couple of places and I don't want to check if user is authorized to do change_status everywhere. Instead of that I want to check if user is authorized in the model, so when I invoke that method in my controllers I don't have to worry about forgetting to check user privileges for that operation. Any ideas? Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. 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: Using ACL in View?
Similiar to what I had in mind, thanks for the input nevertheless :) *thumbs up* Jacek Stinkbug pisze: > I believe the proper MVC way to do it is to do the check in your > controller and set the variables for you view. So in your controller > you might have something like this: > > if ($this->Acl->check(your acl info)) { > $this->set('admin', true); > } > > Then in your view you would simple check the $admin variable: > > if ($admin) { > You html content. > } > > Hope that helps. > > On Apr 6, 4:20 am, Faza wrote: > >> Hello all, >> >> just happily finished setup of group-based ACL in my app, thanks to >> brilliant tutorial on Cake site. >> >> Nevertheless, despite looking around I haven't found any way (known to a >> noob like me) to use a function similiar to $this->Acl->check() in View, >> for, say, hiding certain sections of webpage to non-admin users or >> anything like that. I know, I could do it by saving users group in >> session and checking it in View, but I'm curious if there's some cake >> way to do it. >> >> Thanks! >> >> Regards >> Jacek >> > > > > --~--~-~--~~~---~--~~ 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: Using ACL in View?
I believe the proper MVC way to do it is to do the check in your controller and set the variables for you view. So in your controller you might have something like this: if ($this->Acl->check(your acl info)) { $this->set('admin', true); } Then in your view you would simple check the $admin variable: if ($admin) { You html content. } Hope that helps. On Apr 6, 4:20 am, Faza wrote: > Hello all, > > just happily finished setup of group-based ACL in my app, thanks to > brilliant tutorial on Cake site. > > Nevertheless, despite looking around I haven't found any way (known to a > noob like me) to use a function similiar to $this->Acl->check() in View, > for, say, hiding certain sections of webpage to non-admin users or > anything like that. I know, I could do it by saving users group in > session and checking it in View, but I'm curious if there's some cake > way to do it. > > Thanks! > > Regards > Jacek --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Using ACL in View?
Hello all, just happily finished setup of group-based ACL in my app, thanks to brilliant tutorial on Cake site. Nevertheless, despite looking around I haven't found any way (known to a noob like me) to use a function similiar to $this->Acl->check() in View, for, say, hiding certain sections of webpage to non-admin users or anything like that. I know, I could do it by saving users group in session and checking it in View, but I'm curious if there's some cake way to do it. Thanks! Regards Jacek --~--~-~--~~~---~--~~ 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: Using ACL
if there's only one type of users e.g. admin and you just check wether user is logged in, then Auth is enough for you. On Feb 25, 7:16 pm, "Dave Maharaj :: WidePixels.com" wrote: > I want to setup a site where there are 2 authorized pages and what to know > what the best approach would be? To use the ACL and Auth component or just > Auth. > > The site is pretty basic with 2 core pages: > > User/Profile: where users can view/edit their profile when logged in > Posts: where logged in users can view/edit(their own post)/add posts > > Because of the simplicity is it best to just use Auth? > > Thanks, > Dave --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Using ACL
I want to setup a site where there are 2 authorized pages and what to know what the best approach would be? To use the ACL and Auth component or just Auth. The site is pretty basic with 2 core pages: User/Profile: where users can view/edit their profile when logged in Posts: where logged in users can view/edit(their own post)/add posts Because of the simplicity is it best to just use Auth? Thanks, Dave --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Using Acl component inside a model
Hi there, I've been investigating the skinny-controller, fat-model concept within the CakePHP framework and wondering what the general thoughts are to using ACL components inside a model. In my particular setup, when a record is created (let's call it Book) the associated chapters that reside in another table are also created. >From this, I would have put the Chapter creation in the afterSave() callback on the Book model. But when creating the Chapter records, I also need to assign the permissions to the chapters. Putting the permission code ($this->Acl->allow(...)) into the controller seems like separating code that's too closely linked together. I've had various ideas, but nothing seems to feel right! Any feedback would be appreciated. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~--~~~~--~~--~--~---
Re: Dynamic parentID() when using ACL
Thanks for your reply, Your description would enable people to work; however, if I have understood correctly, it relies on specifying permissions for individual users to override group permissions. This rather seems to me to then lose a lot of the advantage of using ACL. My original question was posing a possible solution (or possibly a harebrained idea, I don't understand the underlying specifics enough) which would 'trick' the group mechanism by returning different parentIDs depending on what was most relevant at a particular time. Benjamin PS: I am also following http://groups.google.com/group/cake-php/browse_thread/thread/62178b38e2466286, which is obviously along similar lines. On Feb 12, 1:27 am, aranworld <[EMAIL PROTECTED]> wrote: > Sorry, I posted that too early. Let me try again: > > When Auth checks the Acl tables to give permission, it is using an > Alias based on the Controller/action pair -- if you are using Auth > under 'actions' mode. > > Under 'crud' mode, it checks for an alias using just the Controller > name. > > Thus, for each forum, you are going to be required to create unique > Controller/action strings. For example, for the part where people > talk about cars, your aliases might look like this: > > CarEnthusiastForum > -- add > -- edit > -- delete > -- index > > For the Television forum > > TVFansForum > -- add > -- edit > -- delete > -- index > > With such a setup, it then becomes quite easy to just give the admin > of the Car Forum all permissions to the CarEnthusiastForum controller, > but only give him member permissions on the TVFansForum controller. > > Obviously you might have a more complex set of controllers > ( CarForumPosts, CarForumTopics etc... ), but the basic idea is that > each forum is going to have to have a unique set of controllers for > this to work. > > On Feb 11, 3:15 pm, aranworld <[EMAIL PROTECTED]> wrote: > > > When Auth checks the Acl tables to give permission, it is using an > > Alias based on the Controller/action pair. > > > Thus, for each forum, you are going to be required to create unique > > Controller/action strings. For example, for the part where people > > talk about cars, your aliases might look like this: > > > CarEnthusiastForum > > add > > CarEnthusiastForum/edit > > CarEnthusiastForum/delete > > CarEnthusiastForum/index > > > On Feb 11, 6:18 am, boyracerr <[EMAIL PROTECTED]> wrote: > > > > Hello to all, > > > > I am keen to use ACL in my application. However, the requirement that > > > users only be in one group seems to me to be a massive obstacle. > > > > As an example, imagine there is a bulletin board application with many > > > forums. Each forum will have members, moderators and administrators. > > > An administrator in one group may be only a member of another group > > > and so on. > > > > I thought up a possible solution to the above, and I would appreciate > > > comments. As I understand it, tree navigation (and thus cascading > > > permissions) is implemented using the parentID() function, implemented > > > in the relevant model. > > > > Would it be possible to write the parentID() function such that it > > > returned a different parentID depending on the current location in the > > > site. > > > > For example: > > > > User visits Forum1. He is only a member of this forum. parentID() > > > knows that he is visiting that particular forum, and thus returns > > > Forum1.members as the relevant parent group. > > > > User visits Forum2. He is an administrator of this forum. parentID(), > > > based on the forum being viewed, returns Forum2.admins as the relevant > > > parent group. > > > > Comments on the above? Would it work? Would it solve this problem? > > > > Thanks, > > > Benjamin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Dynamic parentID() when using ACL
Sorry, I posted that too early. Let me try again: When Auth checks the Acl tables to give permission, it is using an Alias based on the Controller/action pair -- if you are using Auth under 'actions' mode. Under 'crud' mode, it checks for an alias using just the Controller name. Thus, for each forum, you are going to be required to create unique Controller/action strings. For example, for the part where people talk about cars, your aliases might look like this: CarEnthusiastForum -- add -- edit -- delete -- index For the Television forum TVFansForum -- add -- edit -- delete -- index With such a setup, it then becomes quite easy to just give the admin of the Car Forum all permissions to the CarEnthusiastForum controller, but only give him member permissions on the TVFansForum controller. Obviously you might have a more complex set of controllers ( CarForumPosts, CarForumTopics etc... ), but the basic idea is that each forum is going to have to have a unique set of controllers for this to work. On Feb 11, 3:15 pm, aranworld <[EMAIL PROTECTED]> wrote: > When Auth checks the Acl tables to give permission, it is using an > Alias based on the Controller/action pair. > > Thus, for each forum, you are going to be required to create unique > Controller/action strings. For example, for the part where people > talk about cars, your aliases might look like this: > > CarEnthusiastForum > add > CarEnthusiastForum/edit > CarEnthusiastForum/delete > CarEnthusiastForum/index > > On Feb 11, 6:18 am, boyracerr <[EMAIL PROTECTED]> wrote: > > > Hello to all, > > > I am keen to use ACL in my application. However, the requirement that > > users only be in one group seems to me to be a massive obstacle. > > > As an example, imagine there is a bulletin board application with many > > forums. Each forum will have members, moderators and administrators. > > An administrator in one group may be only a member of another group > > and so on. > > > I thought up a possible solution to the above, and I would appreciate > > comments. As I understand it, tree navigation (and thus cascading > > permissions) is implemented using the parentID() function, implemented > > in the relevant model. > > > Would it be possible to write the parentID() function such that it > > returned a different parentID depending on the current location in the > > site. > > > For example: > > > User visits Forum1. He is only a member of this forum. parentID() > > knows that he is visiting that particular forum, and thus returns > > Forum1.members as the relevant parent group. > > > User visits Forum2. He is an administrator of this forum. parentID(), > > based on the forum being viewed, returns Forum2.admins as the relevant > > parent group. > > > Comments on the above? Would it work? Would it solve this problem? > > > Thanks, > > Benjamin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Dynamic parentID() when using ACL
When Auth checks the Acl tables to give permission, it is using an Alias based on the Controller/action pair. Thus, for each forum, you are going to be required to create unique Controller/action strings. For example, for the part where people talk about cars, your aliases might look like this: CarEnthusiastForum add CarEnthusiastForum/edit CarEnthusiastForum/delete CarEnthusiastForum/index On Feb 11, 6:18 am, boyracerr <[EMAIL PROTECTED]> wrote: > Hello to all, > > I am keen to use ACL in my application. However, the requirement that > users only be in one group seems to me to be a massive obstacle. > > As an example, imagine there is a bulletin board application with many > forums. Each forum will have members, moderators and administrators. > An administrator in one group may be only a member of another group > and so on. > > I thought up a possible solution to the above, and I would appreciate > comments. As I understand it, tree navigation (and thus cascading > permissions) is implemented using the parentID() function, implemented > in the relevant model. > > Would it be possible to write the parentID() function such that it > returned a different parentID depending on the current location in the > site. > > For example: > > User visits Forum1. He is only a member of this forum. parentID() > knows that he is visiting that particular forum, and thus returns > Forum1.members as the relevant parent group. > > User visits Forum2. He is an administrator of this forum. parentID(), > based on the forum being viewed, returns Forum2.admins as the relevant > parent group. > > Comments on the above? Would it work? Would it solve this problem? > > Thanks, > Benjamin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Dynamic parentID() when using ACL
Hello to all, I am keen to use ACL in my application. However, the requirement that users only be in one group seems to me to be a massive obstacle. As an example, imagine there is a bulletin board application with many forums. Each forum will have members, moderators and administrators. An administrator in one group may be only a member of another group and so on. I thought up a possible solution to the above, and I would appreciate comments. As I understand it, tree navigation (and thus cascading permissions) is implemented using the parentID() function, implemented in the relevant model. Would it be possible to write the parentID() function such that it returned a different parentID depending on the current location in the site. For example: User visits Forum1. He is only a member of this forum. parentID() knows that he is visiting that particular forum, and thus returns Forum1.members as the relevant parent group. User visits Forum2. He is an administrator of this forum. parentID(), based on the forum being viewed, returns Forum2.admins as the relevant parent group. Comments on the above? Would it work? Would it solve this problem? Thanks, Benjamin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
using ACL without model
Hi guys I'm working on a project using an API instead of models. basically, my cakephp app query the database through the API instead of doing it directly through models. Now i'd like to setup cakephp ACL to manage rights. do you know if it's possible to do this whithout model ? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using Acl to display a user-specific menu
On Jan 17, 1:47 am, Luke <[EMAIL PROTECTED]> wrote: > like 3 different menu.ctp files (menu-admin.ctp, menu-manager.ctp, and > menu-default.ctp) ? Yes, thats what AD7six meant. :-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using Acl to display a user-specific menu
like 3 different menu.ctp files (menu-admin.ctp, menu-manager.ctp, and menu-default.ctp) ? On Jan 16, 2:47 pm, AD7six <[EMAIL PROTECTED]> wrote: > On Jan 16, 11:13 pm, Luke <[EMAIL PROTECTED]> wrote: > > > I am writing an application that has three user groups: admin, user, > > and photo manager. I want all three to have basically the same > > interface, but admins will obviously have more things available to > > them (ability to add things, edit things, etc), photo managers will be > > allowed to add / edit photos, and all users will be able to view just > > about anything in the system. I'm just wondering what the best way to > > go about displaying the menu to my uses is. Should I run a > > beforeFilter in my AppController that grabs all the user's permissions > > and stores them in the session? Then I could check the session to know > > what parts of the menu to display. Is this a good idea? If not, why? > > What would you do? > > I did that a long time ago on a small scale, result: awful > performance. > > Probably better to define, in whatever way suits you best, the 3 > permutations in separate elements and add logic to render the right > one. > > hth, > > AD --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using Acl to display a user-specific menu
On Jan 16, 11:13 pm, Luke <[EMAIL PROTECTED]> wrote: > I am writing an application that has three user groups: admin, user, > and photo manager. I want all three to have basically the same > interface, but admins will obviously have more things available to > them (ability to add things, edit things, etc), photo managers will be > allowed to add / edit photos, and all users will be able to view just > about anything in the system. I'm just wondering what the best way to > go about displaying the menu to my uses is. Should I run a > beforeFilter in my AppController that grabs all the user's permissions > and stores them in the session? Then I could check the session to know > what parts of the menu to display. Is this a good idea? If not, why? > What would you do? I did that a long time ago on a small scale, result: awful performance. Probably better to define, in whatever way suits you best, the 3 permutations in separate elements and add logic to render the right one. hth, AD --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using Acl to display a user-specific menu
Correction: "I'm just wondering what the best way to go about displaying the menu to my uses is" should read: I'm just wondering what the best way to go about displaying the menu to my users is. On Jan 16, 2:13 pm, Luke <[EMAIL PROTECTED]> wrote: > I am writing an application that has three user groups: admin, user, > and photo manager. I want all three to have basically the same > interface, but admins will obviously have more things available to > them (ability to add things, edit things, etc), photo managers will be > allowed to add / edit photos, and all users will be able to view just > about anything in the system. I'm just wondering what the best way to > go about displaying the menu to my uses is. Should I run a > beforeFilter in my AppController that grabs all the user's permissions > and stores them in the session? Then I could check the session to know > what parts of the menu to display. Is this a good idea? If not, why? > What would you do? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Using Acl to display a user-specific menu
I am writing an application that has three user groups: admin, user, and photo manager. I want all three to have basically the same interface, but admins will obviously have more things available to them (ability to add things, edit things, etc), photo managers will be allowed to add / edit photos, and all users will be able to view just about anything in the system. I'm just wondering what the best way to go about displaying the menu to my uses is. Should I run a beforeFilter in my AppController that grabs all the user's permissions and stores them in the session? Then I could check the session to know what parts of the menu to display. Is this a good idea? If not, why? What would you do? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Error 404 when using ACL $aro->create
Hello, i am trying the IBM tutorial no 2 and have a problem, when using the function $aro->create(...) in my register action. After clicking the "register" button, I get an Error 404. If I comment out the $aro->create() the redirect is successful. Here's the code: class UsersController extends AppController { var $components = array('Acl'); function register() { $this->set('username_error', 'Username must be between 6 and 40 characters.'); if(!empty($this->data)){ if($this->User->validates($this->data)){ if($this->User->findByUsername($this->data['User']['username'])) { $this->User->invalidate('username'); $this->set('username_error', 'User already exists.'); } else { $this->data['User']['password'] = md5($this->data['User'] ['password']); $this->data['User']['last_login'] = date("Y-m-d H:i:s"); if($this->User->save($this->data)){ $aro = new Aro(); //$user_id = $this->User->getLastInsertID(); $aro->create($this->User->id, 'Users', $this->data['User'] ['username']); $this->Session->write('user', $this->data['User']['username']); $this->Session->write('last_login', 'You are logged in first time'); $this->redirect('/users/index'); } else { $this->flash('There was a problem saving this information', '/ users/register'); } } } else { $this->User->validateErrors($this->User); } } } function knownusers() { $this->set('knownusers', $this->User->findAll(null, array('id', 'username', 'first_name', 'last_name', 'last_login'), 'id DESC')); } function login(){ $this->set('error', false); if($this->data){ $results = $this->User->findByUsername($this->data['User'] ['username']); if($results && $results['User']['password'] == md5($this- >data['User']['password'])){ $this->Session->write('user', $this->data['User']['username']); $this->Session->write('last_login', $results['User'] ['last_login']); $results['User']['last_login'] = date("Y-m-d H:i:s"); $this->User->save($results); $this->redirect('/users/index'); } else { $this->set('error', true); } } } function logout() { $this->Session->delete('user'); $this->Session->delete('last_login'); $this->redirect('/users/login'); } function index() { $username = $this->Session->read('user'); if($username){ $results = $this->User->findByUsername($username); $this->set('User', $results['User']); $this->set('last_login', $this->Session->read('last_login')); } else { $this->redirect('/users/login'); } } } --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: is anyone using Acl and AuthComponent in 1.2
Hey guys, near as I can tell... ACL is not yet functional in 1.2, unless it was finished in the last release (1.2.0.5137alpha) cook On May 23, 10:09 am, alan <[EMAIL PROTECTED]> wrote: > I am just looking into it for the first time... it would be great to > get a solid tutorial on it on the cakephp site... Perhaps they'll get > to that when 1.2 goes stable. > > thanks, > -alan- > > On May 10, 12:25 pm, Tribastian <[EMAIL PROTECTED]> wrote: > > > On 26 Apr., 07:09, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > > > I was just wondering if anyone is successfully using cakephpAcland > > > the newAuthComponentin 1.2? > > > > If so, could you give us mortals some guidance in setting it up? It > > > looks as thoughAclhas changed significantly from 1.1. > > > > Here is some of what I have managed to peace together so far... > > > > //add theACLcomponent > > > var $components = array('Acl'); > > > > //get the aro model > > > $aro = $this->Acl->Aro; > > > > //create a new aro for User:scook, related to a user in the Users > > > table > > > $aro->create( array('model' => 'User', 'foreign_key' => 2, 'alias' => > > > 'scook') ); > > > > //save the new aro > > > $aro->save(); > > > > //get the aco model > > > $aco = $this->Acl->Aco; > > > > //create an aco for my Clients controller > > > $aco->create( array('foreign_key' => 0, 'alias' => 'Clients') ); > > > > //save the new aco > > > $aco->save(); > > > > //create an aco for the index action of my Clients controller > > > $aco->create( array('parent_id'=>'[id of Client Aco]', 'foreign_key' > > > => 0, 'alias' => 'Index') ); > > > > //save the new aco > > > $aco->save(); > > > > //grant User:scook access to the Clients controller > > > $this->Acl->allow('scook','Clients'); > > > > So now I can accesswww.site.com/clients/index > > > > 1. Is everything I have done so far correct and reasonable? > > > > 2. How do I allow User:scook access to ALL of the Clients > actions, > > > without adding an aco for each action? I have tried using "*" and "/", > > > but no luck. > > > > 3. Can I exclude certain controllers and/or actions from being > > > checked? It seems that if I include theAuthComponent, then every > > > single action is automatically checked. But if the user is not logged > > > in, theaclcheck will deny access to any action (including login). If > > > that is the case, how do I access the login action? > > > > Any insight would be appreciated. > > > > cook > > > Servus, > > > Well i am a newbe, but very interesseted in the ACL component. But i > > could not even get close to what you have already managed. So i wonder > > if you could help me a bit... i loaded the component: > > > var $components = array('Acl'); super > > > then i let cake print out me aktive components: > > > $aro = new Aro(); > > > but in the same time i get a real ugly sql error: > > > Query: startup > > > Warning (512): SQL Error: 1064: You have an error in your SQL syntax; > > check the manual that corresponds to your MySQL server version > > blablabla > > > well if you have any idea what i do wrong, i would be very happy... > > > tribastian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: is anyone using Acl and AuthComponent in 1.2
I am just looking into it for the first time... it would be great to get a solid tutorial on it on the cakephp site... Perhaps they'll get to that when 1.2 goes stable. thanks, -alan- On May 10, 12:25 pm, Tribastian <[EMAIL PROTECTED]> wrote: > On 26 Apr., 07:09, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > > > > I was just wondering if anyone is successfully using cakephpAcland > > the newAuthComponentin 1.2? > > > If so, could you give us mortals some guidance in setting it up? It > > looks as thoughAclhas changed significantly from 1.1. > > > Here is some of what I have managed to peace together so far... > > > //add theACLcomponent > > var $components = array('Acl'); > > > //get the aro model > > $aro = $this->Acl->Aro; > > > //create a new aro for User:scook, related to a user in the Users > > table > > $aro->create( array('model' => 'User', 'foreign_key' => 2, 'alias' => > > 'scook') ); > > > //save the new aro > > $aro->save(); > > > //get the aco model > > $aco = $this->Acl->Aco; > > > //create an aco for my Clients controller > > $aco->create( array('foreign_key' => 0, 'alias' => 'Clients') ); > > > //save the new aco > > $aco->save(); > > > //create an aco for the index action of my Clients controller > > $aco->create( array('parent_id'=>'[id of Client Aco]', 'foreign_key' > > => 0, 'alias' => 'Index') ); > > > //save the new aco > > $aco->save(); > > > //grant User:scook access to the Clients controller > > $this->Acl->allow('scook','Clients'); > > > So now I can accesswww.site.com/clients/index > > > 1. Is everything I have done so far correct and reasonable? > > > 2. How do I allow User:scook access to ALL of the Clients > actions, > > without adding an aco for each action? I have tried using "*" and "/", > > but no luck. > > > 3. Can I exclude certain controllers and/or actions from being > > checked? It seems that if I include theAuthComponent, then every > > single action is automatically checked. But if the user is not logged > > in, theaclcheck will deny access to any action (including login). If > > that is the case, how do I access the login action? > > > Any insight would be appreciated. > > > cook > > Servus, > > Well i am a newbe, but very interesseted in the ACL component. But i > could not even get close to what you have already managed. So i wonder > if you could help me a bit... i loaded the component: > > var $components = array('Acl'); super > > then i let cake print out me aktive components: > > $aro = new Aro(); > > but in the same time i get a real ugly sql error: > > Query: startup > > Warning (512): SQL Error: 1064: You have an error in your SQL syntax; > check the manual that corresponds to your MySQL server version > blablabla > > well if you have any idea what i do wrong, i would be very happy... > > tribastian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: is anyone using Acl and AuthComponent in 1.2
On 26 Apr., 07:09, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > I was just wondering if anyone is successfully using cakephpAcland > the new AuthComponent in 1.2? > > If so, could you give us mortals some guidance in setting it up? It > looks as thoughAclhas changed significantly from 1.1. > > Here is some of what I have managed to peace together so far... > > //add theACLcomponent > var $components = array('Acl'); > > //get the aro model > $aro = $this->Acl->Aro; > > //create a new aro for User:scook, related to a user in the Users > table > $aro->create( array('model' => 'User', 'foreign_key' => 2, 'alias' => > 'scook') ); > > //save the new aro > $aro->save(); > > //get the aco model > $aco = $this->Acl->Aco; > > //create an aco for my Clients controller > $aco->create( array('foreign_key' => 0, 'alias' => 'Clients') ); > > //save the new aco > $aco->save(); > > //create an aco for the index action of my Clients controller > $aco->create( array('parent_id'=>'[id of Client Aco]', 'foreign_key' > => 0, 'alias' => 'Index') ); > > //save the new aco > $aco->save(); > > //grant User:scook access to the Clients controller > $this->Acl->allow('scook','Clients'); > > So now I can accesswww.site.com/clients/index > > 1. Is everything I have done so far correct and reasonable? > > 2. How do I allow User:scook access to ALL of the Clients > actions, > without adding an aco for each action? I have tried using "*" and "/", > but no luck. > > 3. Can I exclude certain controllers and/or actions from being > checked? It seems that if I include theAuthComponent, then every > single action is automatically checked. But if the user is not logged > in, theaclcheck will deny access to any action (including login). If > that is the case, how do I access the login action? > > Any insight would be appreciated. > > cook Servus, Well i am a newbe, but very interesseted in the ACL component. But i could not even get close to what you have already managed. So i wonder if you could help me a bit... i loaded the component: var $components = array('Acl'); super then i let cake print out me aktive components: $aro = new Aro(); but in the same time i get a real ugly sql error: Query: startup Warning (512): SQL Error: 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version blablabla well if you have any idea what i do wrong, i would be very happy... tribastian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: is anyone using Acl and AuthComponent in 1.2
One more note to add: The end result for this site is to simply restrict anything under the admin route, to a group of admins. Everything else is web accessible. I realize that acl is serious overkill for such a simple task, I'm using it here to learn more about acl in 1.2 before using it in larger projects. cook On Apr 26, 1:09 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > I was just wondering if anyone is successfully using cakephp Acl and > the new AuthComponent in 1.2? > > If so, could you give us mortals some guidance in setting it up? It > looks as though Acl has changed significantly from 1.1. > > Here is some of what I have managed to peace together so far... > > //add the ACL component > var $components = array('Acl'); > > //get the aro model > $aro = $this->Acl->Aro; > > //create a new aro for User:scook, related to a user in the Users > table > $aro->create( array('model' => 'User', 'foreign_key' => 2, 'alias' => > 'scook') ); > > //save the new aro > $aro->save(); > > //get the aco model > $aco = $this->Acl->Aco; > > //create an aco for my Clients controller > $aco->create( array('foreign_key' => 0, 'alias' => 'Clients') ); > > //save the new aco > $aco->save(); > > //create an aco for the index action of my Clients controller > $aco->create( array('parent_id'=>'[id of Client Aco]', 'foreign_key' > => 0, 'alias' => 'Index') ); > > //save the new aco > $aco->save(); > > //grant User:scook access to the Clients controller > $this->Acl->allow('scook','Clients'); > > So now I can accesswww.site.com/clients/index > > 1. Is everything I have done so far correct and reasonable? > > 2. How do I allow User:scook access to ALL of the Clients > actions, > without adding an aco for each action? I have tried using "*" and "/", > but no luck. > > 3. Can I exclude certain controllers and/or actions from being > checked? It seems that if I include the Auth Component, then every > single action is automatically checked. But if the user is not logged > in, the acl check will deny access to any action (including login). If > that is the case, how do I access the login action? > > Any insight would be appreciated. > > cook --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
is anyone using Acl and AuthComponent in 1.2
I was just wondering if anyone is successfully using cakephp Acl and the new AuthComponent in 1.2? If so, could you give us mortals some guidance in setting it up? It looks as though Acl has changed significantly from 1.1. Here is some of what I have managed to peace together so far... //add the ACL component var $components = array('Acl'); //get the aro model $aro = $this->Acl->Aro; //create a new aro for User:scook, related to a user in the Users table $aro->create( array('model' => 'User', 'foreign_key' => 2, 'alias' => 'scook') ); //save the new aro $aro->save(); //get the aco model $aco = $this->Acl->Aco; //create an aco for my Clients controller $aco->create( array('foreign_key' => 0, 'alias' => 'Clients') ); //save the new aco $aco->save(); //create an aco for the index action of my Clients controller $aco->create( array('parent_id'=>'[id of Client Aco]', 'foreign_key' => 0, 'alias' => 'Index') ); //save the new aco $aco->save(); //grant User:scook access to the Clients controller $this->Acl->allow('scook','Clients'); So now I can access www.site.com/clients/index 1. Is everything I have done so far correct and reasonable? 2. How do I allow User:scook access to ALL of the Clients > actions, without adding an aco for each action? I have tried using "*" and "/", but no luck. 3. Can I exclude certain controllers and/or actions from being checked? It seems that if I include the Auth Component, then every single action is automatically checked. But if the user is not logged in, the acl check will deny access to any action (including login). If that is the case, how do I access the login action? Any insight would be appreciated. cook --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
Thanks for the explanation Nimrod. Interesting reading. Langdon This may be bit OT now and should belong under "Tree Traversal Methods", however I just wanted to maintain a coherent thread so that I can easily find it later on. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
Hello, This may be bit OT now and should belong under "Tree Traversal Methods", however I just wanted to maintain a coherent thread so that I can easily find it later on. I have been looking back at the top of this thread to see if I missed anything at the same time I kept looking back as to why I used a recursive approach to building the tree traversal data for my MPTT implementation. As I said earlier, it's been about three months since I last touched the implementation found here: http://abing.gotdns.com/wobject.php.html Setting all other fields aside, here are the important fields for a node in the object tree: id = object's ID parent_id = object's parent ID lft, rgt = fields for MPTT data link_order = indicates position of a node relative to its siblings Looking at these fields, one can say that parent_id and link_order are not needed. Ordinarily the recursive approach to rebuilding the MPTT data every time the nodes are updated is also not needed. MPTT was developed to remove the need for recursion in tree traversal. Looking back at the notes I have on paper, I remembered why I made the decision to include these redundant fields. Here are the use cases for my system that warrant such fields: * Inserting a new node in an arbitrary position within a subtree. There are three cases for this. Each case requires finding a specific node in the subtree and making sure (for validation purposes) that node is the one we want. 1. Insert a new node at the beginning of the subtree. We need to find the first child node of the parent node. This can easily be found with WHERE Node.lft=(ParentNode.lft + 1). This needs two queries, one to obtain the node data of the parent node and another one to find the node itself. With adjacency list, only one query is needed. 2. Insert a new node at the end of the subtree. We need to find the last child node of the parent node. This can easily be found with WHERE Node.rgt=(ParentNode.rgt -1). This is similar to case #1. 3. Insert a new node right after a specified sibling node in the subtree. This was where things got a bit sticky. How do you find out if a node is an immediate child of its parent? The best, MPTTish way I could come up with was to issue a query to find *all* the nodes under our parent and then traverse it to find the all the immediate children of our parent. This does not scale very well with very large subtrees. The solution I finally decided on is to combine the MPTT approach with the adjacency list approach and maintain a parent_id and a link_order field for each node. Then it was only a simple matter of having WHERE Node.parent_id=(ParentNode.id) AND Node.link_order=Position. There are probably better ways of doing this and I would gladly explore the alternatives when I find the time. However, there is another use case that warrants this decision. Which leads us to... * Obtain a list of immediate child nodes and be able to paginate them. This is where I needed adjacency list approach. As I mentioned above, I could not think of an easier (read: obvious + generic) way to obtain the immediate child nodes of a chosen parent using only the MPTT technique. Once I was able to solve those problems, the other operations/use cases (arbitrary node reparenting, node removal, node deletion) are easily solved by using a combination of adjacency list and MPTT. Finally, as for the recursive _rebuildTreeTraversalData() method, it's a bit of a misnomer as it not only rebuilds the tree traversal data, it also rebuilds and fixes any discrepancies in the adjacency list data when nodes are moved around in the whole tree. I also wrote it so that _rebuildTreeTraversalData() tries to avoid calling itself as much as possible. As for handling ACL, I was looking at this particular implementation at the time: http://phpgacl.sourceforge.net/ There is a demo here: http://phpgacl.sourceforge.net/demo/phpgacl/admin/acl_list.php However, I must admit that I have no idea if this implementation scales better than the CakePHP implementation. But judging from the database schema here: http://phpgacl.cvs.sourceforge.net/phpgacl/phpgacl/schema.xml?view=annotate the project also uses MPTT and it would be interesting to see if and how their implementation handles the case presented by Dr. Tarique. -- _nimrod_a_abing_ [?] http://abing.gotdns.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
On 1/4/07, AD7six <[EMAIL PROTECTED]> wrote: 1) adding a field to the relavent table (access_level = 1,2,3) and adding a condition such that only data meeting the condition is returned (access_level <= $userAccessLevel). Obviously this doesn't use ACL at all, but then ACL isn't always the right solution. I would bet my money on a non ACL approach for limiting access to multiple records/sets and using ACL for things which operate on a single records So you end up with a part which is application specific and a part which is ACL dependent and generic 2) Using ACL and cheating. What do I mean? Consider wanting to find all albums that Bob can access. I guess what I have said above borders on ACL + Cheating :0) Cheers Tarique -- = PHP Applications for E-Biz: http://www.sanisoft.com Cheesecake-Photoblog: http://cheesecake-photoblog.org = --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Tree traversal methods - Was: Using ACL to limit access to data
Thanks Nimrod, I forgot that I changed the subject line ... Here you go: http://groups-beta.google.com/group/cake-php/browse_thread/thread/263d3ffd6fb7533d I need to get back to work :) I'll keep monitoring both threads for any new developments. I'll also be taking a look at implementing the alternative tree traversal method that I pointed out. When I find the time I will try to write a benchmark, say 1,000 - 10,000 nodes, unless someone can point me to an already existing benchmark for this. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Tree traversal methods - Was: Using ACL to limit access to data
Here you go: http://groups-beta.google.com/group/cake-php/browse_thread/thread/263d3ffd6fb7533d I need to get back to work :) I'll keep monitoring both threads for any new developments. I'll also be taking a look at implementing the alternative tree traversal method that I pointed out. When I find the time I will try to write a benchmark, say 1,000 - 10,000 nodes, unless someone can point me to an already existing benchmark for this. On 1/4/07, Langdon Stevenson <[EMAIL PROTECTED]> wrote: Hi Nimrod > I was monitoring the other thread you started and I was not aware of > this new thread. Sorry, could you point me to that thread please? I can't seem to find it in my mail history :-( Regards, Langdon > -- _nimrod_a_abing_ [?] http://abing.gotdns.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Tree traversal methods - Was: Using ACL to limit access to data
Hi Nimrod I was monitoring the other thread you started and I was not aware of this new thread. Sorry, could you point me to that thread please? I can't seem to find it in my mail history :-( Regards, Langdon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
On Dec 31 2006, 1:30 pm, Langdon Stevenson <[EMAIL PROTECTED]> wrote: Langdon Oh the joy, my message went missing - sorry for the pseudo-duplicate if it turns up. I had a thought regarding the originally posed problem, so thought I would reply. ACL doesn't lend itself very well to limiting multiple result sets. but then it isn't really designed to. Generally speaking I see 2 means of limiting access: 1) adding a field to the relavent table (access_level = 1,2,3) and adding a condition such that only data meeting the condition is returned (access_level <= $userAccessLevel). Obviously this doesn't use ACL at all, but then ACL isn't always the right solution. 2) Using ACL and cheating. What do I mean? Consider wanting to find all albums that Bob can access. First see if Bob has access to Albums in general, by checking if he has access to the ACO parent for all albums ( $this->checkAcl (Bob,Albums,'*'); ) Given that, unless there is a rule denying access to Bob (or one of Bobs parents) to an album, he has access. The below pseudo code isn't complete, I realised whilst writing it that if one of Bobs parents is denied access but Bob himself (or an intermediary parent) is granted access, Bob would still get denied. However I include the code for comments... function index() { $Constraint = $this->_getSubQuery(); $data = $this->Album->findAll($Constraint,NULL,$order, $limit, $page); $this->set('data',$data); $this->render('index'); } function _getSubQuery() { $user = $this->Session->read('User.username'); $aro = $this->Aro->findByAlias ($user); $aroLft = $aro['lft']; $aroRght = $aro['rght']; $SubSQL[] = "NOT EXISTS ( SELECT Album.id FROM `Albums`as Album, `acos`, `aros_acos`, `aros` WHERE `acos`.`alias` = CONCAT('Album:', `Album`.`id`) /* Will bomb out if there is no specific ACO for that album */ AND `aros_acos`.`aco_id` = `acos`.`id` /* Will bomb out if there is no specific rule for this album */ AND `ArosAco`.`_read` < 1, /* Only succeed for deny rules */ AND `aros_acos`.`aro_id` = `aros`.`id` /* Ties the results to the found aro/user/group */ AND `aros`.`lft` <= $aroLft /* Ties the results to Bob or his parents */ AND `aros`.`rght` >= $aroRght /* Ties the results to Bob or his parents */ ORDER BY `aros`.`lft` DESC, /* Find the rule for Bob First, his lft field is higher than all his parents */ `acos`.`lft` DESC /* Find the rule for The album First, it's lft field is higher than all it's parents */ )"; return $SubSQL; } So, anyone willing to pickup the baton and comment on whether this could work? Be made better-er, or differently? HTH, AD7six Please note: The manual/bakery is a good place to start any quest for info. The cake search (at the time of writing) erroneously reports less/no results for the google group. The wiki may contain incorrect info - read at your own risk (it's mainly user submitted) :) You may get your answer quicker by asking on the IRC Channel (you can access it with just a browser here:http://irc.cakephp.org). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Tree traversal methods - Was: Using ACL to limit access to data
I don't have that book. But the best link that I can find about the subject (with an example in Access 2000) is here: http://www.mvps.org/access/queries/qry0023.htm I'm not on Windows right now and I haven't looked into it yet to see if this is what you mean. On 1/3/07, Dr. Tarique Sani <[EMAIL PROTECTED]> wrote: On 1/3/07, Langdon Stevenson <[EMAIL PROTECTED]> wrote: > > This discussion has peaked my interest in MPTT implementations. I am > > working on an object system for a CMS based on CakePHP and the object > > tree is implemented using MPTT. I did a "textbook" implementation of > > the thing, which means using a recursive algorithm to reorder the tree > > traversal data (lft and rgt) for each tree node in for inserts and > > deletes. > > Tree traversal methods are not in my area of expertise unfortunately (I > am better at using the tools given to me), so excuse me if I can't add > much to this sub thread. I am however very interested to hear what you > have to say on the subject :-) If I am not mistaken Joe Celko's book on Nested Tree sets has a chapter on what to do when your trees need frequent inserts /me adds TODO: to find that book Tarique -- = PHP Applications for E-Biz: http://www.sanisoft.com Cheesecake-Photoblog: http://cheesecake-photoblog.org = > -- _nimrod_a_abing_ [?] http://abing.gotdns.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Tree traversal methods - Was: Using ACL to limit access to data
I was monitoring the other thread you started and I was not aware of this new thread. Anyway, just read my last two replies to your original thread to get a picture of what I am trying to use MPTT for. I took a recursive approach for rebuilding tree traversal data for reasons described in my last two replies to the original thread. The recursive approach at the time seemed to make sense and offered better DRY possibilities in terms of not having to write and maintain a separate set of queries for each function applied to the tree. I also posted a link to my current implementation. I made a few optimizations so that recursion is used only when absolutely necessary. But as AD7six points out, it is possible to rebuild the tree traversal data without resorting to recursion (as is being done by the current AclNode implementation). On 1/3/07, Langdon Stevenson <[EMAIL PROTECTED]> wrote: Hi Nimrod > This discussion has peaked my interest in MPTT implementations. I am > working on an object system for a CMS based on CakePHP and the object > tree is implemented using MPTT. I did a "textbook" implementation of > the thing, which means using a recursive algorithm to reorder the tree > traversal data (lft and rgt) for each tree node in for inserts and > deletes. Tree traversal methods are not in my area of expertise unfortunately (I am better at using the tools given to me), so excuse me if I can't add much to this sub thread. I am however very interested to hear what you have to say on the subject :-) Regards, Langdon > -- _nimrod_a_abing_ [?] http://abing.gotdns.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
Hello, On 1/3/07, AD7six <[EMAIL PROTECTED]> wrote: Hi abing and all, On Jan 3, 12:50 pm, "Nimrod A. Abing" <[EMAIL PROTECTED]> wrote: > Will this be available on the 1.2 or 1.1 branch or both? I assume 1.2 only. Oh well, I might as well port my CMS to 1.2. A lot of the new stuff in 1.2 seems to cover the things that I found lacking in 1.1 that prompted me to start some modifications to the core CakePHP code. > http://www.sitepoint.com/print/hierarchical-data-database I maintain that recursion isn't necessary to display MPTT tables. Anything that is recursive or converts MPTT tables to nested arrays is not exactly using the benefits that the DB structure offers ;). You're absolutely right about not requiring recursion. Been looking at your code as well as the AclNode implementation. But there is one case I can think of where recursion is necessary. See below. > For inserts, I am talking about inserting a single new node in an > arbitrary parent. For example, inserting a new node under Meat, say > Chicken. I want to insert it so that it goes in between Beef and Pork. > i.e., We end up with Beef, Chicken, Pork under Meat. The logic necessary to add a new node in the middle of it's siblings isn't very different from adding a new node and then reordering. The minimum executed sql is about the same as creating alone - slightly different ofsets. I remember now why I used recursion. I was not able to come up with an ideal and generic way to compute the offsets for abitrary reordering and moving. I was in a hurry so I went with the recursive approach. > For deletes, when I delete a non-leaf node, all of its children will > be reparented to the immediate parent of their parent. > > Delete does not seem to work as I expected in the aros example. I get > the message "aro Daniele (and any child aros) deleted." > > This does not conform to my requirement that its child nodes be > reparented to their grandparent. What I need is akin to a child being > orphaned and sent to their grandparents when their parents die. Though > deleting the children of a node makes much more sense when we are > talking about filesystems. > I have never heard of or considered this case. Why would you want to do that exactly? It seems perfectly logical to me that if you delete a node you also want to delete it's children. But in any case, the sql to do what you have explained isn't much different than deleting a node and all children (would just need to delete the node, re-index the children -1, the 'new' parent right field -2 and all subsequent nodes -2.) I just don't understand why you would want to. This is application-specific. I wanted there to be an option for a user, if a node is deleted and it contains children, the user should be able to chose from two options: A.) Delete everything under the node that is about to be deleted; or B.) Delete the node, but reassign all children to their grandparent. Use case A is the most common case. B is for those cases when you want to just be able to reduce the number of levels in a particular subtree. This is because reparenting the child nodes of a node one by one and deleting the empty node takes much more effort (on the part of the user) than simply deleting the node and reparenting its children in one go. > Comments are very much welcome. Though at this stage, I am thinking of > rewriting the whole thing to use the implementation described here: > > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/461776 Adding redundancy like that will make some tasks simpler but I wouldn't expect it to help with any of the problems that having large tables would cause. But variety is what spawns new ideas so if you go that route I'd be interested to see what you come up with ;). I most certainly will try it out. But if it falls flat on its face, I can just use your MPTT code :) -- _nimrod_a_abing_ [?] http://abing.gotdns.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
Hi abing and all, On Jan 3, 12:50 pm, "Nimrod A. Abing" <[EMAIL PROTECTED]> wrote: Will this be available on the 1.2 or 1.1 branch or both? I assume 1.2 only. http://www.sitepoint.com/print/hierarchical-data-database I maintain that recursion isn't necessary to display MPTT tables. Anything that is recursive or converts MPTT tables to nested arrays is not exactly using the benefits that the DB structure offers ;). For inserts, I am talking about inserting a single new node in an arbitrary parent. For example, inserting a new node under Meat, say Chicken. I want to insert it so that it goes in between Beef and Pork. i.e., We end up with Beef, Chicken, Pork under Meat. The logic necessary to add a new node in the middle of it's siblings isn't very different from adding a new node and then reordering. The minimum executed sql is about the same as creating alone - slightly different ofsets. For reordering, I am talking about moving a node within its subtree changing its left to right order. In the example above, say I change my mind and switch Beef and Pork so that we end up with Pork, Chicken, Beef. This is what I have currently developed and am testing in the MPTT behaviour. For deletes, when I delete a non-leaf node, all of its children will be reparented to the immediate parent of their parent. Delete does not seem to work as I expected in the aros example. I get the message "aro Daniele (and any child aros) deleted." This does not conform to my requirement that its child nodes be reparented to their grandparent. What I need is akin to a child being orphaned and sent to their grandparents when their parents die. Though deleting the children of a node makes much more sense when we are talking about filesystems. I have never heard of or considered this case. Why would you want to do that exactly? It seems perfectly logical to me that if you delete a node you also want to delete it's children. But in any case, the sql to do what you have explained isn't much different than deleting a node and all children (would just need to delete the node, re-index the children -1, the 'new' parent right field -2 and all subsequent nodes -2.) I just don't understand why you would want to. Comments are very much welcome. Though at this stage, I am thinking of rewriting the whole thing to use the implementation described here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/461776 Adding redundancy like that will make some tasks simpler but I wouldn't expect it to help with any of the problems that having large tables would cause. But variety is what spawns new ideas so if you go that route I'd be interested to see what you come up with ;). HTH, AD7six Please note: The manual/bakery is a good place to start any quest for info. The cake search (at the time of writing) erroneously reports less/no results for the google group. The wiki may contain incorrect info - read at your own risk (it's mainly user submitted) :) You may get your answer quicker by asking on the IRC Channel (you can access it with just a browser here:http://irc.cakephp.org). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
Hello, On 1/3/07, AD7six <[EMAIL PROTECTED]> wrote: I heard on the grapevine that the acl code is currently being refactored, so some of what I write below may be obsolete before too long. Will this be available on the 1.2 or 1.1 branch or both? On Jan 3, 4:09 am, "Nimrod A. Abing" <[EMAIL PROTECTED]> wrote: > > I have tried using a stack-based algorithm instead of recursion, but > surprisingly(?!?) it eats up more memory than the recursive version. > Probably because I'm storing objects (which is needed) into the stack. > I'm interested in hearing about others' experience with MPTT > implementations using both the stack-based and recursive approach. Unless I misunderstand and you are not talking about deleting a single (group of) nodes, moving a single (group of) nodes or creating a single (1) node; updating MPTT tables recursively is unnecessary. I used the following as the basis for my implementation: http://www.sitepoint.com/print/hierarchical-data-database Please see the example tree there to see what I'm talking about. For inserts, I am talking about inserting a single new node in an arbitrary parent. For example, inserting a new node under Meat, say Chicken. I want to insert it so that it goes in between Beef and Pork. i.e., We end up with Beef, Chicken, Pork under Meat. For moves, I am talking about moving a node, and its subtree if present to a new parent. For reordering, I am talking about moving a node within its subtree changing its left to right order. In the example above, say I change my mind and switch Beef and Pork so that we end up with Pork, Chicken, Beef. For deletes, when I delete a non-leaf node, all of its children will be reparented to the immediate parent of their parent. For deleting a node or group of nodes, the acl_node class already takes care of this with a minimum of sql and affected rows. Deletes are actually the easiest case to handle. ... The online acl admin demo allows you to move things around to test this change if you are curious. See http://www.noswad.me.uk/AclAdminDemo/aros (use the Load from user table link if no aros present) or http://www.noswad.me.uk/AclAdminDemo/acos (create something if no acos present and go to the data view) and use the Move this -> form to reparent something(s). Your example handles only the case for moves as I described above. Delete does not seem to work as I expected in the aros example. I get the message "aro Daniele (and any child aros) deleted." This does not conform to my requirement that its child nodes be reparented to their grandparent. What I need is akin to a child being orphaned and sent to their grandparents when their parents die. Though deleting the children of a node makes much more sense when we are talking about filesystems. The exact code in use for the demo, incase there are any differences with the ticket code can be seen here: http://www.noswad.me.uk/AclAdminDemo/acl_node (set parent method) I have a partially finished MPTT behaviour, which was based upon the acl_node class and has some additional functionality namely reordering without reparenting using the above logic (so for example, you could if you really wanted use it to design your multi-level menu. and move option 1.1.1.15 to position 1.1.1.7 by reordering up 8 steps). If there are any other MPTT functions that are of interest (I can't think of any) I'd be glad to hear of them. I'll look into your code as soon as I found the time. I haven't touched my implementation for about three months now after I got sidetracked to work on another project. I've put up the relevant class file here: http://abing.gotdns.com/wobject.php.html in case anyone is interested. The implementation is based mostly on the algorithm described in the sitepoint article above (and from Wikipedia I think). As for using recursion in _rebuildTreeTraversalData() IIRC the reason I did it was because I wanted it to be able to handle the link_order field reordering. Also, I wanted to avoid writing separate SQL statements to handle tree traversal data updates for delete, reparent, and reorder cases. Though I must admit that the link_order field is a bit redundant unnecessary now that I look back at it. I made some optimizations that make sure _rebuildTreeTraversalData() is run only when it is needed. Also, _rebuildTreeTraversalData() avoids recursion if it can (when lft and rgt are unchanged for a node). Comments are very much welcome. Though at this stage, I am thinking of rewriting the whole thing to use the implementation described here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/461776 But the more I look at that implementation, the more it seems to be suboptimal when it is time to handle very large trees. -- _nimrod_a_abing_ [?] http://abing.gotdns.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cak
Re: Using ACL to limit access to data
On 1/3/07, AD7six <[EMAIL PROTECTED]> wrote: Dr. Tarique Sani: I wonder if that book mentions leaving data holes between tree nodes (akin to numbering lines as 10,20,30 in BASIC such that you can create line 15 if you find you need to add something without renumbering the whole file). I think it did - I read that too long ago when I was in "I will never need that" frame of mind ;) Means that some functionality is lost ( you can't know how many children a parent has without specifically searching), but I can't think of any other way of handling frequent inserts. If I do manage to find the book I will read up and let you know Tarique -- = PHP Applications for E-Biz: http://www.sanisoft.com Cheesecake-Photoblog: http://cheesecake-photoblog.org = --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
Hi abing and all, I heard on the grapevine that the acl code is currently being refactored, so some of what I write below may be obsolete before too long. On Jan 3, 4:09 am, "Nimrod A. Abing" <[EMAIL PROTECTED]> wrote: I have tried using a stack-based algorithm instead of recursion, but surprisingly(?!?) it eats up more memory than the recursive version. Probably because I'm storing objects (which is needed) into the stack. I'm interested in hearing about others' experience with MPTT implementations using both the stack-based and recursive approach. Unless I misunderstand and you are not talking about deleting a single (group of) nodes, moving a single (group of) nodes or creating a single (1) node; updating MPTT tables recursively is unnecessary. For deleting a node or group of nodes, the acl_node class already takes care of this with a minimum of sql and affected rows. To clarify what I mean for moving (groups of) nodes, and ignoring that a person has 2 parents :), consider I accidentally put Uncle bob under the wrong grandparent whilst building my family tree. The sql that puts Bob and all of his children, grandchildren etc. in the right place should action everthing under Uncle bob as a whole - not each of his family members individually in a recursive manner. Irrespective of the size of Bobs family the following sql would be executed: 1) change the lft and rght fields for Bob and all children such that the branch is moved out of the tree leaving a hole. 2) change the lft and rght fields of everything inbetween where Bob was to where he needs to be such that the hole is under Bobs Parent. 3) change the lft and rght fields for Bob and all children such that the branch is in the right place and Bob has the right parent. There are never more than 6 sql statements to move a node or group of nodes; and rows that don't need to change are unafected (only the rows inbetween where Bob and his family now are and were they where are afected). I added to the following ticket a while ago https://trac.cakephp.org/ticket/1234 regarding this. The online acl admin demo allows you to move things around to test this change if you are curious. See http://www.noswad.me.uk/AclAdminDemo/aros (use the Load from user table link if no aros present) or http://www.noswad.me.uk/AclAdminDemo/acos (create something if no acos present and go to the data view) and use the Move this -> form to reparent something(s). The exact code in use for the demo, incase there are any differences with the ticket code can be seen here: http://www.noswad.me.uk/AclAdminDemo/acl_node (set parent method) I have a partially finished MPTT behaviour, which was based upon the acl_node class and has some additional functionality namely reordering without reparenting using the above logic (so for example, you could if you really wanted use it to design your multi-level menu. and move option 1.1.1.15 to position 1.1.1.7 by reordering up 8 steps). If there are any other MPTT functions that are of interest (I can't think of any) I'd be glad to hear of them. Dr. Tarique Sani: I wonder if that book mentions leaving data holes between tree nodes (akin to numbering lines as 10,20,30 in BASIC such that you can create line 15 if you find you need to add something without renumbering the whole file). Means that some functionality is lost ( you can't know how many children a parent has without specifically searching), but I can't think of any other way of handling frequent inserts. HTH, AD7six Please note: The manual/bakery is a good place to start any quest for info. The cake search (at the time of writing) erroneously reports less/no results for the google group. The wiki may contain incorrect info - read at your own risk (it's mainly user submitted) :) You may get your answer quicker by asking on the IRC Channel (you can access it with just a browser here:http://irc.cakephp.org). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Tree traversal methods - Was: Using ACL to limit access to data
On 1/3/07, Langdon Stevenson <[EMAIL PROTECTED]> wrote: > This discussion has peaked my interest in MPTT implementations. I am > working on an object system for a CMS based on CakePHP and the object > tree is implemented using MPTT. I did a "textbook" implementation of > the thing, which means using a recursive algorithm to reorder the tree > traversal data (lft and rgt) for each tree node in for inserts and > deletes. Tree traversal methods are not in my area of expertise unfortunately (I am better at using the tools given to me), so excuse me if I can't add much to this sub thread. I am however very interested to hear what you have to say on the subject :-) If I am not mistaken Joe Celko's book on Nested Tree sets has a chapter on what to do when your trees need frequent inserts /me adds TODO: to find that book Tarique -- = PHP Applications for E-Biz: http://www.sanisoft.com Cheesecake-Photoblog: http://cheesecake-photoblog.org = --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Tree traversal methods - Was: Using ACL to limit access to data
Hi Nimrod This discussion has peaked my interest in MPTT implementations. I am working on an object system for a CMS based on CakePHP and the object tree is implemented using MPTT. I did a "textbook" implementation of the thing, which means using a recursive algorithm to reorder the tree traversal data (lft and rgt) for each tree node in for inserts and deletes. Tree traversal methods are not in my area of expertise unfortunately (I am better at using the tools given to me), so excuse me if I can't add much to this sub thread. I am however very interested to hear what you have to say on the subject :-) Regards, Langdon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
On 1/3/07, Dr. Tarique Sani <[EMAIL PROTECTED]> wrote: On 1/2/07, Langdon Stevenson <[EMAIL PROTECTED]> wrote: > What we seem to be talking about is creating an entirely new method of > defining and retrieving our security information hierarchy, something > different to modified preorder tree traversal. MPTT can't be and should not be abandoned - we have to find a way to apply the results in a better way This discussion has peaked my interest in MPTT implementations. I am working on an object system for a CMS based on CakePHP and the object tree is implemented using MPTT. I did a "textbook" implementation of the thing, which means using a recursive algorithm to reorder the tree traversal data (lft and rgt) for each tree node in for inserts and deletes. I looked into the MPTT implementation in the ACL code and it looks like it cleverly avoids having to do recursive traversal in updating the lft and rgt fields during an update. But I think the optimizations used will only work in very simple trees that support the basic CRUD operations. My object tree needs to support reordering of nodes within a subtree as well as moving a node from one subtree to another. Because of this, an extra field is used and needs to be updated when the tree traversal data is updated. The simplest and most maintainable solution I found was through a recursive algorithm. The scenario presented by Dr. Tarique, very large tree of ACO's with very large tree of ARO's is a very real problem with my object system. MPTT provides for minimal amount of memory and SQL queries during reads. But when it comes to writes and updates, the thing uses up a lot of memory and requires a lot of SQL queries when updating a very large tree (this is using my current recursive implementation). I have not found the time to write a good benchmark yet, but from initial tests (20-100 nodes) the results do not look very good. I have tried using a stack-based algorithm instead of recursion, but surprisingly(?!?) it eats up more memory than the recursive version. Probably because I'm storing objects (which is needed) into the stack. I'm interested in hearing about others' experience with MPTT implementations using both the stack-based and recursive approach. Recently, I dug up an article on the ASPN Python Cookbook which implements DOM tree traversal without recursion or node tracking (using stack): http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/461776 From the looks of things, it seems to be much simpler than MPTT and can be optimized in a number of ways depending on the application specifics. But it also seems to require some changes to the database tables to add support for pointers to a node's parent, first child, and next sibling. -- _nimrod_a_abing_ [?] http://abing.gotdns.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
On Jan 2, 5:03 pm, "Dr. Tarique Sani" <[EMAIL PROTECTED]> wrote: On 1/2/07, Langdon Stevenson <[EMAIL PROTECTED]> wrote: > What we seem to be talking about is creating an entirely new method of > defining and retrieving our security information hierarchy, something > different to modified preorder tree traversal.MPTT can't be and should not be abandoned - we have to find a way to apply the results in a better way Tarique -- = PHP Applications for E-Biz:http://www.sanisoft.com Cheesecake-Photoblog:http://cheesecake-photoblog.org = Hi All, I just finished a working version of an access control component that would allow you to define "owner delete", "owner view", "owner edit" etc. using ACL without defining a rule for each actual aco, or even creating each aco. The code for now is here http://bin.cakephp.org/view/1153809117 It's not the answer to everything but I hope it might at least be useful in sparking ideas. Here's an example in how it works: For the url /demo2/categories/edit/1 where "demo2" is a plugin and the AC component has been included. The following occurs: // Find the aro for the currently logged in user SELECT `Aro`.`id`, `Aro`.`model`, `Aro`.`foreign_key`, `Aro`.`alias`, `Aro`.`lft`, `Aro`.`rght` FROM `core_aros` AS `Aro` WHERE (`Aro`.`alias` = 'username') LIMIT 1 SELECT `Category`.`id`, `Category`.`user_id` FROM `demos_categories` AS `Category` WHERE (`Category`.`id` = 1) LIMIT 1 // Find the aco for the current section/controller/action/param combination. SELECT `Aco`.`alias` FROM `core_acos` AS `Aco` WHERE (`Aco`.`alias` IN ( 'demo2:categories:owner_edit:1', 'demo2:categories:owner_edit', 'demo2:categories:edit:1', 'demo2:categories:edit', 'demo2:categories', 'demo2', 'ROOT') ) ORDER BY `Aco`.`lft` DESC LIMIT 1 // If either query returns nothing (i.e. the basic ACL data isn't present), access is denied, otherwise the results of which are used like so: $this->checkAcl ($resultOfFirstQuery,$resultOfSecondQuery,'*'); and the result of this call is used to decide access or not. If a slug/title field is used in the url instead of the row id, this is taken into account by the component if the slug is either the first or a named parameter for the call. The list of ACOs generated for the second query prepends "owner_action:id" and "owner_action" to the potential list of ACOs if the model instance can be identified AND a user is currently logged in (identified by a session variable), otherwise these aco aliases are not added to the list. In this way it is possible to, for example define that USERS can owner_edit posts, and irrespective of how many users or posts you have, this one rule will be found and honored. Happy new year all, Comments welcome, AD7six Please note: The manual/bakery is a good place to start any quest for info. The cake search (at the time of writing) erroneously reports less/no results for the google group. The wiki may contain incorrect info - read at your own risk (it's mainly user submitted) :) You may get your answer quicker by asking on the IRC Channel (you can access it with just a browser here:http://irc.cakephp.org). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
On 1/2/07, Langdon Stevenson <[EMAIL PROTECTED]> wrote: What we seem to be talking about is creating an entirely new method of defining and retrieving our security information hierarchy, something different to modified preorder tree traversal. MPTT can't be and should not be abandoned - we have to find a way to apply the results in a better way Tarique -- = PHP Applications for E-Biz: http://www.sanisoft.com Cheesecake-Photoblog: http://cheesecake-photoblog.org = --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
I've been thinking about this for a while (and am going to have to *do* it in the next week or two:). I plan to specify a 'securing_attribute_name' for each model - set to a default false in AppModel. For your example, the the securing attribute may be 'group_id' on an Album or 'Album.group_id' for a Picture (this assumes a Picture belongsTo an Album and is never fetched without it's parent). The securing attribute (group_id) can be de-normalized for performance or if secured models are likely to be unbound from their parents. In the beforeFind() of AppModel, the conditions get modified to compare the User's securing_attribute_id (may also be an array) to the column specified in securing_attribute_name (either '=' or 'IN (...)'). That's the easy bit. Where I get a bit stuck is in the integration with cake's acl (probably because I'm not yet familiar enough with it). The securing_attribute_id could be per user (if the user has access to the same group of data for all roles) or per role (where the user access different groups of data dependent on the role they are currently in). Ideally, I think it would be useful to be able to set an additional column (securing_attribute_id) on the aco_aros table ( see https://trac.cakephp.org/ticket/1846 ). In my implementation, I will probably turn it on it's head and set the aco's based upon the secured object last accessed (i.e. if you want to modify a picture, then you must navigate via an album which will load the aco's you have been assigned for that album). This way the user_id and secring_attribute_id become the primary key to select the aco's, mitigationg some of the performanc issues with extra large datasets. ~Philip Dr. Tarique Sani wrote: On 1/1/07, Langdon Stevenson <[EMAIL PROTECTED]> wrote: > Can you elaborate on your requirements a little further? Perhaps I am > missing something? Let me give a real-life example. The largest known installation of Coppermine Picture Gallery (an Open Source project that I lead) has more than 3 million pictures and approx 100,000 users. As long as all the pictures and albums were public this was not a big problem. However Coppermine has a concept of user albums and private albums and password protected albums which can be or cannot be seen by public - the webmaster turned on the private albums feature and the hell broke loose as the queries started including criteria like "aid NOT IN (1,5,.. long list of aids) and the looping checks were just too much. Coming to cakePHP perspective - I am currently wondering on how to exclude certain records from model->findAll* calls using the current ACL techniques. Actions which return or affect just one record will be no big deal atleast for some time but as the ACOs increase (in the above case 3 million +) performance will start to slow down even in those cases. That said I have to agree that example given by me is a rare one but at the same time a very plausible one. Cheers Tarique -- = PHP Applications for E-Biz: http://www.sanisoft.com Cheesecake-Photoblog: http://cheesecake-photoblog.org = --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
The more I think and talk about the problem, the more I get the impression that there really is no simple, easy solution. And that is what I am not ready to accept as yet ;-) but the sinking feeling is there. Perhaps it's a matter then of more horse power? It would be interesting to do a cost benefit analysis on a problem like this. What we seem to be talking about is creating an entirely new method of defining and retrieving our security information hierarchy, something different to modified preorder tree traversal. This is where I get scared and run away! I have done a bit of Googling on the subject and for now MPTT seems to be the peak of the art. Regards, Langdon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
On 1/2/07, Langdon Stevenson <[EMAIL PROTECTED]> wrote: The more I think and talk about the problem, the more I get the impression that there really is no simple, easy solution. And that is what I am not ready to accept as yet ;-) but the sinking feeling is there. Cheers Tarique -- = PHP Applications for E-Biz: http://www.sanisoft.com Cheesecake-Photoblog: http://cheesecake-photoblog.org = --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
Hi Tariqu This implies heavily that limiting the number of Acos is the key. Can you give an example of how a user may accumulate large numbers of Acos? Yes, if you see to my previous example - getting in findAll* which pictures/albums/categories a user is allowed to see (depending which group she belongs to) you will soon have a large number of ACOs That's true, if users are able (and likely) to belong to many groups that have lots of nesting. In my system that will never happen, as the business rules and nature of the system limit the number of Acos per user. I think that you are probably right. The question then becomes: is this a problem? If so, why is it a problem? The problem for me is what would be a DRY way to do this. I very easily can do it the usual way by adding criteria to findAll or even some funky bindModel stuff, but this way there is access restriction code in almost every controller / model. A valid point. I had thought about looking into redeclaring the find functions so that they inserting the criteria into the query automatically. That would remove the requirement for adding the criteria to each query in a model. It would also have the advantage of reducing the potential for security holes. The more I think and talk about the problem, the more I get the impression that there really is no simple, easy solution. If we want to have the power and flexibility of ACL, with its ability to nest groups of AROs and ACOs then we have to pay the price for that and provide sufficient processing power to support it. Regards, Langdon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
On 1/2/07, Langdon Stevenson <[EMAIL PROTECTED]> wrote: This implies heavily that limiting the number of Acos is the key. Can you give an example of how a user may accumulate large numbers of Acos? Yes, if you see to my previous example - getting in findAll* which pictures/albums/categories a user is allowed to see (depending which group she belongs to) you will soon have a large number of ACOs I think that you are probably right. The question then becomes: is this a problem? If so, why is it a problem? The problem for me is what would be a DRY way to do this. I very easily can do it the usual way by adding criteria to findAll or even some funky bindModel stuff, but this way there is access restriction code in almost every controller / model. This for a large project soon gets to be P2C2E (Process too Complicated to Explain) unless explained in great details at every step. May be it needs inversion of approach to solve it Cheers Tarique -- = PHP Applications for E-Biz: http://www.sanisoft.com Cheesecake-Photoblog: http://cheesecake-photoblog.org = --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
Hi Tarique This would mean no need to query Acos for findAll queries, other than at login (at which time you select all of their Acos and store them in a session or cache). We will very quickly run out of memory if session is kept in memory, if not reading large number of ACOs from cache/file based session would be *almost* just as expensive as queries from a database. This implies heavily that limiting the number of Acos is the key. Can you give an example of how a user may accumulate large numbers of Acos? (Other than a "superuser" who would logically have access to everything I ask this not to be argumentative, only to try to get a better understanding of the issue. I may well be facing the same problems as you, only I haven't realised it yet! :-) After that it is just a matter of limiting the number of Acos included in an IN () clause to a reasonable number, possibly based on model type, or some other criteria. As soon as we introduce 'some other criteria' the solution becomes app specific. I am getting more and more inclined to believe that access restriction to data will always have to be based on app specific criteria. I think that you are probably right. The question then becomes: is this a problem? If so, why is it a problem? Are you intending for your Cake app to share its security data with other applications? If your application essentially stands alone, then surely it won't matter if its Acos are application specific? Regards, Langdon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
On 1/1/07, Langdon Stevenson <[EMAIL PROTECTED]> wrote: This would mean no need to query Acos for findAll queries, other than at login (at which time you select all of their Acos and store them in a session or cache). We will very quickly run out of memory if session is kept in memory, if not reading large number of ACOs from cache/file based session would be *almost* just as expensive as queries from a database. After that it is just a matter of limiting the number of Acos included in an IN () clause to a reasonable number, possibly based on model type, or some other criteria. As soon as we introduce 'some other criteria' the solution becomes app specific. I am getting more and more inclined to believe that access restriction to data will always have to be based on app specific criteria. Can anyone tell if the newly introduced Behaviours in 1.2 would be helpful in this regard? Cheers Tarique -- = PHP Applications for E-Biz: http://www.sanisoft.com Cheesecake-Photoblog: http://cheesecake-photoblog.org = --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
Hi Tarique Good example. Let me give a real-life example. The largest known installation of Coppermine Picture Gallery (an Open Source project that I lead) has more than 3 million pictures and approx 100,000 users. As long as all the pictures and albums were public this was not a big problem. However Coppermine has a concept of user albums and private albums and password protected albums which can be or cannot be seen by public - the webmaster turned on the private albums feature and the hell broke loose as the queries started including criteria like "aid NOT IN (1,5,.. long list of aids) and the looping checks were just too much. I see the problem alright :-) I guess that in that situation you are limited by the complexity of the Aco tree. In my case I anticipate including business rules that minimise the list of Acos for a user. It should really be possible to limit a user to just half a dozen Acos or so in any given situation. One way of doing this is to only extract Acos that are related to the Model that is being queried. This could be handled by naming conventions. I already do this in fact by filtering out the ":data" Acos. The idea was to avoid exactly that problem of overloading the query. Coming to cakePHP perspective - I am currently wondering on how to exclude certain records from model->findAll* calls using the current ACL techniques. Actions which return or affect just one record will be no big deal atleast for some time but as the ACOs increase (in the above case 3 million +) performance will start to slow down even in those cases. That said I have to agree that example given by me is a rare one but at the same time a very plausible one. Absolutely. I will argue that growth of Aco numbers can be dealt with though. Firstly by the method mentioned above and secondly by caching of the Aco data for the user. This would mean no need to query Acos for findAll queries, other than at login (at which time you select all of their Acos and store them in a session or cache). After that it is just a matter of limiting the number of Acos included in an IN () clause to a reasonable number, possibly based on model type, or some other criteria. Given that, I think that the design would scale well with both large numbers of users and records. However I have never had to deal with a system that holds millions of records, so I may be wrong. It would be very interesting to find out. Regards, Langdon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
On 1/1/07, Langdon Stevenson <[EMAIL PROTECTED]> wrote: Can you elaborate on your requirements a little further? Perhaps I am missing something? Let me give a real-life example. The largest known installation of Coppermine Picture Gallery (an Open Source project that I lead) has more than 3 million pictures and approx 100,000 users. As long as all the pictures and albums were public this was not a big problem. However Coppermine has a concept of user albums and private albums and password protected albums which can be or cannot be seen by public - the webmaster turned on the private albums feature and the hell broke loose as the queries started including criteria like "aid NOT IN (1,5,.. long list of aids) and the looping checks were just too much. Coming to cakePHP perspective - I am currently wondering on how to exclude certain records from model->findAll* calls using the current ACL techniques. Actions which return or affect just one record will be no big deal atleast for some time but as the ACOs increase (in the above case 3 million +) performance will start to slow down even in those cases. That said I have to agree that example given by me is a rare one but at the same time a very plausible one. Cheers Tarique -- = PHP Applications for E-Biz: http://www.sanisoft.com Cheesecake-Photoblog: http://cheesecake-photoblog.org = --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
Hi Tarique Nice implementation - which I am sure will fit very well where the data structure is similar to the one you have, that is where data belongs to groups. Would love to hear more thoughts from more people - on access control for data in a massively multi-user systems built using cakePHP Interesting question. I don't see a problem though with extending this system. I would do so by adding an Aco for each user (effectively creating their own individual group) and using the same system of restriction. Given caching, or session storage of the Aco/s there wouldn't be any performance issue, even if you were talking about hundreds of thousands of users. Can you elaborate on your requirements a little further? Perhaps I am missing something? Regards, Langdon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
Nice implementation - which I am sure will fit very well where the data structure is similar to the one you have, that is where data belongs to groups. Would love to hear more thoughts from more people - on access control for data in a massively multi-user systems built using cakePHP Cheers and happy new year Tarique On 1/1/07, Langdon Stevenson <[EMAIL PROTECTED]> wrote: Ok, have a look at this :-) Warning: 1. You need a solid understanding of ACL for this to make sense. -- = PHP Applications for E-Biz: http://www.sanisoft.com Cheesecake-Photoblog: http://cheesecake-photoblog.org = --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
Ok, have a look at this :-) Warning: 1. You need a solid understanding of ACL for this to make sense. 2. I am sure that this code could be improved substantially by better programmers than me. The aim was just to make something that worked to see if it could be done. I guess that it should be made into a component. Pre-requisites: 1. User authentication (I am using dAuth for this) 2. An Aro structure of usernames and groups that match the authentication system 3. An Aco structure of groups that data can belong to Once you have that then you are ready to protect your data. // First, get a list of Acos that the user has access to and // return it as a comma delimited string with '' mark around each // Aco alias. The functions used are listed below. $ownerString = $this->_arrayToList($this->_getDataAcos()); // Query the database for records that we are allowed to access // using the list generated above as a filter. This requires the // table have a column that holds an Aco name for each record to define // who can access it. In this case the column name is 'owner'. $this->set( 'data', $this->Master->findAll( 'WHERE `Master`.`owner` IN ('.$ownerString.')' ) ); This will return a data set of only the records that the ACL system says the user should have access to. /* * The function _getDataAcos() does the following: * * - Gets the username of the current user from the session * - Retrieves the ARO path for the username * - Gets all AroAco links for the Aro path * - Gets the Alias for each Aco from each link * - Finds Acos that have the extension ":data" (meaning that they * are used for controlling data rather than controller actions * - Gets all children data Acos and puts them in an array * - Returns the array of data Acos * * I put it in appController.php so that it is available everywhere */ function _getDataAcos () { $aro = new Aro(); // Get the username. It may be better to pass this to the function $user = $this->Session->read('User'); $username = $user['username']; // Get the Aro path for this user $aroPath = $aro->getPath($username); // Retrieve all links for the list of Aros $Link = new ArosAco(); foreach ($aroPath as $path) { $temp[] = $Link->findAllByAro_id($path['Aro']['id']); } $Aco = new Aco(); // Iterate through the links foreach ($temp as $tempAro) { // Iterate through each Aco attached the the current Aro foreach ($tempAro as $tempLink) { // If the Aco's alias has the extension ":data" we want it if (count(explode(':', $tempLink['Aco']['alias'])) > 1) { $acos[] = $tempLink['Aco']['alias']; // Get the children of the Aco so that we inherit their access $tempAcos[] = $Aco->getChildren($tempLink['Aco']['object_id']); // Iterate through all child Acos foreach($tempAcos as $potentials) { // There are two levels of nesting, so iterate the second foreach ($potentials as $potential) { // Check that the Acos are data Acos // This is not really required if (count(explode(':', $potential['Aco']['alias'])) > 1) { // Put the Acos we have selected in an array $acos[] = $potential['Aco']['alias']; } } } } } } // send back the Aco array return $acos; } /* * This function just turns the array of names into a comma delimited * string with each item in ''. */ function _arrayToList($sourceArray = null) { $ownerString = ''; $ownerArray = $this->_getDataAcos(); foreach ($ownerArray as $owner) { $ownerString .= '\''.$owner.'\','; } return trim($ownerString, ','); } So that's it. Hope that it made some sense. I have done basic testing on it, and it appears that the data is protected according to the rules of the ACL. However, if you want to use this code I would strongly suggest that you conduct your own testing to be sure I haven't made some glaring error in the security. If anyone can suggest improvements, or a better way to achieve the same result, I would like to hear it :-) Regards, Langdon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
RE: Using ACL to limit access to data
All this expectation is killing me ;) When will we be able to take a glimpse at it? Thanks for the hard work. -MI --- Remember, smart coders answer ten questions for every question they ask. So be smart, be cool, and share your knowledge. BAKE ON! -Mensaje original- De: cake-php@googlegroups.com [mailto:[EMAIL PROTECTED] En nombre de Langdon Stevenson Enviado el: Domingo, 31 de Diciembre de 2006 06:56 p.m. Para: cake-php@googlegroups.com Asunto: Re: Using ACL to limit access to data Agreed. My solution does not modify Cake core code in any way, I just used various function in the ACL code in a different way to achieve the desired result. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
Hi Brandon This sounds along the lines of what I was planning to do. Except that I didn't want to modify the core code, since I'd have to do the same on every version update. Agreed. My solution does not modify Cake core code in any way, I just used various function in the ACL code in a different way to achieve the desired result. So I decided just to make my own implementation, that heavily borrow's from cake's (not in code, just in concept). Sounds useful, though. I considered doing this too, but was put off by the thought of having to access control systems to maintain. I would be interested to hear your thoughts on what I post. Regards, Langdon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
Hi devon This sounds great. Please let me know how to access a sample of your code. Looking forward. I will put a sample together today and post it. It is still just prototype, so I am sure that it can be improved upon. Regards, Langdon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
RE: Using ACL to limit access to data
Hi, This sounds along the lines of what I was planning to do. Except that I didn't want to modify the core code, since I'd have to do the same on every version update. So I decided just to make my own implementation, that heavily borrow's from cake's (not in code, just in concept). Sounds useful, though. Brandon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Using ACL to limit access to data
Hello Langdon This sounds great. Please let me know how to access a sample of your code. Looking forward. Thanks! Devon Langdon Stevenson wrote: Hi I thought that I would share something that I have just developed with the list. My ACL implementation does a good job of limiting access to controllers and their actions. Cake's ACL is great for checking if: "Mr User" (an ARO) is allowed to access "Mr Object" (an ACO). However the standard ACL system does not give you a simple way to generate a list of ACO's that "Mr User" is allowed to access. Therefore if you want to prevent a user from accessing data that they are not allowed to you have to build some sort of security into your controllers that works out how to limit who can request what. You could also use an afterFind callback to check the access rights on each row returned by a query. This would slow your system to a halt in no time with large queries. I wanted to make the most of Cake's ACL system, so I poked around in the API and got an understanding for how it all works. From there I wrote a function that retrieves a list of ACOs that the current user is allowed to access. My solution: - I created a set of ACO's that represent each client, and their various departments - Each data record is tagged with the department that the creator belongs to when they are created (assigning an "owner" to the data) - When a user requests a data record a list of ACOs that they are allowed to access is generated - Find queries have an extra WHERE clause added to them like this that checks if the owner of the data is in the list of owners that the user is associated with: AND `Master`.`owner` IN ('client_dept_1:data', 'client_dept_2:data') As a result, only records that the user is allowed to access are returned to them. I am quite pleased with this result as it represents only a small increase in overhead to the "find" queries, and it allows me to make full use of the (quite awesome) power of ACL. I will look at caching the ACO list of the user some time soon to help reduce the number of queries required for each request. Once that is done this system should have negligible impact on the performance of the system, but give me complete control over who can see what. I hope this may be useful to someone. If so, and you would like to know more about generating a list of ACOs for individual AROs, then let me know. I would be happy to share. Regards and a happy New Year to everyone, Langdon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Using ACL to limit access to data
Hi I thought that I would share something that I have just developed with the list. My ACL implementation does a good job of limiting access to controllers and their actions. Cake's ACL is great for checking if: "Mr User" (an ARO) is allowed to access "Mr Object" (an ACO). However the standard ACL system does not give you a simple way to generate a list of ACO's that "Mr User" is allowed to access. Therefore if you want to prevent a user from accessing data that they are not allowed to you have to build some sort of security into your controllers that works out how to limit who can request what. You could also use an afterFind callback to check the access rights on each row returned by a query. This would slow your system to a halt in no time with large queries. I wanted to make the most of Cake's ACL system, so I poked around in the API and got an understanding for how it all works. From there I wrote a function that retrieves a list of ACOs that the current user is allowed to access. My solution: - I created a set of ACO's that represent each client, and their various departments - Each data record is tagged with the department that the creator belongs to when they are created (assigning an "owner" to the data) - When a user requests a data record a list of ACOs that they are allowed to access is generated - Find queries have an extra WHERE clause added to them like this that checks if the owner of the data is in the list of owners that the user is associated with: AND `Master`.`owner` IN ('client_dept_1:data', 'client_dept_2:data') As a result, only records that the user is allowed to access are returned to them. I am quite pleased with this result as it represents only a small increase in overhead to the "find" queries, and it allows me to make full use of the (quite awesome) power of ACL. I will look at caching the ACO list of the user some time soon to help reduce the number of queries required for each request. Once that is done this system should have negligible impact on the performance of the system, but give me complete control over who can see what. I hope this may be useful to someone. If so, and you would like to know more about generating a list of ACOs for individual AROs, then let me know. I would be happy to share. Regards and a happy New Year to everyone, Langdon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~--~~~~--~~--~--~---
Re: Anyone using Acl in Sql Server database?
(Bump). Am desperate.. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Anyone using Acl in Sql Server database?
The reason I ask is that I get these errors when attempting to create new Aro: == Warning: mssql_query() [function.mssql-query]: message: Invalid column name 'MAX(rght) as rght'. (severity 16) in C:\Program Files\Apache Group\Apache2\htdocs\cake\libs\model\dbo\dbo_mssql.php on line 166 Warning: mssql_query() [function.mssql-query]: General SQL Server error: Check messages from the SQL Server. (severity 5) in C:\Program Files\Apache Group\Apache2\htdocs\cake\libs\model\dbo\dbo_mssql.php on line 166 Warning: mssql_query() [function.mssql-query]: Query failed in C:\Program Files\Apache Group\Apache2\htdocs\cake\libs\model\dbo\dbo_mssql.php on line 166 Notice: Undefined offset: 0 in C:\Program Files\Apache Group\Apache2\htdocs\cake\libs\controller\components\dbacl\models\aclnode.php on line 69 == This is the query that breaks: SELECT TOP 1 [Aro].[MAX(rght) as rght] AS [Aro__MAX(rght) as rght] FROM [aros] AS [Aro] WHERE 1 = 1 Should I log a ticket? Pat. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---