Public Django interface

Policies

class tutelary.models.Policy(*args, **kwargs)

An individual policy has a name and a JSON policy body. Changes to policies are audited.

body = None

Policy JSON body.

name = None

Policy name field.

class tutelary.models.Role(*args, **kwargs)

A policy role has a name, a sequence of policies and a set of variable assignments. Changes to roles are audited.

name = None

Role name field.

variables = None

JSON dump of dictionary giving variable assignments for role.

tutelary.models.assign_user_policies(user, *policies_roles)

Assign a sequence of policies to a user (or the anonymous user is user is None). (Also installed as assign_policies method on User model.

tutelary.models.clear_user_policies(user)

Remove all policies assigned to a user (or the anonymous user if user is None).

Permissioning models

tutelary.decorators.permissioned_model(cls, perm_type=None, path_fields=None, actions=None)

Function to set up a model for permissioning. Can either be called directly, passing a class and suitable values for perm_type, path_fields and actions, or can be used as a class decorator, taking values for perm_type, path_fields and actions from the TutelaryMeta subclass of the decorated class.

Permissions for views

class tutelary.mixins.PermissionRequiredMixin

Permission checking mixin – works just like the PermissionRequiredMixin in the default Django authentication system.

class tutelary.mixins.APIPermissionRequiredMixin

Permission checking mixin for Django Rest Framework – works just like the PermissionRequiredMixin in the default Django authentication system.

tutelary.decorators.permission_required(*actions, obj=None, raise_exception=False)

Permission checking decorator – works like the permission_required decorator in the default Django authentication system, except that it takes a sequence of actions to check, an object must be supplied, and the user must have permission to perform all of the actions on the given object for the permissions test to pass. Not actually sure how useful this is going to be: in any case where obj is not None, it’s going to be tricky to get the object into the decorator. Class-based views are definitely best here…

Permissions backend

class tutelary.backends.Backend

Custom authentication backend: dispatches has_perm queries to the user’s permission set.

has_perm(user, perm, obj=None, *args, **kwargs)

Test user permissions for a single action and object.

Parameters:

• user (User) – The user to test.
• perm (str) – The action to test.
• obj (tutelary.engine.Object) – The object path to test.

Returns:

bool – is the action permitted?

permitted_actions(user, obj=None)

Determine list of permitted actions for an object or object pattern.

Parameters:

• user (User) – The user to test.
• obj (callable) – A function mapping from action names to object paths to test.

Returns:

list(tutelary.engine.Action) – permitted actions.

Exceptions

exception tutelary.exceptions.EffectException(effect)

Exception raised when an effect type other that allow or deny is encountered in a JSON policy body.

exception tutelary.exceptions.PatternOverlapException(exc_type)

Exception raised when overlapping action or object patterns are used in a single policy clause.

exception tutelary.exceptions.PolicyBodyException(msg=None, lineno=None, colno=None)

Exception raised for miscellaneous errors in JSON policy bodies.

exception tutelary.exceptions.VariableSubstitutionException

Exception raised for illegal variable substitutions when using JSON policy bodies.

exception tutelary.exceptions.RoleVariableException(msg)

Exception raised for missing or illegal variable substitutions for permissions roles.

exception tutelary.exceptions.DecoratorException(decorator, msg)

Exception raised if the permissioned_model decorator is used without the required TutelaryMeta class member being included in the model.

exception tutelary.exceptions.PermissionObjectException(prop)

Exception raised by the permissioned_model decorator if a permissions_object property in the actions list refers to a non-existent model field, or to a field that is not a foreign key or one-to-one relation field.