Mark, Aran, Is there a way to access the Acl component from within a model?
Models don't have a $uses attribute, do they? Can I somehow else access the Acl component in a model (ie. creating an instance with new() ? The beforeSave() callback method would be a perfect place to check if a user would have an UPDATE right for a specific record.... bye me. On Nov 21, 3:46 pm, mark_story <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
