users
Objects representing users, their passwords, roles and groups
The users module is accessible via the authkit module.
The objects defined in this file used in conjunction with authentication, authorization and permission objects form a complete user management system.
However, there is no requirement to use this user management API at all. If you define your own authentication checks by specifying your own valid_password() or digest_password() methods when setting up the authentication middleware, and you create your own permissions objects based on your own requriements then you will have no need for this implementation. It is simply provided as a useful default implementation for users looking for a simple, ready made solution that doesn't require any integration.
The implementation consists of the following:
- authkit.authenticate.valid_password()
- A valid_password() implementation used by default with the basic or form authentication methods that checks usernames and passwords against those defined in the user management API object.
- authkit.authenticate.digest_password()
- A digest_password() implementation used by default with the digest authentication which produces a digest from the users set up in the user management API object.
- authkit.permissions.HasAuthKitRole
- A permission object which checks the signed in user's role from the user management API object.
- authkit.permissions.HasAuthKitGroup
- A permission object which checks the signed in user's group from the user management API object.
- authkit.permissions.ValidAuthKitUser
- A permission object which checks the signed in user is defined in the user management API object.
Of course since the user management API is fairly generic, it is possible to have different implementations. This module has two implementations both derived from the base Users class. They are UsersFromString and UsersFromFile. By default, authkit.authenticate.middleware uses UsersFromString and expects you to specify your users, groups and roles as a string in the config file in the way described in the main AuthKit manual but you can also specify you wish to use the alternative implementation to load your user data from a file.
Of course you are also free to create your own implementation derived from Users and as long as it keeps the same API, the existing functions and permissions mentioned earlier will work without modification when using your user management API object. This means that if your requirements are very simple you might prefer to create a custom Users object rather than integrate AuthKit into your project in the slightly lower level fashion by defining the valid_password() and digest_password() functions and any necessary permissions.
If you are using the authentication middleware with users, the Users object will be available in your code as environ[authkit.users].
Functions
Classes
C AuthKitError(...) ...
This class contains 2 members.
C AuthKitNoSuchGroupError(...) ...
This class contains 2 members.
C AuthKitNoSuchRoleError(...) ...
This class contains 2 members.
C AuthKitNoSuchUserError(...) ...
This class contains 2 members.
C AuthKitNotSupportedError(...) ...
This class contains 2 members.
C Users(...) ...
Base class from which all other Users classes should be derived.
This class contains 27 members.
C UsersFromFile(...) ...
A Users class with the same implementation as UsersFromString except that user information is obtained from a file. The file should contain user information in the same format as the string accepted for UsersFromString.
This class contains 27 members.
C UsersFromString(...) ...
A Users class which cbtains user information from a string with lines formatted as` username1:password1:group role1, role2 etc where group is optional and zero or more roles can exist.
One set of user information should be on each line and extra whitespace is stripped.
This class contains 27 members.
C UsersReadOnly(...) ...
Like the Users class except that user information is read only. All the information is obtained from the attributes self.usernames, self.passwords, self.roles, self.groups which are expected to be setup in __init__().
usernames should be a list of lowercase usernames passwords, groups should be a dictionary where the keys are lowercase usernames and the values are the corresponding lowercase group name or password. roles is similar to passwords and groups except values are lists of lowercase role names.
This class contains 27 members.
Modules
The authkit.users module exposes 2 submodules:
See the source for more information.