Default User Manager Data API¶
This section provides an overview of the part of the ETS Permissions Framework API used by developers who want to store a user database in a more secure location (eg. a remote server) than that provided by the default implementation.
The API is defined by the default user manager which uses password based authorisation. If this API isn’t sufficiently flexible, or if another method of authorisation is used (biometrics for example) then an alternative user manager should be implemented.
The API is fully defined by the IUserDatabase interface. This allows user databases to be implemented that extend the IUser interface and store additional user related data. If the user database is being persisted in secure storage (eg. a remote RDBMS) then this could be used to store sensitive data (eg. passwords for external systems) that shouldn’t be stored as ordinary preferences.
In most cases there will be no requirement to store additional user related
data than that defined by IUser
so the supplied UserDatabase
implementation (which provides all the GUI code required to implement the
IUserDatabase interface) can be used. The UserDatabase implementation
delegates the access to the user database to an object implementing the
IUserStorage interface. The default implementation of this interface
stores the user database as a pickle in a local file.
Overview of IUserStorage¶
The IUserStorage interface defines a number of methods that must be implemented to read and write to the user database. The methods are designed to be implemented using simple SQL statements.
In the event of an error a method must raise the UserStorageError
exception. The string representation of the exception is used as an error
message that is displayed to the user.
Overview of IUserDatabase¶
The IUserDatabase interface defines a set of Bool
traits, all beginning
with can_
, that describe the capabilities of a particular implementation.
For example, the can_add_user
trait is set by an implementation if it
supports the ability to add a new user to the database.
Each of these capability traits has a corresponding method which has the same
name except for the can_
prefix. The method only needs to be implemented
if the corresponding traits is True
. The method, for example
add_user()
is called by the user manager to implement the capability.
The interface has two other methods.
The bootstrapping()
method is called by the user manager to determine if
the database is bootstrapping. Typically this is when the database is empty
and no users have yet been defined. The permissions framework treats this
situation as a special case and is able to relax the enforcement of permissions
to allow users and permissions to be initially defined.
The user_factory()
method is called by the user manager to create a new
user object, ie. an object that implements the IUser interface. This allows
an implementation to extend the IUser interface and store additional user
related data in the object if the blob
trait proves insufficient.