Wednesday, September 28, 2011

Re: Record level ACL

On Sep 28, 8:20 pm, jmcneese <jmcne...@gmail.com> wrote:
> hi there.  it looks to me that you are not using the groups correctly,
> which is how you restrict non-owner users from undesired actions.  the
> bits are just like unix permission bits, in that there is there is a
> user and group id associated with the record, then bits assigned to
> the owner, group and "others" (anyone who is not the owner or in the
> group specified).
>
> a practical example would be something like this:
>
> you create a new record.  that permission record gets automatically
> created with an owner id matching the creating user's id, and a group
> id matching the creating users *primary* group id.  the permission
> bits for this new record will either be the default bits defined in
> the behavior configuration, or else whatever you specify in the data
> to be saved.
>
> let's say you have two groups, Editors and Authors.  you would want
> editors to have full read write access, as well as the creating
> author, but everyone else can only view. that would mean you want to
> have a permission bit of 500 (owner: read/write/delete, group: read/
> write, others: read).  the owner id is the author user's id who
> created the record, and the group id is the editor group's id.
>
> this would allow the original author to have full control, editors can
> modify the record but not delete, and all other users can read the
> record but not modify/delete.
>
> does that make more sense?


Hi,
First of all my thanks to the wonderful behavior and reply. I
understood the bit masking part. If you see my previous posts i have
mentioned how the 9 bits works. I am clear about that. But where i
need help is when a record owner wants to assign permission to another
set of groups or users or a single group or user for CRUD on all his
inserted record (data) how can he do that? I am planning for an
interface where the record owner allows permission for his inserted
record to a selected group or users. More than that, you have
mentioned in your TODO list as

"I intend on updating the plugin to have more options for
configuration, to whit: implementing some level of inheritable
permissions, introducing the concept of roles, supporting "trickle-
down" permission changes to models that actAs Tree, common UNIX-y
commands like chmod/chown/chgrp."

Please explain more on this points. Though I am a beginner in cakephp
(just 2 months) I could try those TODO for my knowledge gain.

>
> On Sep 28, 5:41 am, sathyashrayan <sathyashra...@gmail.com> wrote:
>
>
>
>
>
>
>
> > On Sep 28, 12:25 pm, sathyashrayan <sathyashra...@gmail.com> wrote:
>
> > > On Sep 28, 11:39 am, sathyashrayan <sathyashra...@gmail.com> wrote:
>
> > > > Ok I have made the RMAC work (http://jmcneese.wordpress.com/2010/01/28/
> > > > rmac-is-dead-long-live-rmac/) I will tell what i have done.
>
> > > > 1)Downloaded a fresh cakephp
> > > > 2)created the users,groups tables
> > > > 3)acos,aros,acos_aros ("cake schema create DbAcl" in command line)
> > > > 4)Baked users and used Auth component to set up a login page
> > > > 5)Placed the plugin in [path]/app/plugin/permissionable
> > > > 6)Created the permission_bits table
> > > > 7)Created a "contacts" table for a sample module
> > > > 8)In the file [path]\app\plugins\permissionable\controllers\components
> > > > \permissionable.php I added
> > > >    var $components = array('Session', 'Auth');
> > > >   for calling
> > > >     $users = $this->Auth->user();
> > > >   Then assigned userid and groupid in
>
> > > >                  $users = $this->Auth->user();
> > > >                  $userId = $users['User']['id'];
> > > >                  $groupId = $users['User']['id'];
> > > >                  Permissionable::setUserId($userId);
> > > >                  Permissionable::setGroupId($groupId);
> > > >                  Permissionable::setGroupIds(array($groupId));
>
> > > > 9)Created some groups in tree (tree component) with hierarchy
>
> > > > 10)Now each user logged in and creates a contact  the
> > > > "permission_bits" table gets filled with model,and model Id and 416
> > > > (default bits) in perms..
>
> > > > 11)If each user logs in and he can see only his records. He can edit
> > > > and view but he can not delete his own record. If an Admin logs in he
> > > > can do all the action(delete also) on all the record including his
> > > > record..
>
> > > > Now what i need is..
>
> > > > 1)Record created user (owner) can also delete his record
>
> > > Ok i have found out doing this point. Which is 480 in the prems coloum
> > > of permission_bits table.
> > > 840 == (111) - (100) - (000). Add the line before calling save ($this-
>
> > > >Contact->save($this->data)) in the contact_controller..
>
> > > $this->data['Permissionable'] = array('perms'=>480);
>
> > > > 2)Record created user (owner) can allow other group's user below his
> > > > level to do all the action (create/update/delete/view)
>
> > > > I can guess that this could be done in the Behavior (\app\plugins
> > > > \permissionable\models\behaviors\permissionable.php) with correct bit
> > > > set in the callback functions. But i dont know what is the bit mask
> > > > for that. If i am wrong then please correct me and guide me how to do
> > > > that.
>
> > ok I got a bit more closer in this. I have changed the
>
> > Permissionable::setUserId(array($userId,6,7)); in the file
>
> > [path]\app\plugins\permissionable\controllers\components
> > \permissionable.php
>
> > where 6,7 are other user IDs I get the following query generated with
> > beforeFind() callback function from the file [path]\app\plugins
> > \permissionable\models\behaviors\permissionable.php
>
> > SELECT `Contact`.*, `ContactPermissionBit`.* FROM `contacts` AS
> > `Contact` INNER JOIN `permission_bits` AS `ContactPermissionBit` ON
> > (`ContactPermissionBit`.`foreign_id` = `Contact`.`id` AND
> > `ContactPermissionBit`.`model` = 'Contact' AND
> > `ContactPermissionBit`.`foreign_id` = `Contact`.`id` AND
> > ((`ContactPermissionBit`.`perms`&4 <> 0) OR
> > (((`ContactPermissionBit`.`perms`&32 <> 0) AND
> > (`ContactPermissionBit`.`gid` = 2))) OR
> > (((`ContactPermissionBit`.`perms`&256 <> 0) AND
> > (`ContactPermissionBit`.`uid` IN (2,6,7)))))) WHERE 1 = 1 LIMIT 20
>
> > Look at the last part of the query IN (2,6,7) that happens with the
> > array of user ids. But this will affect the afterSave() callback in
> > [path]\app\plugins\permissionable\models\behaviors\permissionable.php
> > since it expects a variable but not an array. So I have changed the
> > code to check if its a array or variable. Just added these lines on
> > the top.
>
> >         //$user_id    = Permissionable::getUserId();
> >         //$group_id    = Permissionable::getGroupId();
>
> >         if(is_array(Permissionable::getUserId()))
> >         {
> >             $ids_user = Permissionable::getUserId();
> >             $user_id = $ids_user[0];
> >         }
> >         else
> >         {
> >             $user_id    = Permissionable::getUserId();
> >         }
>
> >         if(is_array(Permissionable::getGroupId()))
> >         {
> >             $ids_group = Permissionable::getGroupId();
> >             $group_id = $ids_group[0];
> >         }
> >         else
> >         {
> >             $group_id    = Permissionable::getGroupId();
> >         }
>
> > So now this works on both afterSave() and beforeFind() callback
> > function, never minding if it is a array or variable.
> > Now if user id 2 is the leader and user id 6 and 7 are under the
> > privilege of user 2. How can i restrict some resource for the other
> > users such as no deleting possible for 6,7 but only view. But user id
> > 2 could do all the CRUD since he is the master for this record? I
> > think I need to make a bitmask for this in perms but where in
> > afterSave() and what is that bit?
>
> > I wounder why I am not getting any help for this issue.. May be people
> > here did not able to open the link which is
>
> >http://jmcneese.wordpress.com/2010/01/28/rmac-is-dead-long-live-rmac/...
>
> > Please help..:o
>
> > > > One more this is when a admin delets all the record the
> > > > "permission_bits" table not getting deleted..
>
> > > > Thanks for any help..
>
> > > > On Sep 26, 5:04 pm, sathyashrayan <sathyashra...@gmail.com> wrote:
>
> > > > > Dear group,
> > > > >  After i used ACL plugin by Alaxos (http://www.alaxos.ch/blaxos/pages/
> > > > > view/plugin_acl) i wanted to have a ACL at each record level. That is,
> > > > > a user's record need not be shown to the non-Creator. I started to
> > > > > understand the concept of record level ACL from  this thread.
>
> > > > >  http://groups.google.com/group/cake-php/browse_frm/thread/886fe37ecbc...
>
> > > > >  After downloading those code from those given links about RMAC i
> > > > > tried to implement it. But I am stuck. So i started to read that code
> > > > > (behaviour, [path]/app/plugin/permissionable/models/behaviors) i
> > > > > understood that its the callback function that does all. Especially
> > > > > the bit checking in _getPermissionQuery function. But I am still not
> > > > > clear in implementation(user end). So i studied the Auth and ACL
> > > > > component in core cake (libs) and i saw the _create,_delete (CRUD)
> > > > > permission is set in Auth. Then I understood that RMAC implementation
> > > > > is different from Core ACL which uses aros_acos table. My doubt with
> > > > > the RMAC plugin is this.. Does every record will have an extra entry
> > > > > in the permission table? Can anyone give an example of this full
> > > > > working of the RMAC code, with more than two or three model (tables)
> > > > > with tree level access (roles) including every entry in the permission
> > > > > table. Can I able to use both the ACL plugin and RMAC plugin together?
>
> > > > >  I am also planing to have own interface for the ACL, both action
> > > > > level and record level. I am not sure if this will be continued since
> > > > > i work for a company and they asked so. It could be dropped any time.
> > > > > A basic layout as follows in a word docs.
>
> > > > >https://docs.google.com/document/d/1VGkvtvZk3fuST_pgn1q0sfhtvgka1NCTY...
>
> > > > > This is very basic and it could be non feasible (funny :D).

--
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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php

No comments: