evennia.web.api.permissions

Sets up an api-access permission check using the in-game permission hierarchy.

class evennia.web.api.permissions.EvenniaPermission

Bases: rest_framework.permissions.BasePermission

A Django Rest Framework permission class that allows us to use Evennia’s permission structure. Based on the action in a given view, we’ll check a corresponding Evennia access/lock check.

MINIMUM_LIST_PERMISSION = 'builder'

MINIMUM_CREATE_PERMISSION = 'builder'

view_locks = ['examine']

destroy_locks = ['delete']

update_locks = ['control', 'edit']

has_permission(request, view)

Checks for permissions

Parameters

• request (Request) – The incoming request object.

• view (View) – The django view we are checking permission for.

Returns

bool – If permission is granted or not. If we return False here, a PermissionDenied error will be raised from the view.

Notes

This method is a check that always happens first. If there’s an object involved, such as with retrieve, update, or delete, then the has_object_permission method is called after this, assuming this returns True.

static check_locks(obj, user, locks)

Checks access for user for object with given locks :param obj: Object instance we’re checking :param user: User who we’re checking permissions :type user: Account :param locks: list of lockstrings :type locks: list

Returns

bool – True if they have access, False if they don’t

has_object_permission(request, view, obj)

Checks object-level permissions after has_permission

Parameters

• request (Request) – The incoming request object.

• view (View) – The django view we are checking permission for.

• obj – Object we’re checking object-level permissions for

Returns

bool – If permission is granted or not. If we return False here, a PermissionDenied error will be raised from the view.

Notes

This method assumes that has_permission has already returned True. We check equivalent Evennia permissions in the request.user to determine if they can complete the action.