| Age | Commit message (Collapse) | Author |
|---|
|
|
|
--------
- It is now possible to register a custom
``repoze.bfg.interfaces.INotFoundView`` for a given application.
This feature replaces the
``repoze.bfg.interfaces.INotFoundAppFactory`` feature previously
described in the Hooks chapter. The INotFoundView will be called
when the framework detects that a view lookup done as a result of a
reqest fails; it should accept a context object and a request
object; it should return an IResponse object (a webob response,
basically). See the Hooks narrative chapter of the BFG docs for
more info.
Deprecations
------------
- The ``repoze.bfg.interfaces.IUnauthorizedAppFactory`` interface has
been deprecated in favor of using the new
``repoze.bfg.interfaces.IForbiddenResponseFactory`` mechanism.
|
|
``repoze.bfg.interfaces.IForbiddenView``.
|
|
|
|
I'll do this work on the authchanges branch first.
|
|
|
|
|
|
--------
- It is now possible to write a custom security policy that returns a
customized ``Forbidden`` WSGI application when BFG cannot authorize
an invocation of a view. To this end, ISecurityPolicy objects must
now have a ``forbidden`` method. This method should return a WSGI
application. The returned WSGI application should generate a
response which is appropriate when access to a view resource was
forbidden by the security policy (e.g. perhaps a login page).
``repoze.bfg`` is willing to operate with a custom security policy
that does not have a ``forbidden`` method, but it will issue a
warning; eventually security policies without a ``forbidden`` method
will cease to work under ``repoze.bfg``.
Note that the ``forbidden`` WSGI application returned by the
security policy is not used if a developer has registered an
IForbiddenAppFactory (see the "Hooks" narrative chapter); the
explicitly registered IForbiddenAppFactory will be preferred over
the (more general) security policy forbidden app factory.
- All default security policies now have a ``forbidden`` callable
attached to them. This particular callable returns a WSGI
application which generates a ``401 Unauthorized`` response for
backwards compatibility (had backwards compatibility not been an
issue, this callable would have returned a WSGI app that generated a
``403 Forbidden`` response).
Backwards Incompatibilities
---------------------------
- Custom NotFound and Forbidden (nee' Unauthorized) WSGI applications
(registered a 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 renamed to ``repoze.bfg.interfaces.IForbiddenAppFactory``.
|
|
|
|
:mod:`repoze.bfg` generates when a view cannot be found or cannot be
invoked due to lack of permission. See the "ZCML Hooks" chapter in
the docs for more information.
- Use a homegrown Unauthorized error instead of
``webob.exc.Unauthorized`` (the latter is slow).
- Various speed micro-tweaks.
|
|
|
|
urldispatch chapter of the documentation.
Clean up "BFG" vernacular (replace with repoze.bfg).
|
|
factory" (e.g. in the ``Router`` class) and ``webob.Response`` and
the "response factory" (e.g. in ``render_template_to_response``),
allow both to be overridden via a ZCML utility hook. See the "Using
ZCML Hooks" chapter of the documentation for more information.
|
