| Age | Commit message (Collapse) | Author |
|
``repoze.bfg.view.append_slash_notfound_view`` view as the Not Found
view in your application. When this view is the Not Found view
(indicating that no view was found), and any routes have been
defined in the configuration of your application, if the value of
``PATH_INFO`` does not already end in a slash, and if the value of
``PATH_INFO`` *plus* a slash matches any route's path, do an HTTP
redirect to the slash-appended PATH_INFO. Note that this will
*lose* ``POST`` data information (turning it into a GET), so you
shouldn't rely on this to redirect POST requests.
|
|
``repoze.bfg.exceptions.NotFound``. The old location still
functions, but emits a deprecation warning.
- The import of ``repoze.bfg.security.Unauthorized`` is deprecated in
favor of ``repoze.bfg.exceptions.Forbidden``. The old location
still functions but emits a deprecation warning. The rename from
``Unauthorized`` to ``Forbidden`` brings parity to the the name of
the exception and the system view it invokes when raised.
- New ``repoze.bfg.exceptions`` module was created to house exceptions
that were previously sprinkled through various modules.
- An ``exceptions`` API chapter was added, documenting the new
``repoze.bfg.exceptions`` module.
|
|
generating URLs to static resources defined by the ``<static>`` ZCML
directive. See the "Views" narrative chapter's section titled
"Generating Static Resource URLs" for more information.
|
|
deprecated in favor of
``repoze.bfg.testing.registerTemplateRenderer``. A deprecation
warning is *not* issued at import time for the former name; it will
exist "forever".
- The ``repoze.bfg.templating.renderer_from_cache`` function has been
moved to ``repoze.bfg.renderer.template_renderer_factory``. This
was never an API, but code in the wild was spotted that used it. A
deprecation warning is issued at import time for the former.
- Better error message when a wrapper view returns None.
|
|
|
|
|
|
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.
|
|
"front" for the Routes ``url_for`` API. See the URL Dispatch
narrative chapter and the "repoze.bfg.url" module API documentation
for more information.
|
|
|
|
|
|
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.
|
|
enough to be very helpful and had a misleading name.
|
|
|
|
should be used (**very sparingly**) to retrieve the "current"
request. See the ``repoze.bfg.request`` API documentation for more
information.
|
|
|
|
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.
|
|
|
|
--------
- 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.
|
|
|
|
``registerAdapter``, ``registerUtiity``, ``registerSubscriber``, and
``cleanUp``.
- Added glossary entry for "root factory".
|
|
--------
- Two new security policies were added:
RemoteUserInheritingACLSecurityPolicy and
WhoInheritingACLSecurityPolicy. These are security policies which
take into account *all* ACLs defined in the lineage of a context
rather than stopping at the first ACL found in a lineage. See the
"Security" chapter of the API documentation for more information.
- The API and narrative documentation dealing with security was
changed to introduce the new "inheriting" security policy variants.
- Added glossary entry for "lineage".
Deprecations
------------
- The security policy previously named
``RepozeWhoIdentityACLSecurityPolicy`` now has the slightly saner
name of ``WhoACLSecurityPolicy``. A deprecation warning is emitted
when this policy is imported under the "old" name; usually this is
due to its use in ZCML within your application. If you're getting
this deprecation warning, change your ZCML to use the new name,
e.g. change::
<utility
provides="repoze.bfg.interfaces.ISecurityPolicy"
factory="repoze.bfg.security.RepozeWhoIdentityACLSecurityPolicy"
/>
To::
<utility
provides="repoze.bfg.interfaces.ISecurityPolicy"
factory="repoze.bfg.security.WhoACLSecurityPolicy"
/>
|
|
|
|
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.
|
|
|
|
now still returns a string; albeit a quoted one. An additional API
(model_path_tuple) now also exists which can be used to get a model
path as a tuple.
- The ``repoze.bfg.traversal.model_path`` API now returns a *quoted*
string rather than a string represented by series of unquoted
elements joined via ``/`` characters. Previously it returned a
string or unicode object representing the model path, with each
segment name in the path joined together via ``/`` characters,
e.g. ``/foo /bar``. Now it returns a string, where each segment is
a UTF-8 encoded and URL-quoted element e.g. ``/foo%20/bar``. This
change was (as discussed briefly on the repoze-dev maillist)
necessary to accomodate model objects which themselves have
``__name__`` attributes that contain the ``/`` character.
For people that have no models that have high-order Unicode
``__name__`` attributes or ``__name__`` attributes with values that
require URL-quoting with in their model graphs, this won't cause any
issue. However, if you have code that currently expects
``model_path`` to return an unquoted string, or you have an existing
application with data generated via the old method, and you're too
lazy to change anything, you may wish replace the BFG-imported
``model_path`` in your code with this function (this is the code of
the "old" ``model_path`` implementation)::
from repoze.bfg.location import lineage
def i_am_too_lazy_to_move_to_the_new_model_path(model, *elements):
rpath = []
for location in lineage(model):
if location.__name__:
rpath.append(location.__name__)
path = '/' + '/'.join(reversed(rpath))
if elements:
suffix = '/'.join(elements)
path = '/'.join([path, suffix])
return path
- The ``repoze.bfg.traversal.find_model`` API no longer implicitly
converts unicode representations of a full path passed to it as a
Unicode object into a UTF-8 string. Callers should either use
prequoted path strings returned by
``repoze.bfg.traversal.model_path``, or tuple values returned by the
result of ``repoze.bfg.traversal.model_path_tuple`` or they should
use the guidelines about passing a string ``path`` argument
described in the ``find_model`` API documentation.
- Each argument contained in ``elements`` passed to
``repoze.bfg.traversal.model_path`` will now have any ``/``
characters contained within quoted to ``%2F`` in the returned
string. Previously, ``/`` characters in elements were left unquoted
(a bug).
- A ``repoze.bfg.traversal.model_path_tuple`` API was added. This API
is an alternative to ``model_path`` (which returns a string);
``model_path_tuple`` returns a model path as a tuple (much like
Zope's ``getPhysicalPath``).
- A ``repoze.bfg.traversal.quote_path_segment`` API was added. This
API will quote an individual path segment (string or unicode
object). See the ``repoze.bfg.traversal`` API documentation for
more information.
|
|
--------
- The ``repoze.bfg.url.model_url`` API now works against contexts
derived from Routes URL dispatch (``Routes.util.url_for`` is called
under the hood).
- "Virtual root" support for traversal-based applications has been
added. Virtual root support is useful when you'd like to host some
model in a :mod:`repoze.bfg` model graph as an application under a
URL pathname that does not include the model path itself. For more
information, see the (new) "Virtual Hosting" chapter in the
documentation.
- A ``repoze.bfg.traversal.virtual_root`` API has been added. When
called, it returns the virtual root object (or the physical root
object if no virtual root has been specified).
Implementation Changes
----------------------
- ``repoze.bfg.traversal.RoutesModelTraverser`` has been moved to
``repoze.bfg.urldispatch``.
- ``model_url`` URL generation is now performed via an adapter lookup
based on the context and the request.
- ZCML which registers two adapters for the ``IContextURL`` interface
has been added to the configure.zcml in ``repoze.bfg.includes``.
|
|
"traversal" API chapter in the docs. This was a function previously
known as ``split_path`` that was not an API but people were using it
anyway. Unlike ``split_path`` it now returns a tuple instead of a
list (as its values are cached).
|
|
|
|
|
|
|
|
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.
|
|
method accepts keyword arguments. Each key/value pair in the
keyword arguments causes an assertion to be made that the renderer
received this key with a value equal to the asserted value.
- Projects generated by the paster templates now use the
``DummyTemplateRenderer.assert_`` method in their view tests.
|
|
module. Instances of this class are willing to act as BFG views
which return static resources using files on disk. See the
:mod:`repoze.bfg.view` docs for more info.
|
|
- A new module ``repoze.bfg.url`` has been added. It contains the
``model_url`` API (moved from ``repoze.bfg.traversal``) and an
implementation of ``urlencode`` (like Python's
``urllib.urlencode``) which can handle Unicode keys and values in
parameters to the ``query`` argument.
Deprecations
- The ``model_url`` function has been moved from
``repoze.bfg.traversal`` into ``repoze.bfg.url``. It can still
be imported from ``repoze.bfg.traversal`` but an import from
``repoze.bfg.traversal`` will emit a DeprecationWarning.
Features
- The ``repoze.bfg.url.model_url`` API (nee'
``repoze.bfg.traversal.model_url``) now accepts and honors a
keyword argument named ``query``. The value of this argument
will be used to compose a query string, which will be attached to
the generated URL before it is returned. See the API docs (in
the docs directory or `on the web
<http://static.repoze.org/bfgdocs>`_) for more information.
|
|
setuptools 0.6c9.
- Turn ``view_execution_permitted`` from the :mod:`repoze.bfg.view`
module into a documented API.
- Doc cleanups.
|
|
where the template does not need to be wrapped in any containing
XML).
Prep for 0.4.9.
|
|
|
|
|
|
- Added a ``repoze.bfg.testing`` module to attempt to make it
slightly easier to write unittest-based automated tests of BFG
applications. Information about this class is in the
documentation.
- The default template renderer now supports testing better by
looking for ``ITestingTemplateRenderer`` using a relative
pathname. This is exposed indirectly through the API named
``registerTemplate`` in ``repoze.bfg.testing``.
Deprecations
- The names ``repoze.bfg.interfaces.ITemplate`` ,
``repoze.bfg.interfaces.ITemplateFactory`` and
``repoze.bfg.interfaces.INodeTemplate`` have been deprecated.
These should now be imported as
``repoze.bfg.interfaces.ITemplateRenderer`` and
``repoze.bfg.interfaces.ITemplateRendererFactory``, and
``INodeTemplateRenderer`` respectively.
- The name ``repoze.bfg.chameleon_zpt.ZPTTemplateFactory`` is
deprecated. Use ``repoze.bfg.chameleon_zpt.ZPTTemplateRenderer``.
- The name ``repoze.bfg.chameleon_genshi.GenshiTemplateFactory`` is
deprecated. Use
``repoze.bfg.chameleon_genshi.GenshiTemplateRenderer``.
- The name ``repoze.bfg.xslt.XSLTemplateFactory`` is deprecated.
Use ``repoze.bfg.xslt.XSLTemplateRenderer``.
|
|
- The ``BFG_DEBUG_AUTHORIZATION`` envvar and the
``debug_authorization`` config file value now only imply debugging
of view-invoked security checks. Previously, information was
printed for every call to ``has_permission`` as well, which made
output confusing. To debug ``has_permission`` checks and other
manual permission checks, use the debugger and print statements in
your own code.
- Authorization debugging info is now only present in the HTTP
response body oif ``debug_authorization`` is true.
- The format of authorization debug messages was improved.
- A new ``BFG_DEBUG_NOTFOUND`` envvar was added and a symmetric
``debug_notfound`` config file value was added. When either is
true, and a NotFound response is returned by the BFG router
(because a view could not be found), debugging information is
printed to stderr. When this value is set true, the body of
HTTPNotFound responses will also contain the same debugging
information.
- ``Allowed`` and ``Denied`` responses from the security machinery
are now specialized into two types: ACL types, and non-ACL types.
The ACL-related responses are instances of
``repoze.bfg.security.ACLAllowed`` and
``repoze.bfg.security.ACLDenied``. The non-ACL-related responses
are ``repoze.bfg.security.Allowed`` and
``repoze.bfg.security.Denied``. The allowed-type responses
continue to evaluate equal to things that themselves evaluate
equal to the ``True`` boolean, while the denied-type responses
continue to evaluate equal to things that themselves evaluate
equal to the ``False`` boolean. The only difference between the
two types is the information attached to them for debugging
purposes.
- Added a new ``BFG_DEBUG_ALL`` envvar and a symmetric ``debug_all``
config file value. When either is true, all other debug-related
flags are set true unconditionally (e.g. ``debug_notfound`` and
``debug_authorization``).
Documentation
- Added info about debug flag changes.
- Added a section to the security chapter named "Debugging
Imperative Authorization Failures" (for e.g. ``has_permssion``).
|
|
- A ``repoze.bfg.location`` API module was added.
Backwards incompatibilities
- Applications must now use the ``repoze.bfg.interfaces.ILocation``
interface rather than ``zope.location.interfaces.ILocation`` to
represent that a model object is "location-aware". We've removed
a dependency on ``zope.location`` for cleanliness purposes: as
new versions of zope libraries are released which have improved
dependency information, getting rid of our dependence on
``zope.location`` will prevent a newly installed repoze.bfg
application from requiring the ``zope.security``, egg, which not
truly used at all in a "stock" repoze.bfg setup. These
dependencies are still required by the stack at this time; this
is purely a futureproofing move.
The security and model documentation for previous versions of
``repoze.bfg`` recommended using the
``zope.location.interfaces.ILocation`` interface to represent
that a model object is "location-aware". This documentation has
been changed to reflect that this interface should now be
imported from ``repoze.bfg.interfaces.ILocation`` instead.
|
|
|
|
|
|
|
|
|
|
named ``render_view_to_response``, ``render_view_to_iterable`` and
``is_response``, which are documented in the API docs. These features
aid programmatic (non-request-driven) view execution.
|
|
|
|
"get_options" from __init__.py of repoze.bfg; use repoze.bfg.router:make_app and repoze.bfg.registry:get_options instead.
|
|
|