| commit | author | age | ||
| d95e97 | 1 | :mod:`repoze.who` Narrative Documentation |
| TS | 2 | ========================================= |
| 8b6ab2 | 3 | |
| d95e97 | 4 | Using :mod:`repoze.who` as WSGI Middleware |
| TS | 5 | ------------------------------------------ |
| 8b6ab2 | 6 | |
| d95e97 | 7 | :mod:`repoze.who` was originally developed for use as authentication |
| TS | 8 | middleware in a WSGI pipeline, for use by applications which only |
| 9 | needed to obtain an "authenticated user" to enforce a given security | |
| 8b6ab2 | 10 | policy. |
| TS | 11 | |
| d95e97 | 12 | See :ref:`middleware_responsibilities` for a description of this use case. |
| 8b6ab2 | 13 | |
| TS | 14 | |
| d95e97 | 15 | Using :mod:`repoze.who` without WSGI Middleware |
| TS | 16 | ----------------------------------------------- |
| 8b6ab2 | 17 | |
| d95e97 | 18 | Some applications might want to use a configured set of |
| TS | 19 | :mod:`repoze.who` plugins to do identification and authentication for |
| 20 | a request, outside the context of using :mod:`repoze.who` middleware. | |
| 21 | For example, a performance-sensitive application might wish to defer | |
| 22 | the effort of identifying and authenticating a user until the point at | |
| 23 | which authorization is required, knowing that some code paths will not | |
| 24 | need to do the work. | |
| 8b6ab2 | 25 | |
| d95e97 | 26 | See :ref:`api_narrative` for a description of this use case. |
| 8b6ab2 | 27 | |
| TS | 28 | |
| d95e97 | 29 | Mixing Middleware and API Uses |
| TS | 30 | ------------------------------ |
| 8b6ab2 | 31 | |
| d95e97 | 32 | Some applications might use the :mod:`repoze.who` middleware for most |
| TS | 33 | authentication purposes, but need to participate more directly in the |
| 34 | mechanics of identification and authorization for some portions of the | |
| 35 | application. For example, consider a system which allows users to | |
| 71e6f0 | 36 | sign up online for membership in a site: once the user completes |
| d95e97 | 37 | registration, such an application might wish to log the user in |
| TS | 38 | transparently, and thus needs to interact with the configured |
| 39 | :mod:`repoze.who` middleware to generate response headers, ensuring | |
| 40 | that the user's next request is properly authenticated. | |
| 8b6ab2 | 41 | |
| d95e97 | 42 | See :ref:`middleware_api_hybrid` for a description of this use case. |
| 8b6ab2 | 43 | |
| TS | 44 | |
| d95e97 | 45 | Configuring :mod:`repoze.who` |
| TS | 46 | ----------------------------- |
| 8b6ab2 | 47 | |
| d95e97 | 48 | Developers and integrators can configure :mod:`repoze.who` using either |
| TS | 49 | imperative Python code (see :ref:`imperative_configuration`) or using an |
| 50 | INI-style declarative configuration file (see :ref:`declarative_configuration`). | |
| 51 | In either case, the result of the configuration will be a | |
| 52 | :class:`repoze.who.api:APIFactory` instance, complete with a request | |
| 53 | classifier, a challenge decider, and a set of plugins for each plugin | |
| 54 | interface. | |
