Authenticators are special classes which can, in conjunction with mechanisms in the server environment, judge whether a user of an application is recognised or not. The process of using authenticators is as follows:
The exact details of configuring authentication mechanisms in each server
environment may vary substantially. For example, Apache environments require
that Auth
directives be specified in the Apache configuration
files (see docs/ModPython/NOTES.txt
); in Zope environments,
protected folders can be defined to hold the application when deployed (see
docs/Zope/NOTES.txt
).
An authenticator must be defined within your application in order to make decisions about users who have presented their credentials; this authenticator will respond with a decision when prompted by the server or underlying framework, either allowing or denying access for the user whose identity has been presented to the server/framework.
The code for an authenticator usually looks like this:
class MyAuthenticator: "This is an authenticator - something which decides whether a user is known to the application." def authenticate(self, trans): user = trans.get_user() [Make a decision about the validity of the user.] [Return a true value if the user is allowed to access the application.] [Return a false value if the user is not recognised or allowed to access the application.] def get_auth_type(self): "This method returns 'Basic' in most deployments." return "Basic" def get_realm(self): "This method returns something to distinguish this authentication mechanism from others." return "MyRealm"
In this mechanism, authenticators rely on authentication information from the server/framework and have a "global" effect on access to the application. However, it is always possible to test the user identity later on and to change the way an application behaves accordingly.
Transaction objects have the following methods for inspecting and redefining the identity of users:
get_user
set_user
get_user
, allowing certain parts of an application to view
users according to other criteria than their basic username - for
example, one might use set_user
to redefine each user's
identity in terms of the role that user may have in an application.Authenticator objects are created in the adapter code - see "Writing Adapters" for more information.
With application-wide authenticators, anonymous access to resources and applications can be difficult to permit alongside access by specific users, mostly because servers and frameworks which employ HTTP authentication schemes do so globally for a given application.
With application-wide authenticators, a logout function may not be available if the server/framework has been configured to use HTTP authentication schemes, mainly because no logout mechanism generally exists for such schemes.