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?
On Sep 28, 5:41 am, sathyashrayan <sathyashrayan@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/http://jmcneese.wordpress.com/2009/04/19/rmac-ftw-part-1/
>
> 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:
Post a Comment