Aran, then my apologies to you as well. The internet is a terrible place to decipher intonation. Its easy to misconstrue a question as complaining, and it doesn't help that I've been asked that question 10+ times.
I think that only in complicated systems should row level permissions be implemented at an ACL level. There is alot of overhead in using the DB ACL and it complicated not only application design but application development. So if you can avoid row level ACL you should. -Mark On Nov 20, 3:40 pm, aranworld <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
