Repoze.who

------------------

Features
~~~~~~~~

- Restored the ability to create the middleware using the old ``classifier``
argument. That argument is now a deprecated-but-will-work-forever alias for
``request_classifier``.

- The ``auth_tkt`` plugin now implements the ``IAuthenticator`` interface,
and should normally be used both as an ``IIdentifier`` and an
``IAuthenticator``.

- Factored out the API of the middleware object to make it useful from
within the application. Applications using ``repoze.who now fall into
one of three catgeories:

- "middleware-only" applications are configured with middleware, and
use either ``REMOTE_USER`` or ``repoze.who.identity`` from the environment
to determing the authenticated user.

- "bare metal" applications use no ``repoze.who`` middleware at all:
instead, they configure and an ``APIFactory`` object at startup, and
use it to create an ``API`` object when needed on a per-request basis.

- "hybrid" applications are configured with ``repoze.who`` middleware,
but use a new library function to fetch the ``API`` object from the
environ, e.g. to permit calling ``remember`` after a signup or successful
login.

Bugs Fixed
~~~~~~~~~~

- Fix http://bugs.repoze.org/issue102: when no challengers existed,
logging would cause an exception.

- Remove ``ez_setup.py`` and dependency on it in setup.py (support
distribute).

Backward Incompatibilities
~~~~~~~~~~~~~~~~~~~~~~~~~~

- The middleware used to allow identifier plugins to "pre-authenticate"
an identity. This feature is no longer supported: the ``auth_tkt``
plugin, which used to use the feature, is now configured to work as
an authenticator plugin (as well as an identifier).

- The ``repoze.who.middleware:PluggableAuthenticationMiddleware`` class
no longer has the following (non-API) methods (now made API methods
of the ``repoze.who.api:API`` class):

- ``add_metadata``
- ``authenticate``
- ``challenge``
- ``identify``

- The following (non-API) functions moved from ``repoze.who.middleware`` to
``repoze.who.api``:

- ``make_registries``
- ``match_classification``
- ``verify``

-------------------

- Issue 104: AuthTkt plugin was passing an invalid cookie value in
headers from ``forget``, and was not setting the ``Max-Age`` and
``Expires`` attributes of those cookies.

-------------------

- Fixed the ``repoze.who.plugins.form.make_plugin`` factory's ``formcallable``
argument handling, to allow passing in a dotted name (e.g., from a config
file).

-------------------

- Exposed ``formcallable`` argument for ``repoze.who.plugins.form.FormPlugin``
to the callers of the ``repoze.who.plugins.form.make_plugin`` factory.
Thanks to Roland Hedburg for the report.

- Fixed an issue that caused the following symptom when using the
ini configuration parser::

TypeError: _makePlugin() got multiple values for keyword argument 'name'

See http://bugs.repoze.org/issue92 for more details. Thanks to vaab
for the bug report and initial fix.

-------------------

- If the form post value ``max_age`` exists while in the ``identify``
method is handling the ``login_handler_path``, pass the max_age
value in the returned identity dictionary as ``max_age``. See the
below bullet point for why.

- If the ``identity`` dict passed to the ``auth_tkt`` ``remember``
method contains a ``max_age`` key with a string (or integer) value,
treat it as a cue to set the ``Max-Age`` and ``Expires`` headers in
the returned cookies. The cookie ``Max-Age`` is set to the value
and the ``Expires`` is computed from the current time.

-------------------

- Fix test breakage on Windows. See http://bugs.repoze.org/issue79 .

- Documented issue with using ``include_ip`` setting in the ``auth_tkt``
plugin. See http://bugs.repoze.org/issue81 .

- Added 'passthrough_challenge_decider', which avoids re-challenging 401
responses which have been "pre-challenged" by the application.

- One-hundred percent unit test coverage.

- Add ``timeout`` and ``reissue_time`` arguments to the auth_tkt
identifier plugin, courtesty of Paul Johnston.

- Add a ``userid_checker`` argument to the auth_tkt identifier plugin,
courtesty of Gustavo Narea.

If ``userid_checker`` is provided, it must be a dotted Python name
that resolves to a function which accepts a userid and returns a
boolean True or False, indicating whether that user exists in a
database. This is a workaround. Due to a design bug in repoze.who,
the only way who can check for user existence is to use one or more
IAuthenticator plugin ``authenticate`` methods. If an
IAuthenticator's ``authenticate`` method returns true, it means that
the user exists. However most IAuthenticator plugins expect *both*
a username and a password, and will return False unconditionally if
both aren't supplied. This means that an authenticator can't be
used to check if the user "only" exists. The identity provided by
an auth_tkt does not contain a password to check against. The
actual design bug in repoze.who is this: when a user presents
credentials from an auth_tkt, he is considered "preauthenticated".
IAuthenticator.authenticate is just never called for a
"preauthenticated" identity, which works fine, but it means that the
user will be considered authenticated even if you deleted the user's
record from whatever database you happen to be using. However, if
you use a userid_checker, you can ensure that a user exists for the
auth_tkt supplied userid. If the userid_checker returns False, the
auth_tkt credentials are considered "no good".