repoze.who Narrative Documentation¶
repoze.who as WSGI Middleware¶
repoze.who was originally developed for use as authentication
middleware in a WSGI pipeline, for use by applications which only
needed to obtain an “authenticated user” to enforce a given security
See Middleware Responsibilities for a description of this use case.
repoze.who without WSGI Middleware¶
Some applications might want to use a configured set of
repoze.who plugins to do identification and authentication for
a request, outside the context of using
For example, a performance-sensitive application might wish to defer
the effort of identifying and authenticating a user until the point at
which authorization is required, knowing that some code paths will not
need to do the work.
See Using the repoze.who Application Programming Interface (API) for a description of this use case.
Mixing Middleware and API Uses¶
Some applications might use the
repoze.who middleware for most
authentication purposes, but need to participate more directly in the
mechanics of identification and authorization for some portions of the
application. For example, consider a system which allows users to
sign up online for membership in a site: once the user completes
registration, such an application might wish to log the user in
transparently, and thus needs to interact with the configured
repoze.who middleware to generate response headers, ensuring
that the user’s next request is properly authenticated.
See Mixed Use of repoze.who Middleware and API for a description of this use case.
Developers and integrators can configure
repoze.who using either
imperative Python code (see Configuring repoze.who via Python Code) or using an
INI-style declarative configuration file (see Configuring repoze.who via Config File).
In either case, the result of the configuration will be a
repoze.who.api:APIFactory instance, complete with a request
classifier, a challenge decider, and a set of plugins for each plugin