Simple Data Access Control

Posted by Felix Geisendörfer, on Aug 25, 2008 - in PHP & CakePHP » Auth, Acl & Permissions

Hey folks,

this is post #6 of my 30 day challenge.

If your application is like most, then you have some basic permission requirements for your data. A simple scenario is the following. Blog posts can only be edited by their owners and administrators. Same goes for viewing unpublished blog posts. Given that requirement I usually wrote code like this in the past:

php
  1. class PostsController extends Controller{
  2.   function view($id = null) {
  3.     $post = $this->Post->findById($post);
  4.     Assert::notEmpty($post, '404');
  5.     $ownPost = $post['Post']['user_id'] == User::get('id');
  6.     Assert::true($post['Post']['published'] || ($ownPost || User::isAdmin()), '403');
  7.   }
  8.  
  9.   function edit($id = null) {
  10.     $post = $this->Post->findById($post);
  11.     Assert::notEmpty($post, '404');
  12.     $ownPost = $post['Post']['user_id'] == User::get('id');
  13.     Assert::true($ownPost || User::isAdmin(), '403');
  14.   }
  15. }

Note: See this post about the Assert implementation. If you wonder about the User::get('id') call - that is part of our custom Auth system we hope to publish at some point.

One could argue that the above is not ideally DRY and therefor should be refactored. In the past I probably would have followed that logic. However, these days I'm more often like fuck DRY if a little dupplication here and there makes code easier to read and to maintain (yes, that is very much possible with certain one liners).

Anyway, what I don't like about the above is that I feel the logic for deciding record permissions falls into the Model realm. It simply makes more sense if you think of it as a business requirement which should be abstracted in the model layer. So here is how I deal with the problem these days:

php
  1. class User extends AppModel{
  2.   static function can($action, $record, $options = array()) {
  3.     if (is_string($options)) {
  4.       $options = array('model' => $options);
  5.     }
  6.     $options = array_merge(array(
  7.       'action' => $action,
  8.       'model' => key($record)
  9.     ), $options);
  10.     if (method_exists($options['model'], 'userCan')) {
  11.       return call_user_func(array($options['model'], $method), $record, $options);
  12.     }
  13.     return $record[$options['model']]['user_id'] == User::get('id');
  14.   }
  15. }
  16.  
  17. class Post extends AppModel{
  18.   static function userCan($record, $options) {
  19.     if ($options['action'] == 'view' && $record['Post']['published']) {
  20.       return true;
  21.     }
  22.     return ($record['Post']['user_id'] == User::get('id')) || User::isAdmin();
  23.   }
  24. }
  25.  
  26. class PostsController extends Controller{
  27.   function view($id = null) {
  28.     $post = $this->Post->findById($post);
  29.     Assert::notEmpty($post, '404');
  30.     Assert::true(User::can('view', $post), '403');
  31.   }
  32.  
  33.   function edit($id = null) {
  34.     $post = $this->Post->findById($post);
  35.     Assert::notEmpty($post, '404');
  36.     Assert::true(User::can('edit', $post), '403');
  37.   }
  38. }
  39.  

This is quite some code for this refactoring, yet I found it extremly nice to work with this pattern torwards data access control. It is fairly light weight compared to most other approaches, yet gives you a per-Model and per-Context kind of flexibility on access control.

Let me know if you have any questions!

HTH,
-- Felix Geisendörfer aka the_undefined