Version 0.9a1 of repoze.bfg has been released. It is the first release which
makes a distinction between an "authorization policy" and an "authentication
policy". Older versions had a "security policy" which performed both
authentication and authorization, but it's much more frequent to only need to
change one or the other and not both.
You can install 0.9a1 via:
$ easy_install -i http://dist.repoze.org/bfg/dev/simple repoze.bfg
Or upgrade to it using easy_install -U against the same URL.
The changelog follows.
- New API functions named ``forget`` and ``remember`` are available in
the ``security`` module. The ``forget`` function returns headers
which will cause the currently authenticated user to be logged out
when set in a response. The ``remember`` function (when passed the
proper arguments) will return headers which will cause a principal
to be "logged in" when set in a response. See the Security API
chapter of the docs for more info.
- New keyword arguments to the ``repoze.bfg.router.make_app`` call
have been added: ``authentication_policy`` and
``authorization_policy``. These should, respectively, be an
implementation of an authentication policy (an object implementing
the ``repoze.bfg.interfaces.IAuthenticationPolicy`` interface) and
an implementation of an authorization policy (an object implementing
implementations of authentication policies exist in
``repoze.bfg.authentication``. Concrete implementations of
authorization policies exist in ``repoze.bfg.authorization``.
Both ``authentication_policy`` and ``authorization_policy`` default
If ``authentication_policy`` is ``None``, but
``authorization_policy`` is *not* ``None``, then
``authorization_policy`` is ignored (the ability to do authorization
depends on authentication).
If the ``authentication_policy`` argument is *not* ``None``, and the
``authorization_policy`` argument *is* ``None``, the authorization
policy defaults to an authorization implementation that uses ACLs
.. note:: we no longer encourage configuration of "security
policies" using ZCML, as previously we did for
``ISecurityPolicy``. This is because it's not uncommon to need to
configure settings for concrete authorization or authentication
policies using paste .ini parameters; the app entry point for your
applicatio is the natural place to do this.
- Two new abstractions have been added in the way of adapters used by
the system: an ``IAuthorizationPolicy`` and an
``IAuthenticationPolicy``. A combination of these (as registered by
the ``securitypolicy`` ZCML directive) take the place of the
``ISecurityPolicy`` abstraction in previous releases of repoze.who.
The API functions in ``repoze.who.security`` (such as
``has_permission``, and so on) have been changed to try to make use
of these new adapters. If you're using an older ``ISecurityPolicy``
adapter, the system will still work, but it will print deprecation
warnings when such a policy is used.
- The way the (internal) IViewPermission utilities registered via ZCML
are invoked has changed. They are purely adapters now, returning a
boolean result, rather than returning a callable. You shouldn't have
been using these anyway. ;-)
- New concrete implementations of IAuthenticationPolicy have been
added to the ``repoze.bfg.authentication`` module:
``RepozeWho1AuthenticationPolicy`` which uses ``repoze.who``
identity to retrieve authentication data from and
``RemoteUserAuthenticationPolicy``, which uses the ``REMOTE_USER``
value in the WSGI environment to retrieve authentication data.
- A new concrete implementation of IAuthorizationPolicy has been added
to the ``repoze.bfg.authorization`` module:
``ACLAuthorizationPolicy`` which uses ACL inheritance to do
- It is now possible to register a custom
``repoze.bfg.interfaces.IForbiddenResponseFactory`` for a given
application. This feature replaces the
``repoze.bfg.interfaces.IUnauthorizedAppFactory`` feature previously
described in the Hooks chapter. The IForbiddenResponseFactory will
be called when the framework detects an authorization failure; it
should accept a context object and a request object; it should
return an IResponse object (a webob response, basically). Read the
below point for more info and see the Hooks narrative chapter of the
BFG docs for more info.
- Custom NotFound and Forbidden (nee' Unauthorized) WSGI applications
(registered as a utility for INotFoundAppFactory and
IUnauthorizedAppFactory) could rely on an environment key named
``message`` describing the circumstance of the response. This key
has been renamed to ``repoze.bfg.message`` (as per the WSGI spec,
which requires environment extensions to contain dots).
- The ``repoze.bfg.interfaces.IUnauthorizedAppFactory`` interface has
been deprecated in favor of using the new
- The ``view_execution_permitted`` API should now be imported from the
``repoze.bfg.security`` module instead of the ``repoze.bfg.view``
- The ``authenticated_userid`` and ``effective_principals`` APIs in
``repoze.bfg.security`` used to only take a single argument
(request). They now accept two arguments (``context`` and
``request``). Calling them with a single argument is still
supported but issues a deprecation warning.
- Use of "old-style" security policies (those base on ISecurityPolicy)
is now deprecated. See the "Security" chapter of the docs for info
about activating an authorization policy and an authentication poicy.
Repoze-dev mailing list