Sorry for writing something that looked like griping! I was absolutely NOT complaining about how the Auth Component works -- even though a year ago, I did once make this complaint.
On the other hand, it is nice to have such a nicely worded explanation of why this "feature" is not in the core code. I am in agreement with the idea that it is generally not necessary to use the ACL Component to protect items at a record level. Usually just using an author_id field will be enough. -Aran On Nov 20, 6:18 am, mark_story <[EMAIL PROTECTED]> wrote: > On Nov 20, 4:23 am, eMarcus <[EMAIL PROTECTED]> wrote: > > > Hi Mark, > > > Thanks for your answer! > > > When you follow the conversation right from the beginning, you will > > see, that I definitly KNOW that controller/actions/id access does not > > help me and that I therefore want to use your proposed schema of > > models/records to protect my content. > > My apologies for the rant then, just I've heard that gripe so many > times, I've gotten quite tired of it. > > > However, what confused me as a beginner was, that in all the official > > documentation there where only examples of "the easy way". > > The reason for this is that many people find the concept of ACL > complicated enough without further muddying the issue with row level > permissions and multiple checks across multiple branches of the aco > tree. > > > > > My intention was to ask for the "best practice" for providing access > > on a model/record level. > > > I already implemented the ACO tree as you proposed (I have a "models" > > hive where all records get its entry). > > > As Mark explained, I have to do the permission check manually. Fine, I > > can do this using $this->Acl->check() Doing this in the controller > > would work, but seems to be quite complicate as I do combined queries > > from different models. So I get a result of : > > > result = array ( > > [model0] => array ( > > [field0] => value, > > [field1] => value, > > ...), > > [model2] => array (...) > > [model3] => array (...) > > ) > > > now, if the user has i.e. read permissions for model2 but not for > > model0 and model3, how would I do that? Check manually all entries and > > delete the ones he does not have permissons on? > > Yes if you want a complicated CRUD perm system then you will need to > do checks on all the records you wish to display / edit and then > filter the records going out to the view. Complicated permission > systems can be complicated. However, you should be able to abstract > most of the work into a component I would think. > > In the past when I've had owner/non-owner based permissions I would > just make model methods to check if the owner of a record was correct > and then allow/deny based on that. But if your requirements are more > complicated, you will need a more complicated system. > > > > > Is there a "Best Practice" how to deal with that? > > My thoughts would be try to abstract all of this row permission > checking logic into a component that will make the rest of development > easier. Something like > > SuperAcl->checkRows($dataRows, $userData) > > or > > SuperAcl->checkRow($row, $userData) > > As long as you set some sort of convention it should work well. > > -Mark > > > > > Thanks, > > > bye > > me. > > > On Nov 20, 5:28 am, mark_story <[EMAIL PROTECTED]> wrote: > > > > This can be done with the ACL but you need to do the check manually. > > > > It may seem like a good idea to have an ACL tree that looks like > > > > controller/action/id > > > > but that is setting yourself up for an epic fail. If you ever need to > > > add an action you need to copy all the record nodes and set new > > > perms. If you make a record in a controller with 10 actions, you now > > > need 10 records. It gets insane very quickly. Some quick math also > > > shows this is the wrong approach. > > > > 150 records x 8 actions x 10 controllers = 12000 ACO elements. > > > > This is a very conservative estimate, as most applications have far > > > greater amounts of data than. A further indication of a wrong > > > approach is that this system and any proposed changes to the > > > AuthComponent fall short under the following circumstances: > > > > * when an action needs to edit more than one row > > > * when an action needs to display more than one row > > > * when an action needs to work on a record and its related records. > > > > There are probably more that I didn't think of but in all cases > > > controller/action/id is a recipe for disaster. > > > > A better approach in my opinion is to keep your controller/action > > > perms separate from your model record permissions, and do the check > > > manually. If you application is sophisticated enough to require these > > > advanced permission settings, it can stomach a few extra method calls. > > > I would use a tree like > > > > app > > > -- controllers > > > ---- posts > > > ------ index > > > ------ add > > > ------ edit > > > ---- comments > > > ------- index > > > ------- edit > > > ------- view > > > -- models > > > ---- post > > > ------ 1 > > > ------ 2 > > > ---- comment > > > ------- 1 > > > ------- 2 > > > > and so on. Another option is to use the idea of 'roles' for all your > > > access control and assign permissions with those. > > > > Sorry if I ranted a bit there, but I'm tired of people belly aching > > > that controller/action/id doesn't work when it is obviously the > > > totally wrong solution for the problem. And anyone who thinks it is a > > > great idea should go for it, and report back in a year or so after > > > their app runs into scaling issues because the ACL is ridiculously > > > complicated and impossible to deal with. > > > > -Mark > > > > On Nov 19, 9:55 am, eMarcus <[EMAIL PROTECTED]> wrote: > > > > > Hi, > > > > > I want to use the ACL component to control access of users to model > > > > data. > > > > > I built up AROs, ACOs and permissions so far. > > > > > 1.) does the ACL component automatically check if a user has an UPDATE > > > > right on save operations? > > > > 2.) if not, where would be the best place to perform that check? (in a > > > > callback function in the model itself, in the controller?) > > > > > Thanks, > > > > > bye > > > > me. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
