Row-level Model Access Control for CakePHP

Core Developer says “You Don’t Need It”

it seems that for as long as i have been using cake, i’ve been hearing people asking “how do i control access to an individual record with ACL?”. the usual response is “you aren’t doing it right if you need to restrict access to a specific row”. while this may be correct 90% of the time (due to the php/development greenhorns who use cake, but that’s a different blog post), i think it’s a bit narrowminded to think in this way. who’s to say whether or not i or my product owner want to restrict access to certain db rows? and how much of that response is due to the fact that cake’s generic ACL implemenation makes doing row level permissions a nightmare? and so, remembering the “good old days” when i used phpGACL in projects, i wondered if there was a better way to do this in cake, that doesn’t require backporting an old clunky library like phpGACL (which i’ve seen done elsewhere).

Enter the “RMAC” dragon

awhile back, i ran across this post on by Baron Schwartz, author of the excellent O’reilly book “High Performance MySQL” and various handy mysql tools. his two-part article on how to implement role based access in just sql is very intriguing, to say the least. while i like his implementation, it’s has a lot of bells and whistles that are more specific to his requirements that i would need.

around a year ago, i tasked one of my developers with adapting Baron’s implementation to fit our requirements. in the end, while it was a good stab at it, i think we still tried to make it do too much, and there were various problems with our implementation (accessing $_SESSION in a model behavior gives me shivers), but it did what we needed it to do and all was good.

for a new project we are working on i thought i would try to do this from scratch. i’ll leave off describing all the exhaustive implemenation/testing that was done to verify whether or not this can be done with cake’s built in ACL behavior/component. in a nutshell, the answer is yes, but to put it how Mark Story said “you have to know the answer to the question before you even ask it”, in that you have to query the model in question, along with the aros/acos/aros_acos table to find a list of row ids that you are able to access, and then use that as a filter for your original query. this becomes even more tedious when dealing with a tree behaviored model, because you will run into the scenario where someone may be allowed to access a node several levels deep in the tree, but disallowed access to it’s parent. you then have to decide to bypass the permissions and give the user access to read the parent node, or else change the way you save permission for each user/group to implicitly allow paths. this sucks, to say the least. after all this “research” (read: unsatisfactory implementations that made my head hurt to try to keep straight), i scrapped all of this. i have come to the conclusion that cake’s ACL is a very good generic implementation that never was explicitly intended for use with users/groups, much less roles. that is not to say you can’t, but that you probably shouldn’t. turns out the cake core developers were right (but i still think that blithely ignoring the fact that it’s just not suited for this sort of implementation is kind of naughty).

so where does this leave us? after scrapping the implementations that used cake’s generic ACL, i returned to Baron’s method and stripped it down. while i don’t have it in a “plug-n-play” state just yet, here she is, the Permissionable behavior! </trumpet flourish> (apologies for not having syntax highlighting!)

/**
 * Permission Model
 *
 * Model for manipulating permissions data
 *
 * @author      Joshua McNeese
 */
final class PermissionModel extends AppModel {

    /**
     * Permissions table
     *
     * @access  public
     * @var     string
     */
    public $useTable = 'permissions';

}

/**
 * Permissionable Behavior
 *
 * @author      Joshua McNeese
 * @since       1.0
 * @internal    $Info: $
 * @version     $Rev: $
 */
final class PermissionableBehavior extends ModelBehavior {

    public $settings    = array();
    private $__defaults = array(
        'userModel'     => 'User',
        'groupModel'    => 'Group',
        'defaultBits'   => 416      // owner_read (256) +
                                    // owner_write (128) +
                                    // group_read (32)
    );
    private $__enabled  = true;

    /**
     * Bits for various permissions.  Don't touch!
     *
     * @access  private
     * @var     array
     */
    private $__permissions = array(
        'owner_read'   => 256,
        'owner_write'  => 128,
        'owner_delete' => 64,
        'group_read'   => 32,
        'group_write'  => 16,
        'group_delete' => 8,
        'other_read'   => 4,
        'other_write'  => 2,
        'other_delete' => 1
    );

    public function setup(&$model, $config = array()) {
        $model->Permission =& ClassRegistry::init('PermissionModel');

        $config = (is_array($config) and !empty($config))
                ? am($this->__defaults, $config)
                : $this->__defaults;

        foreach($config as $k=>$v) {
            if(isset($model->{$k})) {
                $config[$k] = $model->{$k};
            }
        }

        $this->settings[$model->alias] = $config;
	}

	public function afterDelete(&$model) {
	    if(!$this->isEnabled()) {
	        return true;
	    }

        $model->Permission->deleteAll(array(
            'model'         => $model->alias,
            'foreign_key'   => $model->id
        ));
	}

	public function afterSave(&$model, $created) {
	    if(!$this->isEnabled()) {
	        return true;
	    }

	    if(
	       !defined('PERMISSION_GROUP_BITS') or
	       !defined('PERMISSION_USER_ID')
        ) {
	        return $this->backout($model);
	    }

	    $data = array();

	    if($created) {
	        $data = array(
                'model'         => $model->alias,
                'foreign_key'   => $model->id,
                'user_id'       => PERMISSION_USER_ID,
                'group_bits'    => PERMISSION_GROUP_BITS,
                'permission'    => $this->getPermissionBits($model)
	        );

	        $groupModelName = $this->settings[$model->alias]['groupModel'];
	        $userModelName  = $this->settings[$model->alias]['userModel'];

	        if($model->alias == $userModelName) {
	            $data['user_id'] = $model->id;

	            if(
	               !isset($model->data[$groupModelName]) or
	               empty($model->data[$groupModelName])
                ) {
                    return $this->backout($model);
                }

                $groupIds = array_unique(am(
                    Set::extract(
                        "/$groupModelName/$groupModelName/.",
                        $model->data
                    ),
                    Set::extract(
                        "/$groupModelName/{$model->{$groupModelName}->primaryKey}",
                        $model->data
                    )
                ));

                if(empty($groupIds)) {
                    return $this->backout($model);
                }

                $groupModel= $this->getModel($model, $groupModelName);

                if(empty($groupModel)) {
                    return $this->backout($model);
                }

                $groupBits = 0;

                foreach($groupIds as $groupId) {
                    $bitPath    = $groupModel->getpath($groupId, array('bit'));
                    $bitArray   = array_sum(Set::extract("/$groupModelName/bit", $bitPath));
                    $groupBits  = (int) $groupBits | (int) $pathBits;
                }

                if(empty($groupBits)) {
                    return $this->backout($model);
                }

                $data['group_bits'] = (int) $groupBits;
	        } elseif($model->alias == $groupModelName) {
	            $data['group_bits'] = $model->data[$groupModelName]['bit'];
	        }

	        $model->Permission->create();
	    } elseif(
	       isset($model->data['Permission']) and
	       !empty($model->data['Permission'])
        ) {
	        $data = $model->data['Permission'];

	        if(!isset($data['id']) or empty($data['id'])) {
	            $oldPermission = $model->Permission->find('first', array(
                    'conditions' => array(
                        'model'         => $model->alias,
                        'foreign_key'   => $model->id
    	            )
	            ));

	            if(empty($oldPermission)) {
	                $model->Permission->create();
	                $data['permission'] = $this->getPermissionBits($model);
	            } else {
	                $data = am($oldPermission['Permission'], $data);
	            }
	        }

	        $data = am($data, array(
	           'model'         => $model->alias,
               'foreign_key'   => $model->id
	        ));
	    }

	    if(!empty($data)) {
	        $model->Permission->save($data);
	    }
	}

	public function beforeDelete(&$model) {
	    if(!$this->isEnabled()) {
	        return true;
	    }

	    return $this->hasPermission($model, 'delete');
	}

	public function beforeFind(&$model, $queryData) {
	    if((
            isset($queryData['permissions']) and
	        $queryData['permissions'] == false
        ) or (
            isset($queryData['conditions']['permissions']) and
            $queryData['conditions']['permissions'] == false
        )) {
	        unset($queryData['conditions']['permissions']);
	        unset($queryData['permissions']);
	        return $queryData;
	    } elseif(!$this->isEnabled()) {
	        return true;
	    } elseif(!defined('PERMISSION_GROUP_BITS') or !defined('PERMISSION_USER_ID')) {
	        $queryData['conditions'] = '1=0';
	    } elseif((PERMISSION_GROUP_BITS & 1) <> 0) {
	        return true;
	    } else {
	        $alias = $model->Permission->alias;

	        $queryData['joins'][]  = array(
                'table'     => $model->Permission->table,
                'alias'     => $alias,
                'type'      => 'INNER',
                'foreignKey'=> false,
                'conditions'=> array(
                    "$alias.model = '{$model->alias}'",
                    "$alias.foreign_key = {$model->alias}.{$model->primaryKey}",
                    'or' => $this->getPermissionQuery($model)
                )
            );
	    }

	    return $queryData;
	}

	public function beforeSave(&$model) {
	    if(!$this->isEnabled()) {
	        return true;
	    }

	    $id = null;

	    if(!empty($model->id)) {
	        $id = $model->id;
	    } elseif(
	       !empty($model->data) and
	       isset($model->data[$model->alias]) and
           isset($model->data[$model->alias]['id']) and
           !empty($model->data[$model->alias]['id'])) {
	        $id = $model->data[$model->alias]['id'];
	    }

            if($model->alias == $this->settings[$model->alias]['groupModel'] and empty($id)) {
                $next_bit   = 1;
                $max_bit    = $model->field('bit', null, "{$model->alias}.bit DESC");

                if(!empty($max_bit)) {
                    $next_bit = $max_bit * 2;
                }

                $this->set('bit', $next_bit);
            }

            return (!empty($id))
	           ? $this->hasPermission($model, 'write', $id)
	           : true;
	}

	private function backout(&$model) {
	    $model->del();
	    return false;
	}

	private function getModel(&$model, $name = null) {

	    if(empty($name)) {
	        return null;
	    }

	    if(isset($model->{$name})) {
	        $theModel =& $model->{$name};
	    } else {
	        $theModel =& ClassRegistry::init($name);
	    }

	    return $theModel;
	}

	private function getPermissionBits(&$model) {
	    return (isset($model->data['permission']) and
	            !empty($model->data['permission']))
                    ? $model->data['permission']
                    : (isset($model->data[$model->alias]) and
                       isset($model->data[$model->alias]['permission']) and
                       !empty($model->data[$model->alias]['permission']))
                        ? $model->data[$model->alias]['permission']
                        : $this->settings[$model->alias]['defaultBits'];
	}

	private function getPermissionQuery(&$model, $action = 'read') {
	    $alias = $model->Permission->alias;
	    $perms = $this->__permissions;

	    return array(
            "$alias.permission & {$perms['other_'.$action]} <> 0",
            array(
                "$alias.permission & {$perms['group_'.$action]} <> 0",
                "$alias.group_bits & ". PERMISSION_GROUP_BITS ." <> 0"
            ),
            array(
                "$alias.permission & {$perms['owner_'.$action]} <> 0",
                "$alias.user_id = '". PERMISSION_USER_ID ."'"
            )
        );
	}

	public function hasPermission(&$model, $action = 'read', $id = null) {
	    if(!$this->isEnabled()) {
	        return true;
	    }

	    if((PERMISSION_GROUP_BITS & 1) <> 0) {
	        return true;
	    } elseif(empty($id) and empty($model->id)) {
	        return false;
	    }

	    $permission = $model->Permission->find('count', array(
            'recursive'     => -1,
            'conditions'    => array(
                'model'         => $model->alias,
                'foreign_key'   => (!empty($id)
                                ?  $id
                                :  $model->id),
                'or'            => $this->getPermissionQuery($model, $action)
            )
	    ));

	    return (!empty($permission) and $permission > 0);
	}

	private function isEnabled() {
	    return $this->__enabled;
	}

	private function isTree(&$model) {
	    return $model->Behaviors->attached('Tree');
	}

	public function setUserData(&$model, $data = array()) {
	    if(empty($data)) {
	        return;
	    }

	    $modelNames = am(array_values($model->tableToModel), array($model->alias));

	    foreach($modelNames as $modelName) {
	        if(!isset($this->settings[$modelName])) {
	            $this->settings[$modelName] = $this->__defaults;
	        }

	        $this->settings[$modelName]['userData'] = $data;
	    }
	}

}

How To Use

first off, there are a couple of caveats, as with anything that’s not 100% ready for release and built primarily for my use.

my app uses UUIDs, so you might need to adjust sql/code if you don’t
groups are hierarchical, and thus tree-behaviored
there must be a “root” group with a bit of 1, and a “root” user in that group. any other groups must be created as siblings to the root group (not children!)
if you use the Auth component to control your app, you’ll need to set the scope for Auth, ala: $this->Auth->userScope = array(‘permissions’ => false);
if you use this on a tree-behaviored model besides the group model, you will need to handle inherited permissions (if you want that)
there are other missing knicknacks, specifically updating the user’s group_bits when you add/remove groups, or if you add/remove the user from groups. actually, now that i think about it, removing a group won’t cause a problem, so long as you skip the removed group’s bit when adding a new group. i’ll explain why in a bit. and there isn’t a way to override the owner or group_bit for a record as of the moment. i’ll add that soon.

you will need to create the appropriate tables:

CREATE TABLE `groups` (
  `id` char(36) collate utf8_unicode_ci NOT NULL,
  `parent_id` char(36) collate utf8_unicode_ci default NULL,
  `lft` int(3) NOT NULL,
  `rght` int(3) NOT NULL,
  `name` varchar(100) collate utf8_unicode_ci NOT NULL,
  `bit` int(11) NOT NULL,
  PRIMARY KEY  (`id`),
  KEY `parent_id` (`parent_id`),
  KEY `lft` (`lft`,`rght`),
  KEY `bit` (`bit`)
) DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

CREATE TABLE `groups_users` (
  `id` int(11) NOT NULL auto_increment,
  `group_id` char(36) collate utf8_unicode_ci NOT NULL,
  `user_id` char(36) collate utf8_unicode_ci NOT NULL,
  PRIMARY KEY  (`id`),
  UNIQUE KEY `group_id` (`group_id`,`user_id`)
)  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

CREATE TABLE `permissions` (
  `id` char(36) collate utf8_unicode_ci NOT NULL,
  `model` varchar(25) collate utf8_unicode_ci NOT NULL,
  `foreign_key` char(36) collate utf8_unicode_ci NOT NULL,
  `user_id` char(36) collate utf8_unicode_ci NOT NULL,
  `group_bits` int(11) NOT NULL default '0',
  `permission` int(3) unsigned zerofill NOT NULL default '000',
  PRIMARY KEY  (`id`),
  KEY `user_id` (`user_id`),
  KEY `group_bit` (`group_bits`),
  KEY `model` (`model`,`foreign_key`)
) DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

CREATE TABLE `users` (
  `id` char(36) collate utf8_unicode_ci NOT NULL,
  `password` char(40) collate utf8_unicode_ci NOT NULL,
  `email` varchar(255) collate utf8_unicode_ci NOT NULL,
  PRIMARY KEY  (`id`)
) DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

and that’s it! well, not really. you will need to add the behavior to each model you want to be permissioned:

public $actsAs = array('Permissionable');

you will need to put this code in AppController::beforeFilter(). this will inform the behavior who the user in question is, as well as what the group_bit is for the user (we’ll explain how this works later).

if you put this in some other controller’s beforeFilter you run the risk of permissioned associated models not knowing who the logged-in user is, i don’t recommend it. i’ll be moving this to a component in all likelihood, so it doesn’t have to live directly in any controller(s).

        $modelName  = Inflector::classify($this->name);
        $user_id    = $this->Auth->user('id');

        if(
            empty($user_id) or !isset($this->{$modelName}) or
            $this->{$modelName}->Behaviors->attached('Permissionable') == false
        ) {
            return;
        }

        $mainModel  = $this->{$modelName};
        $group_bits = $this->Session->read('Permission.group_bits');

        if(empty($group_bits)) {
            $permissionModel    =& $mainModel->Permission;
            $permissionBehavior = $mainModel->Behaviors->Permissionable;
            $group_bits         = $permissionModel->field('group_bits', array(
                'model'         => $permissionBehavior->settings[$mainModel->alias]['userModel'],
                'foreign_key'   => $user_id
            ));

            if(empty($group_bits)) {
                return;
            }

            $this->Session->write('Permission.group_bits', $group_bits);
        }

        define('PERMISSION_USER_ID',    $user_id);
        define('PERMISSION_GROUP_BITS', $group_bits);

after that, any new record that is created will have a permission set, the creating user being the owner, and the groups that the user is in as the group_bit for the permission. this means that every group the user is in will have the same group level permissions that the creating user has. for example: if the record is created with the permissions of (user read/write/delete, group read/write, others read), then any member of any group that the creator is in will also have read/write permissions on that record, while the author will additionally have delete permission, and all others will have read.

now, if you want to override the default permissions, you can do so in the model by setting the $defaultBits property to the desired permission for that model. additionally, you can set $model->data[‘permission’] or $model->data[$modelName][‘permission’] to the desired permission for the row being saved.

So, how does it work, Mr. Wizard?

well, the simple answer is “bitwise”-ly. without going into tedious detail, we make use of bitwise operators in php (and sql) to determine what type of operation we are trying to accomplish (selects are reads, updates are writes and deletes are deletes), we check whether or not the user is either the owner of the row, in a group that the record in question is also in, or if “other” permissions allow them to do what they are asking. some quick examples:

group A has bit of 1 (root)
group B has bit of 2
group C has bit of 4
group D has a bit of 8
user 1 has a group_bit of 1 (root)
user 2 has a group_bit of 6 (group B + group C)
user 3 has a group_bit of 8 (group D)
record is owned by user 2, has a group_bit of 6 (group B + group C) and a permission of 416 (owner read (256) + owner write (128) + group read (32) = 416)

user 1 (root) tries to select the record. since he’s root (bit 1), he’s allowed.

user 2 tries to select record. he’s not the record owner, so permissions are checked to see if it contains the “group read” bit: (416 & 32 <> 0) == true, and then the record’s group_bit is checked to see if the user has a matching group bit: (6 & 6 <> 0) == true. both checks are true, so the user can read the row.

user 3 tries to select record. he’s not the record owner, so group permissions are checked: (416 & 32 <> 0) == true, and then group_bit is checked: (6 & 8 <> 0) == false, then other_read permissions are checked (416 & 4 <> 0) == false, so the user is denied access to the row.

probably the nicest thing about this method is that instead of having to do separate queries in a beforeFind to determine if the query should continue or how to filter the original query, all the behavior does is add a join to the query on the permissions table. all of your single queries to find matching records stay single queries. there still are pre-checks when trying to update or delete a record, but they are quick and relatively painless. there’s nothing else to really change. all your find calls will work like before, except they will only return allowed rows. save()/delete() calls will return false if the row doesn’t have write access for the user trying to do so. inserting isn’t covered by this method though, that’s where ACLs come into play… and that’s what the follow-up article will cover.

so there you have it. since this is only mostly finished, i welcome fixes, comment, critique and/or praise.

About this entry

You’re currently reading “Row-level Model Access Control for CakePHP,” an entry on some flot, some jet

Published:: April 5, 2009 / 23:20

Category:: CakePHP, PHP

Tags:: ACL, CakePHP, PermissionableBehavior, permissions, programming, RBAC

nate 4.6.09 / 5pm

As the lead developer of CakePHP, I can tell you with a fair amount of certainty that not only is this (“you aren’t doing it right if you need to restrict access to a specific row”, etc.) flat-out wrong (and no one on the team would ever say it), but it also directly contradicts the very use case that the AclBehavior class (http://book.cakephp.org/view/545/Using-the-AclBehavior) was designed for.

Please check your facts and cite your sources before making software design recommendations on behalf of other people.

jmcneese 4.7.09 / 12am

nate: i didn’t say that *you* said it, only that one of the developers did. i also didn’t say that you can’t do it, just that it becomes a nightmare (performance/management-wise), especially when using the tree behavior on the model being permissioned. consider the example i gave in the post. what if one group of users is allowed a node deep in the tree. to be able to see this node when using a UI that fetches tree nodes asynchronously for a user, you must decide to override their root node (instead of just grabbing those that have a null parent_id), or override the permission that denies them the path to get to the nested node. every scenario that i tried with AclBehavior/Component needed extra code to allows this to happen correctly. i’m not complaining, i’m just saying it didn’t work for *me* and thus this implementation. i am not dismissing cake ACL in any way, as it is still needed to limit access to actions in my controllers. i remain a steadfast cake evangelist, but everyone should be aware of the strengths and weaknesses of everything they build and that just because it rocks (as cake’s ACLs do) doesn’t mean it does everything perfectly. neither does my implementation. it’s just another option. moreover, i specifically remember you being very enthusiastic about exactly this sort of implementation done by Martin Radosta. no need to get your back up because the default implementation didn’t cut it for my requirements. it obviously didn’t cut it for Martin either, otherwise he wouldn’t have done his version of this very thing.

as far as making design recommendations, i am not aware that i did? does making the TreeBehavior available recommend it’s use? or does making an AclBehavior advocate using ACLs in your app, even if you don’t need it?

brozerman 4.7.09 / 7am

i ‘m not going to discuss the way everybody makes softwares, but jmcneese is right and i’m coming (and already ) from .net, and i’m using cakephp now since a few days . very interesting, probably more open and faster than synfony ,but how can you say “you arent’ doing right if you need….” i was digging internet since 2 days to find out how to fix it. Acl is not a correct answer (or i didn’t find it) . if you can tell me how to do it with cake acl or ?? would be interesting .i have a “tree” of companies (admin) each of them managing their own datas and allowing (editors) to add some. the admin can create and give the rights to the editors. the editors rights is (CRuD) for their own datas but (R) for the admin data (or sometimes null). we manage different companies (300) on the same website, and none of them must see the other company data and etc…..the datas are not public. i found how to fix the problem with acl for a part of it but could not fix the Superadmin (we), Admin (company) Editor (company->child) problem. how can i fix this with acl ? if you can’t bring me a solution you are welcome.

CakePHP : signets remarquables du 05/04/2009 au 06/04/2009 | Cherry on the... 4.6.09 / 6pm

[…] Row-level Model Access Control for CakePHP […]

brian (headache) 4.6.09 / 6pm

This is timely! I’ve been trying to work out how to do record-level ACL for a while now and have something almost working. But it’s certainly not looking optimatl.

I did see Mark’s post about Martin’s work, as well as these two pages:
http://www.xaprb.com/blog/2006/08/16/how-to-build-role-based-access-control-in-sql/
http://blog.joebeeson.com/?p=19

Your implementation looks very promising. I’m still sorting through this but one thing (of several, admittedly) I’m confused about is how to an admin would allow/deny access to some model based on Group.

My model uses Tree and looks something like this:

Volume::1 --Volume::1.a ----Volume::1.a.1 ----Volume::1.a.2 --Volume::1.b --Volume::1.c Volume::2 --Volume::2.a --Volume::2.b --Volume::2.c Volume::3

Basically, it’s similar to a filesystem tree. Each Volume can have one or more Item and/or Volume associated.

I have several Groups and need to be able to deny access to certain nodes of the tree. So, depending on the User’s Group, the displayed Volume tree may have some nodes missing. A node that is denied would mean that all nodes below it are also denied. This part isn’t a problem for me. But I’m struggling to see how to update the permissions table if, say, an admin wanted to deny access to Volume::1.a, and everything below it, to Group3.

Also, you say that “any other groups must be created as siblings to the root group (not children!)” but your groups table is set up for a tree (ie. parent_id). Could you explain this?

jmcneese 4.7.09 / 1am

brian: you can limit nodes by removing the subtracting the bit from the group you want to deny from the group_bit on the treenode in question. so, if your group 3 had a bit of 16, group 2 had a bit of 8, and the group_bit on Volume::1.a was 24 (16 + 8), group 3 would have access (as would group 2). to deny group 3 access, just subtract 16 from the group_bits in the permission for that tree node.

regarding “any other groups must be created as siblings to the root group (not children!)”, i guess i should have explained better. my tree looks like this (group name followed by bit).

root 1
global 2
– internal 4
— editors 8
— managers 16
– external 32
— client 1 64
— client 2 128

the reason to do this is that if all other groups were children of root, then everyone would effectively be root, due to child groups inheriting the group_bits of their parents.

brozerman 4.6.09 / 8pm

hi
i’m new on cake , i was looking for such a stuff, but i cannot make it work . Do i have to put the Acl (with the aros, acos tables) ? do i need a controller for the group and permissions ?

jmcneese 4.7.09 / 1am

brozerman: this does not fully replace cake ACLs. it only manages permissions for existing rows in a table. you will still need to use ACL to limit access to controllers/actions.

brozerman 4.6.09 / 9pm

i forgot, can you give a sample of your data in the tables .

brozerman 4.6.09 / 10pm

ok , i made it work. works fine but i don’t understand where i give my rights , i mean my “model” is :
Superadministrator (has all the rights)
Admin (has the rights for the group of user(s) his going to create , and the table(s) row(s) they manage
Editor (granted by the admin to add , delete, …rows in the table(s)
fyi : i had to create manually the “user” in the permission cause i had an error . and for the moment i manage all this rights manually , little boring , what are you suggesting ?
but you really did a great job , thanks

jmcneese 4.7.09 / 1am

i haven’t (and most likely will not be) released any sort of management for this. the behavior just uses the permissions/groups of the user who created the record, and alternately using passed data to permissioned model. if you want to be able to change the permissions or group_bits on a particular row, you’ll need to implement some way of doing this yourself, sorry! it’s definitely not a complete solution, and still has nuts and bolts that need adding.

that being said, make sure you understand the way that it works. this behavior expects that there is one group for users (‘User’ is default), and one for groups (‘Group’ is default). User hasAndBelongsToMany Group. the behavior sees if you are associating a user to a group, and recalculates the group_bit for that user’s permission. this works exactly like unix filesystem permissions, with the exception that objects can be owned by multiple groups (whereas unix only allows one group id per file/directory) and the ‘execute’ bit is replaced by ‘delete’.

1. brozerman 4.7.09 / 7am
  
  thanks for your answer,
  just something that i wasn’t awaiting for : when you use a table in a listbox (with the form magic) all the rows a in the list box. it’s easy to fix , did you try it in a form ?

jmcneese 4.7.09 / 5am

a little update: https://jmcneese.wordpress.com/2009/04/07/update-row-level-model-access-control-for-cakephp/

stebu 4.9.09 / 4am

hi jmcneese,
thanks for this implementation.
there is a syntax error in your sql-statement to create the users table. after “PRIMARY KEY (`id`)” there is a comma, which is not accepted in my sql.
best!
stebu

jmcneese 4.9.09 / 8am

thanks stebu, original post is updated.

chanakya 12.26.09 / 10am

Great Thanks, was looking for something like this.
Now to try and convert this for Zend framework, or does Zend already have something like this? 🙂

Joshua McNeese 12.26.09 / 11am

no idea 🙂

Dennis Gearon 12.17.10 / 12pm

No, Zend does not have something liket this, according to Google, as of 2010-12-17.

I’m thinking of doing something like this, but more like the way a database does it (or Postgres that is). ANY group can be assigned any permissions to the objects, not just one group,

If I read it right, yours is like *nix filesytems, One owner, and one group can have it’s permimssions set for an object.

One thing that I did NOT see in your implementation is the file system equivilent of DIRECTORY permissions, i.e. the contatiner permissions. Probably you’re using Cake’s ACL for that on module/actions, right?

I’m using Symfony. My opinoin is that Zend, Symfony, and Cake all are based on the ‘One CompanyDivision per Site’ model. But it a site has GROUPS of users, or different COMPANIES, than all the module/action stuff becomes very limited.

The module/action model of security ony applies to the SITE, not really to its content. RBAC/RLAC implementations can become VERY complex, especially for hiearchial models. I’m thinking of just stopping at a root model access and letting users have access only THROUGH that root model. My needs are simple enough for that.

Now that I had the brainstorm for Postgres, I’m going to look at their system tables and see what’s there. 🙂

League 5.10.12 / 11pm

As controversial as this topic is, there are cases where row level permissions are needed. I have a situation similar to one mentioned in the comments with multiple companies accessing a single web app. Also, Oracle database has a built-in solution for row level permissions called Fine-Grain-Access Control. My implementation is different than the one here; it uses per-user MySQL accounts (this isn’t as onerous as it sounds) and triggers and views to handle all the row-level access control entirely at the database level. There is a bit of logic in AppController and AppModel to ensure the right account is used to connect to the database, but other than that CakePHP works as normal. I’ve written this up in more detail but haven’t published it; if anyone wants more information contact me. Thanks for this code and the reference to Baron Schwartz’s work.

Leslie Sanford 7.19.12 / 7am

$modelName = Inflector::classify($this->name);

This line of code in the AppController assumes that the target model can be derived from the controller’s name. Is this always the case? I have a few controllers whose name are not directly derived from a model; many of those controllers work with more than one model.

So in order for your approach to work, do you have to make certain assumptions about your controller and follow certain conventions when creating those controllers?

Joshua McNeese 7.19.12 / 6pm

it is definitely the assumption in the code as it currently is. i can easily imagine a configuration option that, if left null, would default to deriving the default model from the controller’s name. i accept pull requests on github! 🙂

Database row access controll in cakeph way. « Codeperl's Knowledge Sharing System 7.24.12 / 11pm

[…] row access controll in cakeph way.https://jmcneese.wordpress.com/2009/04/05/row-level-model-access-control-for-cakephp/ Like this:LikeBe the first to like this. […]

some flot, some jet

Row-level Model Access Control for CakePHP

Core Developer says “You Don’t Need It”

Enter the “RMAC” dragon

How To Use

So, how does it work, Mr. Wizard?

About this entry

22 Comments

Leave a reply to jmcneese Cancel reply

recent tweets

Meta

Recently

Categories

some flot, some jet

Row-level Model Access Control for CakePHP

Core Developer says “You Don’t Need It”

Enter the “RMAC” dragon

How To Use

So, how does it work, Mr. Wizard?

Share this:

Related

About this entry

22 Comments

Leave a reply to jmcneese Cancel reply

recent tweets

Meta

Recently

Categories