There is one problem with nesting records underneath each action. Your Aco table becomes enormous, and if you add actions / controllers to your application you end up with a monstrous mess. I think its best to keep a separate branch of
models --- posts ------ 1 ------- 2 etc. And set the crud perms there. Doing it on a per record per action basis is definitely not dry and will cause more headaches than it solves. -Mark On Sep 8, 9:48 pm, aranworld <[EMAIL PROTECTED]> wrote: > I while ago I submitted an enhancement ticket regarding this: > > https://trac.cakephp.org/ticket/3857 > > Since then I have gone back and forth on whether I think it should be > universal or just handled on an individual basis. > > Anyways, if you check out the ticket, there are some patches which > might give you some direction in how to put together your own modified > AuthComponent that does pass along the id. > > -Aran > > On Sep 8, 9:23 am, luke BAKING barker <[EMAIL PROTECTED]> wrote: > > > aranworld - I am wondering how this could be made universal throughout > > an app...better possibly in the app_model somehow? but obvioulsy Auth > > is a component :/ > > > On Aug 28, 8:22 am, aranworld <[EMAIL PROTECTED]> wrote: > > > > You can add this to your UsersController: > > > > function __checkUsersOwnRecord($recordId = null) { > > > if( $this->Auth->user('id') == $recordId ){ > > > return TRUE; > > > } else { > > > return FALSE; > > > } > > > > } > > > > Give all users access to users/edit ... however, before you do any > > > edit functionality first check that the logged inuseris the sameuseras > > > the record being edited. > > > > The basic answer is that since theAuthComponent does not look at the > > > record ID when it verifies access, then you cannot rely on it to > > > automatically handle record level access, and you therefore have to > > > create such logic on your own. > > > > On Aug 12, 5:02 am, [EMAIL PROTECTED] wrote: > > > > > I have the same problem, but let us take a look to the debug messages: > > > > (we say thatusermodel must behave as "requester", and in the model > > > > it's written > > > > var $actsAs = array('Acl' => array('type'=>'requester')); > > > > ) > > > > So the debug is > > > > > SELECT `Aro`.`id`, `Aro`.`parent_id`, `Aro`.`model`, > > > > `Aro`.`foreign_key`, `Aro`.`alias` FROM `aros` AS `Aro` LEFT JOIN > > > > `aros` AS `Aro0` ON (`Aro`.`lft` <= `Aro0`.`lft` AND `Aro`.`rght` >= > > > > `Aro0`.`rght`) WHERE `Aro0`.`model` = 'User' AND `Aro0`.`foreign_key` > > > > = 29 ORDER BY `Aro`.`lft` DESC > > > > > here 29 is id of theuserrequesting some permissions > > > > ok, works perfectly > > > > > then > > > > > SELECT `Aco`.`id`, `Aco`.`parent_id`, `Aco`.`model`, > > > > `Aco`.`foreign_key`, `Aco`.`alias` FROM `acos` AS `Aco` LEFT JOIN > > > > `acos` AS `Aco0` ON (`Aco0`.`alias` = 'Users') WHERE `Aco`.`lft` <= > > > > `Aco0`.`lft` AND `Aco`.`rght` >= `Aco0`.`rght` ORDER BY `Aco`.`lft` > > > > DESC > > > > > Here you see `Aco0`.`alias` = 'Users'!!! but it's not true, i do not > > > > want to request permissions on the whole users group, i'm interested > > > > only in > > > > aco with alias, say,User::29, or, i would say it must be better, in > > > > aco with foreign_key=29 > > > > > so then as a consequence we have > > > > > SELECT `Permission`.`id`, `Permission`.`aro_id`, > > > > `Permission`.`aco_id`, `Permission`.`_create`, `Permission`.`_read`, > > > > `Permission`.`_update`, `Permission`.`_delete`, `Aro`.`id`, > > > > `Aro`.`parent_id`, `Aro`.`model`, `Aro`.`foreign_key`, `Aro`.`alias`, > > > > `Aro`.`lft`, `Aro`.`rght`, `Aco`.`id`, `Aco`.`parent_id`, > > > > `Aco`.`model`, `Aco`.`foreign_key`, `Aco`.`alias`, `Aco`.`lft`, > > > > `Aco`.`rght` FROM `aros_acos` AS `Permission` LEFT JOIN `aros` AS > > > > `Aro` ON (`Permission`.`aro_id` = `Aro`.`id`) LEFT JOIN `acos` AS > > > > `Aco` ON (`Permission`.`aco_id` = `Aco`.`id`) WHERE > > > > `Permission`.`aro_id` = 5 AND `Permission`.`aco_id` = (1) ORDER BY > > > > `Aco`.`lft` desc > > > > > where we have correct aro_id and incorrect aco_id > > > > > so it seemsUsermodel must behave as a "requester" and as a > > > > "controlled", but you cannot define such a behaviour (at least i don't > > > > know how) > > > > > reasonable solutions are to check permissions in such a situations > > > > yourself (but i cannot switch off auto check!), to define additional > > > > model like profile or to make some correction in some cake files > > > > (still don't know where) > > > > > any suggestions? > > > > > On Aug 8, 6:31 am, KoPanda <[EMAIL PROTECTED]> wrote: > > > > > > Yes, I'm using "crud" mode inAuth. The Aro and Aco trees are like > > > > > this. > > > > > > Aro > > > > > > users > > > > > |- user1 > > > > > |- user2 > > > > > |- administrators > > > > > |----- admin > > > > > > Aco > > > > > > Site > > > > > |- Users > > > > > |-----user1 > > > > > |-----user2 > > > > > > The permissions were setup like this, > > > > > > cakeaclgrant administrator Site * > > > > > cakeaclgrant users Site read > > > > > > And then in the register() action after saving theuserdata, > > > > > > //Usermodel is define with $actAs = array('Acl' => 'requester') so > > > > > the Aro is automatically handled > > > > > // some code to create the aco and set the $alias to the username > > > > > $this->Acl->allow($alias, $alias, array('read','update')); > > > > > > For example, ARO user1 would have "read" and "update"permissionto > > > > > ACO user1. I supposeAuthwould check through the tree and see if ARO > > > > > user1 can update ACO user1 and then allow edit() action when I do / > > > > > users/edit/5 (suppose user1 has id:5). But that's not the case. It > > > > > kicks me back to /users/view/5, as ARO user1 has "read"permissionto > > > > > ACO Users. If I want to make /users/edit/5 runs as I wish, I have to > > > > > grant "update"permissionto Users controller, which eventually let > > > > > all users to edit any records of other users. > > > > > > Well, I know I can do an extra check() in edit() action and see if the > > > > > currentuserhas updatepermissionto the record but I don't > > > > > understand why theAuthcomponent acts like this. Is my approach > > > > > wrong? OrAclandAuthare not supposed to do the work like this? > > > > > > On Aug 8, 2:29 am, francky06l <[EMAIL PROTECTED]> wrote: > > > > > > > You have to set (or use) the right mode toAuth, in this case "model" > > > > > > or "crud". > > > > > > > On Aug 7, 12:02 pm, KoPanda <[EMAIL PROTECTED]> wrote: > > > > > > > > I'm trying to develop a community website usingcrudmode onAuth > > > > > > > component.Userprofiles can be viewed by all users while only be > > > > > > > edited by the profile owner and administrator. I followed anAcl > > > > > > > tutorial from Bakery > > > > > > > >http://bakery.cakephp.org/articles/view/how-to-use-acl-in-1-2-x > > > > > > > > to setup theAcl, createuseralias in aco and aro under Users, and > > > > > > > allow 'read' and 'update'permissionto the aco. However,Auth > > > > > > > component doesn't check thepermissionin the record. It only checks > > > > > > > if Users controller in aco can be updated. It won't let a > > > > > > > normaluser > > > > > > > to edit his ownuserprofile. If I allow users to update Users, > > > > > > > normal > > > > > > > users can run edit() on alluserprofile. > > > > > > > > Why is that? In the understanding,Authshould check the permissions > > > > > > > from theAclroot to all the leaves. Why it stops checking when the > > > > > > > controller won't let it to update while the actual record is set > > > > > > > with > > > > > > > 'update'? Or is there any other suggestedAclmodel for my > > > > > > > situation? > > > > > > > > Thanks! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
