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. 0.9a1 (2009-5-27) ================= Features -------- - 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 ``repoze.bfg.interfaces.IAuthorizationPolicy)``. Concrete 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 to ``None``. 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 (``repoze.bfg.authorization.ACLAuthorizationPolicy``). .. 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 ``authentication_userid``, ``effective_principals``, ``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 authorization. - 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. Backwards Incompatibilities --------------------------- - 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). Deprecations ------------ - The ``repoze.bfg.interfaces.IUnauthorizedAppFactory`` interface has been deprecated in favor of using the new ``repoze.bfg.interfaces.IForbiddenResponseFactory`` mechanism. - The ``view_execution_permitted`` API should now be imported from the ``repoze.bfg.security`` module instead of the ``repoze.bfg.view`` module. - 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 Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
