This built-in permission system is simple; as in you shouldn’t expect complex authorization schemes to be implemented easily. It is mainly used by django.contrib.admin and you can use it without any hassle for your very simple authorization requirements. Beauty of this permission system is it’s simplicity. Here are a few strong points:

• All your models get add, change and delete permissions created automatically.¹ These three are all you need for most of your models.
• Admin uses permissions internally. But more importantly permissions can be granted/revoked dynamically via admin.
• Simple design encourages you to keep authorization scheme clean.²

The last point is very important; permissions shouldn’t leak into business logic. If you have a project that goes beyond a CMS, you probably have business objects. Business objects might have quite complex states and typically interact with each other in more than straightforward ways. On the other hand models in CMS style projects have simple states that are independent (of other models). Take a blog post; it is either published or not and its author is simply a ForeignKey to Users. If you depend heavily upon permissions for complex state transitions of your models you will soon find yourself in a dead end.

Permissions in Fixtures

One problem, and it’s a big problem, I’ve had with permissions is that; you can’t store permissions in fixtures. Here is what happens:

1. Relationships are stored in fixtures as primary keys.
2. Permission are created by the framework programmatically in a specific order.
3. When you add/delete a new model or add/delete a custom permission this order changes.
4. Therefore primary keys of permissions change.
5. As a result permission data in your fixture are invalid.

I’m a big fan of fixtures. More often than not you have some models that will be used as definitions (they’re partially fixed data) or you want to kickstart your project with placeholder data. It’s quite easy in Django. After creating your models, launch admin and create your data. Then simply dumpdata, maybe post-process a little bit and you have your initial_data! Not so easy if you have permissions in that basket.

Best solution I can come up with now is to hook a post_syncdb function and add your permissions programmatically.

Authorization

Basic usage of permissions is to check if a user has a certain Permission and branch accordingly:

@login_required
def some_view(request):
    user = request.user
    if user.has_perm('foo.bar_baz'):
        # go on and bar that baz
    else:
        # display an error message
    # ...rest of the view

When you need to combine conditions, it is a good idea to abstract authorization check in a function:

class Foo(models.Model):
    # stuff that goes into a model

    def can_bar(self, user):
        return user.has_perm('app.bar_foo') and user.baz >= self.baz

You can combine this with techniques explained in here and here to achieve column level permissions.

Row level permissions are cooking as well. There is a branch for per object permissions. You can checkout this branch from subversion with the following command:

svn co http://code.djangoproject.com/svn/django/branches/per-object-permissions

Generic Permissions

Let’s define permissions problem in a more generic way. A permission determines if:

• An actor can
• Perform an action
• On an object
• Depending on arbitrary number of runtime conditions [optional]

In our little implementation actors will be auth.User instances and objects, naturally, models. Actions will simply be keys of string type. Because of the possibility that our permission can have conditions, it should be a callable. Then we will have all the power Python/Django has.

Let’s place our permissions on our models:

   1 class FooPermissions(PermissionMixin):
   2     def __warg(self):
   3         return max(self.quux - self.parent.quux, 1)
   4 
   5     @staticmethod
   6     def allows_bar_for(actor):
   7         return actor.has_perm('app.bar_foo') and actor.status == 'barrable'
   8 
   9     def allows_baz_for(self, actor):
  10         if self.qux_set.count() > 10:
  11             return True
  12         else:
  13             return self.__warg() > 5 or actor.is_staff
  14 
  15 
  16 class Foo(models.Model, FooPermissions):
  17     # fields, managers, etc...

First we created a permissions mixin, subclassing a PermissionMixin I’ll show it to you in a minute, and mixed it with our model definition. This way we keep permissions seperate at the source level. Also, for instance __warg method will not be accessible from our model. You can do anything inside your permissions class, you can even have side effects if you like. all you have to do is to follow a naming convention for your permission methods. Here is the PermissionMixin class:

   1 from django.contrib.auth.models import User
   2 
   3 
   4 class PermissionError(StandardError):
   5     pass
   6 
   7 
   8 class PermissionMixin(object):
   9     def attempt(self, action, actor, msg=None):
  10         return PermissionMixin._attempt(self, action, actor, msg=None)
  11 
  12     @classmethod
  13     def cls_attempt(cls, action, actor, msg=None):
  14         return PermissionMixin._attempt(cls, action, actor, msg=None)
  15 
  16     @staticmethod
  17     def _attempt(obj, action, actor, msg):
  18         if actor.__class__ != User or not isinstance(action, basestring):
  19             raise TypeError
  20         if getattr(obj, 'allows_%s_for' % action.lower().replace(' ',
  21                                                                  '_'))(actor):
  22             return True
  23         else:
  24             if msg is None:
  25                 msg = u'%s doesn\'t have permission to %s %s' % (actor.username,
  26                                                                  action.lower(),
  27                                                                  repr(obj))
  28             raise PermissionError(msg)

When you want to check for a permission you just need it’s key (name of the action) and have your User at hand:

# Check a permission on a model:
Foo.cls_attempt('bar', user)

# Check a permission on an instance:
foo.attempt('baz', user)

Notice that we are still using Permissions from auth. Our PermissionMixin can do complex logic, but its hard-coded. We still need something like Permissions for dynamic behaviour. Why not use what’s built-in?

You can find PermissionMixin‘s code at Django snipplets.

Conclusion

Before employing a similar mechanism, you should think hard if you absolutely positively need it. Maybe you can simplify your UI? Maybe there is a nice tradeoff between code complexity and interactivity of your application? Maybe you can move this logic into model.save() or form.save() or form.clean()? Or maybe your code will be best organized if you use PermissionMixins.

I just wanted to show that you can build on auth‘s Permissions. Just don’t get discouraged when you find out you can’t do x out of the box. Be it permissions or some model magic or making something available in your templates; Django is Python, it can be extended easily.

1: Provided you have auth app installed of course.

2: Ask yourself; “Is this really a must?”, and not only for permission related complications.

Related posts:

1. Working with files in Django – Part 1
2. Working with files in Django – Part 2
3. Working with files in Django – Part 3