wsgi_adaptors
Authorization objects for checking permissions
The wsgi_adaptors module is accessible via the authkit.authorize module.
In the AuthKit model permissions are handled by Permission objects. Authorization objects are used to check permissions and to raise NotAuthenticatedError or NotAuthorizedError if there is no user or the user is not authorized. The execeptions are converted to HTTP responses which are then intercepted and handled by the authentication middleware.
The way permissions objects should be checked depends on where abouts in the application stack the check occurs and so different authorization objects exist to make checks at different parts of the stack. You can of course create your own permission objects to be authorized by the middleware and decorator defined here. See the permissions docs or the AuthKit manual for more information.
Framework implementors might also create their own implementations of AuthKit authorization objects. For example the authkit.pylons_adaptors module contains some Pylons-specific authorization objects which you'll want to use if you are using AuthKit with Pylons.
For an example of how to use permission objects have a look at the AuthorizeExampleApp class in the authorize.py example in the examples directory or have a look at the AuthKit manual.
Functions
f authorize(permission) ...
This is an authorize decorator (requires Python 2.4) which can be used to decorate a function. It takes the permission to check as its only argument.
See the AuthKit manual for an example.
f authorize_request(environ, permission) ...
This function can be used within a controller action to ensure that no code after the function call is executed if the user doesn't pass the permission check specified by permission.
Note
Unlike the authorize() decorator or authkit.authorize.middleware middleware, this function has no access to the WSGI response so cannot be used to check response-based permissions. Since almost all AuthKit permissions are request-based this shouldn't be a big problem unless you are defining your own advanced permission checks.
f middleware(app, permission) ...
Returns an WSGI app wrapped in authorization middleware and on each request will check the permission specified.
Takes the arguments:
- app
- The WSGI application to be wrapped
- permission
- The AuthKit permission object to be checked.
The httpexceptions and authkit.authenticate.middleware middleware need to be wrap this middleware otherwise any errors triggered will not be intercepted.
See the AuthKit manual for an example.
Classes
C NonConformingPermissionError(...) ...
Raised when a custom permission object is not behaving in a compliant way
This class contains 2 members.
C NotAuthenticatedError(...) ...
Raised when a permission check fails because the user is not authenticated.
The exception is caught by the httpexceptions middleware and converted into a 401 HTTP response which is intercepted by the authentication middleware triggering a sign in.
This class contains 10 members.
C NotAuthorizedError(...) ...
Raised when a permission check fails because the user is not authorized.
The exception is caught by the httpexceptions middleware and converted into a 403 HTTP response which is intercepted by the authentication middleware triggering a sign in.
This class contains 10 members.
C PermissionError(...) ...
Base class from which NotAuthenticatedError and NotAuthorizedError are inherited.
This class contains 10 members.
C PermissionSetupError(...) ...
This class contains 2 members.
See the source for more information.