permissions
Permission objects
The permissions module is accessible via the authkit module.
Permission objects are used to define which users should have access to a particular resource. They are checked using some of the authorization objects either in the authkit.authorize module or authkit.pylons_adaptors module if you are using Pylons.
Permissions objects are very similar to WSGI applications and can perform a check based on the request or the response. Not all of the authorization objects have access to the response because the permission might be checked as part of a code block before the response is generated. This leads to two classes of permissions, request-based (which can be checked anywhere) and responce-based which can only be checked when the authorization object has access to the response.
All the built-in AuthKit permissions are request-based but you can use the permissions objects defined in this module or create your own derived from authkit.permission.Permission.
Permissions are described in detail in the AuthKit manual.
Attributes
Classes
C And(...) ...
Checks all the permission objects listed as keyword arguments in turn. Permissions are checked from left to right. The error raised by the And permission is the error raised by the first permission check to fail.
This class contains 2 members.
C AuthKitConfigError(...) ...
Raised when there is a problem with the configuration options chosen for the authenticate middleware
This class contains 2 members.
C BetweenTimes(...) ...
Only grants access if the request is made on or after start and before end. Times should be specified as datetime.time objects.
This class contains 2 members.
C Exists(...) ...
Checks the specified key is present in the environ.
Takes the following arguments:
- key
- The required key
- error
- The error to be raised if the key is missing. XXX This argument may be deprecated soon.
This class contains 2 members.
C FromIP(...) ...
Checks that the remote host specified in the environment key is one of the hosts specified in hosts.
This class contains 2 members.
C HasAuthKitGroup(...) ...
Designed to work with the user management API described in the AuthKit manual.
This permission checks that the signed in user is in one of the groups specified in groups.
This class contains 2 members.
C HasAuthKitRole(...) ...
Designed to work with the user management API described in the AuthKit manual.
This permission checks that the signed in user has any if the roles specified in roles. If all is True, the user must have all the roles for the permission check to pass.
This class contains 2 members.
C Permission(...) ...
The base class for all permissions objects.
The check() method is called by the authorization object to check the permission. Permissions should return the original status, headers and response or raise a NotAuthorizedError when their check() method is called.
Note
The WSGI app can only be called once by the check() method. This means that you cannot write permisisons objects that perform logical not and or operations on other permissions objects since doing so might require the same app to be called multiple times. A permission object to perform an and operation is feasible and has been impleneted as the And permission class.
This class contains 2 members.
C RemoteUser(...) ...
Checks someone is signed in by checking for the presence of the REMOTE_USER.
If accept_empty is False (the default) then an empty REMOTE_USER will not be accepted and the value of REMOTE_USER must evaluate to True in Python.
This class contains 2 members.
C RequestPermission(...) ...
The base class for all request-based permissions
This class contains 2 members.
C UserIn(...) ...
Checks the REMOTE_USER is one of the users specified.
Takes the following arguments:
- users
- A list of usernames which are valid
If there is no REMOTE_USER a NotAuthenticatedError is raised. If the REMOTE_USER is not in users a NotAuthorizedError is raised.
Usernames supplied to users are treated case insensitively.
This class contains 2 members.
C ValidAuthKitUser(...) ...
Checks that the signed in user is one of the users specified when setting up the user management API.
This class contains 2 members.
See the source for more information.