| Age | Commit message (Collapse) | Author |
|---|
|
within the ``repoze.bfg.wsgi`` module.
|
|
|
|
for use as a default context factory as documented in the "Hooks"
chapter.
|
|
|
|
|
|
alias for its ``condition_method`` argument for symmetry with the
``view`` directive.
|
|
|
|
``bfg_view`` decorators can now be one of the strings ``GET``,
``POST``, ``PUT``, ``DELETE``, or ``HEAD`` instead of a reference to
the respective interface type imported from
``repoze.bfg.interfaces``.
|
|
``repoze.bfg.wsgi.NotFound``, and ``repoze.bfg.wsgi.Unauthorized``.
These classes were disused with the introduction of the
``IUnauthorizedView`` and ``INotFoundView`` machinery.
|
|
unit tests.
|
|
Chameleon text templates.
|
|
|
|
non-response object now includes the view's name for troubleshooting
purposes.
- A "new response" event is emitted for forbiden and notfound views.
|
|
|
|
|
|
--------
- 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``.
|
|
|
|
``authenticated_userid`` function APIs in ``repoze.bfg.security``,
effectively a doing reversion to 0.8 and before behavior. Both
functions now again accept only the ``request`` parameter.
|
|
|
|
|
|
credentials from an auth_tkt cookie managed by the application
itself (instead of relying on an upstream data source for
authentication data). See the Security API chapter of the
documentation for more info.
- Allow RemoteUserAuthenticationPolicy and
RepozeWho1AuthenticationPolicy to accept various constructor
arguments. See the Security API chapter of the documentation for
more info.
|
|
|
|
obtains a WSGI application from a config file given a config file
name and a section name. See the ``repoze.bfg.paster`` API docs for
more information.
- Add a new module named ``scripting``. It contains a ``get_root``
API function, which, provided a Router instance, returns a traversal
root object and a "closer". See the ``repoze.bfg.scripting`` API
docs for more info.
|
|
ZCML (thinko).
|
|
|
|
|
|
``repoze.bfg.interfaces.IRootPolicy`` (deprecated since 0.6.2). It
must be imported as ``repoze.bfg.interfaces.IRootFactory`` now.
- Removed backwards compatibility alias for
``repoze.bfg.interfaces.ITemplate`` (deprecated since 0.4.4). It
must be imported as ``repoze.bfg.interfaces.ITemplateRenderer`` now.
- Removed backwards compatibility alias for
``repoze.bfg.interfaces.ITemplateFactory`` (deprecated since 0.4.4).
It must be imported as
``repoze.bfg.interfaces.ITemplateRendererFactory`` now.
- Removed backwards compatibility alias for
``repoze.bfg.chameleon_zpt.ZPTTemplateFactory`` (deprecated since
0.4.4). This must be imported as ``repoze.bfg.ZPTTemplateRenderer``
now.
|
|
overridden via ZCML registrations (do ZCML parsing after
registering these in router.py).
|
|
``InheritingACLSecurityPolicy``, ``RemoteUserACLSecurityPolicy``,
``RemoteUserInheritingACLSecurityPolicy``, ``WhoACLSecurityPolicy``,
and ``WhoInheritingACLSecurityPolicy`` from the
``repoze.bfg.security`` module; for the meantime (for backwards
compatibility purposes) these live in the ``repoze.bfg.secpols``
module. Note however, that the entire concept of a "security
policy" is deprecated in BFG in favor of separate authentication and
authorization policies, so any use of a security policy will
generate additional deprecation warnings even if you do start using
``repoze.bfg.secpols``. ``repoze.bfg.secpols`` will disappear in a
future release of ``repoze.bfg``.
|
|
package have been deprecated since version 0.3.8. Instead, import
``get_template``, ``render_template``, and
``render_template_to_response`` from the
``repoze.bfg.chameleon_zpt``module.
|
|
``repoze.bfg.traversal.split_path`` (deprecated since 0.6.5). This
must now be imported as ``repoze.bfg.traversal.traversal_path``).
|
|
``repoze.bfg.urldispatch.RoutesContext`` (deprecated since 0.6.3).
This must now be imported as
``repoze.bfg.urldispatch.DefaultRoutesContext``.
|
|
``repoze.bfg.router.get_options`` and ``repoze.bfg.router.Settings``
(deprecated since 0.6.2). These both must now be imported from
``repoze.bfg.settings``.
|
|
|
|
|
|
|
|
|
|
be used to get an interactive prompt with your BFG root object in
the global namespace. E.g.::
bin/paster bfgshell /path/to/myapp.ini myapp
See the ``Project`` chapter in the BFG documentation for more
information.
|
|
|
|
|
|
|
|
|
|
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``.
|
|
|
