Permissions interface¶
The surface area of the django-tutelary permissions management part of the example application is surprisingly small:
Model annotations¶
The permissioned_model
decorator or function is used to register
action names for models and to provide django-tutelary with the
information it needs to derive object paths for model instances.
View permissioning¶
We use the PermissionRequiredMixin
in all of our view classes to
enable django-tutelary permission checking for them. We only need to
derive our own mixin here because we want custom behaviour in “no
permissions” cases.
Policy handling¶
Policies are at the heart of django-tutelary, and all applications using policy-based permissions need to manage them somehow. I’ve tried not to impose any real requirements on this aspect of applications that use django-tutelary: policies are just normal Django models, and you can manage them more or less as you want in your applications. The example application manages django-tutelary policies as just another kind of object, using common CRUD operations (themselves permissioned by django-tutelary).
Custom backend¶
We need to enable the django-tutelary permissions backend in our settings file. In the example application, we further derive a custom backend to allow for switching between users without authentication for the purposes of the example.