Django Object Permissions Proof of Concept <a href=_http_/www.flickr.com/photos/howardlake/4727110626/__Howard/index.html Lake</a>
Photo by Howard Lake

Django Object Permissions Proof of Concept

by Corey Oordt •  Published 10 Dec 2009

In the process of refactoring an app, we realized that we needed a general purpose, object-level (or row-level) permission system. So we looked around and found two: django-authority and django-granular-permissions. Django Granular permissions was closest to what we wanted, but not as complete as Django Authority. We figured we could flush out Granular Permissions and all would be well.

So one thing lead to another and it has morphed into something different. Because of the complexity of object-level or row-level permissions, we wanted to get feedback on the current proof-of-concept from the Web’s best and brightest: the Django developer community.

First the code:on github.com

For discussions, I created a public Google Wave, as it seems more appropriate than just comments on this blog or via e-mail list. Since I don’t know how to reference them any other way, search for django permission with:public. If some of you aren’t on Google Wave yet and want to comment, I do have some invites.

Now my introduction to the code: There is documentation, although it is preliminary. There is a script build_docs.sh that will build it and put it into docs/_build/html if you have Sphinx installed. It walks you through assigning permissions on your own code, or other models, granting permissions on users and groups and testing for permission.

There are unit tests, for the low-level code. There is still some testing code to write for the decorators and probably some other things I’m not thinking of.

There is an example project to use for testing, called: example. You can type ./manage.py syncdb in that directory and then ./manage.py test objectpermissions for testing, or playing.

The User and Group models get new functions:

  • grant_object_perm
  • revoke_object_perm
  • revoke_all_object_perm
  • has_object_perm
  • has_any_object_perm
  • has_all_object_perm
  • get_object_perm
  • get_object_perm_as_str_list
  • get_object_perm_as_int_list
  • get_object_perm_as_choices
  • get_objects_with_perms

The registered model has generic relations with UserPermission and GroupPermission and has user_perm_set and group_perm_set functions.

The registered model is also assigned a ModelPermission instance as perms that you can use to reference the individual permissions, or get the permissions in various formats.

There are four inline admin classes and instructions on how to modify an existing model’s registered admin class.

Concepts behind the code:

  • Permissions are registered with a model, so you don’t have to have full control over or even modify existing code.
  • Permissions are strings, but are stored as a bitwise integer behind the scenes.
  • The programmer doesn’t need to know anything about the bitwise nature of the storage, but they can do some interesting things if they do.

blog comments powered by Disqus