| Age | Commit message (Collapse) | Author |
|---|
|
|
|
instead rely on queryAdapter and a manual default to
ModelGraphTraverser.
- Speed: do not register an IContextURL in configure.zcml; instead
rely on queryAdapter and a manual default to TraversalContextURL.
- General speed microimprovements for helloworld benchmark: replace
try/excepts with statements which use 'in' keyword.
|
|
|
|
|
|
return value of any view callble into a string. It is documented in
the "Views" narrative chapter.
|
|
|
|
|
|
default_notfound_view functions into the ``repoze.bfg.view`` module
(moved from ``repoze.bfg.router``).
|
|
|
|
absolute filesystem path including a drive letter was passed as
``filename`` (or as ``configure_zcml`` in the options dict) to
``repoze.bfg.router.make_app``, it would be treated as a
package:resource_name specification.
|
|
|
|
environment variable (``BFG_CONFIGURE_ZCML``) to name a ZCML file
that will be used to bootstrap the application. Previously, the
integrator could not influence which ZCML file was used to do the
boostrapping (only the original application developer could do so).
|
|
arguments to ``repoze.bfg.router.make_app``. Instead, developers
should use the various authentication policy ZCML directives
(``repozewho1authenticationpolicy``,
``remoteuserauthenticationpolicy`` and
``authtktauthenticationpolicy``) and the `aclauthorizationpolicy``
authorization policy directive as described in the changes to the
"Security" narrative documentation chapter and the wiki tutorials.
|
|
IAuthenticationPolicy/IForbiddenView/INotFoundView based on older
concepts from the router module's ``make_app`` function into the
``repoze.bfg.zcml.zcml_configure`` callable, to service
compatibility with scripts that use "zope.configuration.xmlconfig"
(replace with ``repoze.bfg.zml.zcml_configure`` as necessary to get
BBB logic)
|
|
directive can be used to name a view that should be invoked when the
request can't otherwise be resolved to a view callable. For example::
<notfound
view="helloworld.views.notfound_view"/>
- A new ZCML directive was added named ``forbidden``. This ZCML
directive can be used to name a view that should be invoked when a
view callable for a request is found, but cannot be invoked due to
an authorization failure. For example::
<forbidden
view="helloworld.views.forbidden_view"/>
|
|
a request object, instead of both a context and a request (which
still works, and always will). The following types work as views in
this style:
- functions that accept a single argument ``request``, e.g.::
def aview(request):
pass
- new and old-style classes that have an ``__init__`` method that
accepts ``self, request``, e.g.::
def View(object):
__init__(self, request):
pass
- Arbitrary callables that have a ``__call__`` method that accepts
``self, request``, e.g.::
def AView(object):
def __call__(self, request):
pass
view = AView()
This likely should have been the calling convention all along, as
the request has ``context`` as an attribute already, and with views
called as a result of URL dispatch, having the context in the
arguments is not very useful. C'est la vie.
|
|
|
|
``environ["PATH_INFO"]`` on the notfound result page rather than the
fullly computed URL.
|
|
# used routes (at least apps without any custom "context
# factory") in BFG 0.9.X and before
|
|
|
|
no purpose in trying to account for non-Webob requests.
|
|
|
|
derivation of values passed as the ``options`` value of
``repoze.bfg.router.make_app``. This API should be preferred
instead of using getUtility(ISettings). I added a new
``repoze.bfg.settings`` API document as well.
|
|
for use as a default context factory as documented in the "Hooks"
chapter.
|
|
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``.
|
|
ZCML (thinko).
|
|
overridden via ZCML registrations (do ZCML parsing after
registering these in router.py).
|
|
|
|
I'll do this work on the authchanges branch first.
|
|
``forbidden``) works properly.
|
|
|
|
|
|
--------
- 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``.
|
|
|
|
--------
- Added a ``traverse`` function to the ``repoze.bfg.traversal``
module. This function may be used to retrieve certain values
computed during path resolution. See the Traversal API chapter of
the documentation for more information about this function.
Deprecations
------------
- Internal: ``ITraverser`` callables should now return a dictionary
rather than a tuple. Up until 0.7.0, all ITraversers were assumed
to return a 3-tuple. In 0.7.1, ITraversers were assumed to return a
6-tuple. As (by evidence) it's likely we'll need to add further
information to the return value of an ITraverser callable, 0.8
assumes that an ITraverser return a dictionary with certain elements
in it. See the ``repoze.bfg.interfaces.ITraverser`` interface for
the list of keys that should be present in the dictionary.
``ITraversers`` which return tuples will still work, although a
deprecation warning will be issued.
Backwards Incompatibilities
---------------------------
- If your code used the ITraverser interface directly (not via an API
function such as ``find_model``) via an adapter lookup, you'll need
to change your code to expect a dictionary rather than a 3- or
6-tuple if your code ever gets return values from the default
ModelGraphTraverser or RoutesModelTraverser adapters.
|
|
built-in implementations that implement the interface
(``repoze.bfg.traversal.ModelGraphTraverser``, and
``repoze.bfg.urldispatch.RoutesModelTraverser``) now expect the
``__call__`` method of an ITraverser to return 3 additional
arguments: ``traversed``, ``virtual_root``, and
``virtual_root_path`` (the old contract was that the ``__call__``
method of an ITraverser returned; three arguments, the contract new
is that it returns six). ``traversed`` will be a sequence of
Unicode names that were traversed (including the virtual root path,
if any) or ``None`` if no traversal was performed, ``virtual_root``
will be a model object representing the virtual root (or the
physical root if traversal was not performed), and
``virtual_root_path`` will be a sequence representing the virtual
root path (a sequence of Unicode names) or ``None`` if traversal was
not performed.
Six arguments are now returned from BFG ITraversers. They are
returned in this order: ``context``, ``view_name``, ``subpath``,
``traversed``, ``virtual_root``, and ``virtual_root_path``.
Places in the BFG code which called an ITraverser continue to accept
a 3-argument return value, although BFG will generate and log a
warning when one is encountered.
- The request object now has the following attributes: ``traversed``
(the sequence of names traversed or ``None`` if traversal was not
performed), ``virtual_root`` (the model object representing the
virtual root, including the virtual root path if any), and
``virtual_root_path`` (the seuquence of names representing the
virtual root path or ``None`` if traversal was not performed).
- A new decorator named ``wsgiapp2`` was added to the
``repoze.bfg.wsgi`` module. This decorator performs the same
function as ``repoze.bfg.wsgi.wsgiapp`` except it fixes up the
``SCRIPT_NAME``, and ``PATH_INFO`` environment values before
invoking the WSGI subapplication.
- The ``repoze.bfg.testing.DummyRequest`` object now has default
attributes for ``traversed``, ``virtual_root``, and
``virtual_root_path``.
- The RoutesModelTraverser now behaves more like the Routes
"RoutesMiddleware" object when an element in the match dict is named
``path_info`` (usually when there's a pattern like
``http://foo/*path_info``). When this is the case, the
``PATH_INFO`` environment variable is set to the value in the match
dict, and the ``SCRIPT_NAME`` is appended to with the prefix of the
original ``PATH_INFO`` not including the value of the new variable.
- The notfound debug now shows the traversed path, the virtual root,
and the virtual root path too.
|
|
|
|
: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.
|
|
(the latter is slow).
|
|
----------------
- The ``repoze.bfg.view.render_view_to_response`` API will no longer
raise a ValueError if an object returned by a view function it calls
does not possess certain attributes (``headerlist``, ``app_iter``,
``status``). This API used to attempt to perform a check using the
``is_response`` function in ``repoze.bfg.view``, and raised a
``ValueError`` if the ``is_response`` check failed. The
responsibility is now the caller's to ensure that the return value
from a view function is a "real" response.
- WSGI environ dicts passed to ``repoze.bfg`` 's Router must now
contain a REQUEST_METHOD key/value; if they do not, a KeyError will
be raised (speed).
Implementation Changes
----------------------
- Various speed micro-tweaks.
|
|
instead of using imported ZCA APIs, use the same APIs directly
against the registry that is an attribute of the Router. As a
result, the registry used by BFG is now a subclass of
``zope.component.registry.Components`` (defined as
``repoze.bfg.registry.Registry``); it has a ``notify`` method.
|
|
# request methods within ``router.py`` when constructing a request
# object rather than using ``alsoProvides`` to attach the proper
# interface to an unsubclassed webob.Request. This pattern is purely
# an optimization (e.g. preventing calls to ``alsoProvides`` means the
# difference between 590 r/s and 690 r/s on a MacBook 2GHz).
|
|
|
|
uses directlyProvides.
|
|
|
|
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.
|
|
attached to each request object on ingress. The HTTP-verb-related
interfaces are defined in ``repoze.bfg.interfaces`` and are
``IGETRequest``, ``IPOSTRequest``, ``IPUTRequest``,
``IDELETERequest`` and ``IHEADRequest``. These interfaces can be
specified as the ``request_type`` attribute of a bfg view
declaration. A view naming a specific HTTP-verb-matching interface
will be found only if the view is defined with a request_type that
matches the HTTP verb in the incoming request. The more general
``IRequest`` interface can be used as the request_type to catch all
requests (and this is indeed the default). All requests implement
``IRequest``. The HTTP-verb-matching idea was pioneered by
`repoze.bfg.restrequest
<http://pypi.python.org/pypi/repoze.bfg.restrequest/1.0.1>`_ . That
package is no longer required, but still functions fine.
|
|
of registries in order to make it possible to call one BFG
application from inside another.
|
