This is a simple alternative to django-rules. The core difference is that it uses as registry that can be modified on runtime, instead of database models.
One of the goal is to enable developpers of external apps to make rules, depend on it, while allowing a project to override rules.
# Everybody can read a blog post (for now!): rules_light.registry['blog.post.read'] = True # Require authentication to create a blog post, using a shortcut: rules_light.registry['blog.post.create'] = rules_light.is_authenticated def is_staff_or_mine(user, rule, obj): return user.is_staff or obj.author == user # But others shouldn't mess with my posts ! rules_light.registry['blog.post.update'] = is_staff_or_mine rules_light.registry['blog.post.delete'] = is_staff_or_mine
@rules_light.class_decorator class PostDetailView(generic.DetailView): model = Post @rules_light.class_decorator class PostCreateView(generic.CreateView): model = Post @rules_light.class_decorator class PostUpdateView(generic.UpdateView): model = Post @rules_light.class_decorator class PostDeleteView(generic.DeleteView): model = Post
You might want to read the tutorial for more.
What's the catch ?
The catch is that this approach does not offer any feature to get secure querysets.
This means that the developper has to:
- think about security when making querysets,
- override eventual external app ListViews,
- Maintained against Python 2.7
- and Django 1.4+
- Install module: pip install django-rules-light,
- Add to settings.INSTALLED_APPS: rules_light,
- Add in settings.MIDDLEWARE_CLASSES: rules_light.middleware.Middleware,
- Add in urls.py: rules_light.autodiscover(),
You might want to read the tutorial.
There is also a lot of documentation, from the core to the tools, including pointers to debug, log and test your security.
You could subscribe to the mailing list ask questions or just be informed of package updates.