Repoze-who

Latest version: v2.3

Safety actively analyzes 687918 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 2 of 7

2.0b1

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

- Enabled standard use of logging module's configuration mechanism.
See http://docs.python.org/dev/howto/logging.htmlconfiguring-logging-for-a-library
Thanks to jgoldsmith for the patch: http://bugs.repoze.org/issue178


- ``repoze.who.plugins.htpasswd``: defend against timing-based attacks.

2.0a4

Not secure
------------------

- Ensure that the middleware calls ``close()`` (if it exists) on the
iterable returned from thw wrapped application, as required by PEP 333.
http://bugs.repoze.org/issue174

- Make ``make_api_factory_with_config`` tolerant of invalid filenames /
content for the config file: in such cases, the API factory will have
*no* configured plugins or policies: it will only be useful for retrieving
the API from an environment populated by middleware.

- Fix bug in ``repoze.who.api`` where the ``remember()`` or ``forget()``
methods could return a None if the identifier plugin returned a None.

- Fix ``auth_tkt`` plugin to not hand over tokens as strings to paste. See
http://lists.repoze.org/pipermail/repoze-dev/2010-November/003680.html

- Fix ``auth_tkt`` plugin to add "secure" and "HttpOnly" to cookies when
configured with ``secure=True``: these attributes prevent the browser from
sending cookies over insecure channels, which could be vulnerable to some
XSS attacks.

- Avoid propagating unicode 'max_age' value into cookie headers. See
https://bugs.launchpad.net/bugs/674123 .

- Added a single-file example BFG application demonstrating the use of
the new 'login' and 'logout' methods of the API object.

- Add ``login`` and ``logout`` methods to the ``repoze.who.api.API`` object,
as a convenience for application-driven login / logout code, which would
otherwise need to use private methods of the API, and reach down into
its plugins.

2.0a3

Not secure
------------------

- Deprecated the following plugins, moving their modules, tests, and docs
to a new project, ``repoze.who.deprecatedplugins``:

- ``repoze.who.plugins.cookie.InsecureCookiePlugin``

- ``repoze.who.plugins.form.FormPlugin``

- ``repoze.who.plugins.form.RedirectingFormPlugin``

- Made the ``repoze.who.plugins.cookie.InsecureCookiePlugin`` take a
``charset`` argument, and use to to encode / decode login and password.
See http://bugs.repoze.org/issue155

- Updated ``repoze.who.restrict`` to return headers as a list, to keep
``wsgiref`` from complaining.

- Helped default request classifier cope with xml submissions with an
explicit charset defined: http://bugs.repoze.org/issue145 (Lorenzo
M. Catucci)

- Corrected the handling of type and subtype when matching an XML post
to ``xmlpost`` in the default classifier, which, according to RFC
2045, must be matched case-insensitively:
http://bugs.repoze.org/issue145 (Lorenzo M. Catucci)

- Added ``repoze.who.config:make_api_factory_with_config``, a convenience
method for applications which want to set up their own API Factory from
a configuration file.

- Fixed example call to ``repoze.who.config:make_middleware_with_config``
(added missing ``global_config`` argument). See
http://bugs.repoze.org/issue114

2.0a2

Not secure
------------------

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

- Fixed failure to pass substution values in log message string formatting
for ``repoze.who.api:API.challenge``. Fix included adding tests for all
logging done by the API object. See http://bugs.repoze.org/issue122

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

- Adjusted logging level for some lower-level details from ``info``
to ``debug``.

2.0a1

Not secure
------------------

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``

1.0.18

Not secure
-------------------

- 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.

Page 2 of 7

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.