| Age | Commit message (Collapse) | Author |
|---|
|
This interface is provided by all internal exception classes (such
as ``repoze.bfg.exceptions.NotFound`` and
``repoze.bfg.exceptions.Forbidden``), instances of which are both
exception objects and can behave as WSGI response objects. This
interface is made public so that exception classes which are also
valid WSGI response factories can be configured to implement them
or exception instances which are also or response instances can be
configured to provide them.
- New API class: ``repoze.bfg.view.AppendSlashNotFoundViewFactory`` (undoes
previous custom_notfound_view on request passsed to
append_slash_notfound_view).
- Previously, two default view functions were registered at
Configurator setup (one for ``repoze.bfg.exceptions.NotFound`` named
``default_notfound_view`` and one for
``repoze.bfg.exceptions.Forbidden`` named
``default_forbidden_view``) to render internal exception responses.
Those default view functions have been removed, replaced with a
generic default view function which is registered at Configurator
setup for the ``repoze.bfg.interfaces.IExceptionResponse`` interface
that simply returns the exception instance; the ``NotFound` and
``Forbidden`` classes are now still exception factories but they are
also response factories which generate instances that implement the
new ``repoze.bfg.interfaces.IExceptionResponse`` interface.
|
|
|
|
``set_request_factory``. If used, this method will set the factory
used by the :mod:`repoze.bfg` router to create all request objects.
- The ``Configurator`` constructor takes an additional argument:
``request_factory``. If used, this argument will set the factory
used by the :mod:`repoze.bfg` router to create all request objects.
- The ``Hooks`` narrative chapter now contains a section about
changing the request factory.
|
|
``_app_url`` is present in the arguments passed to ``route_url``,
this value will be used as the protocol/hostname/port/leading path
prefix of the generated URL. For example, using an ``_app_url`` of
``http://example.com:8080/foo`` would cause the URL
``http://example.com:8080/foo/fleeb/flub`` to be returned from this
function if the expansion of the route pattern associated with the
``route_name`` expanded to ``/fleeb/flub``.
- It is now possible to use a URL as the ``name`` argument fed to
``repoze.bfg.configuration.Configurator.add_static_view``. When the
name argument is a URL, the ``repoze.bfg.url.static_url`` API will
generate join this URL (as a prefix) to a path including the static
file name. This makes it more possible to put static media on a
separate webserver for production, while keeping static media
package-internal and served by the development webserver during
development.
|
|
$REPOZE_SVN/repoze.bfg/branches/i18n
No foreigners were harmed in the coding of this feature.
|
|
merge -r9054:9030 svn+ssh://repoze@svn.repoze.org/svn/repoze.bfg/trunk
|
|
|
|
|
|
|
|
the "phash" branch.
|
|
|
|
configuration into account in more places and uses glossary
references more liberally.
|
|
|
|
|
|
event listener.
|
|
removed; it has become unused.
- Change imperative API.
|
|
an IDebugLogger unnamed utility. A named utility with the old name
is registered for b/w compat.
|
|
traversal *after* url dispatch via ``<route>`` paths containing the
``*traverse`` element) were broken in 1.1-final and all 1.1 alpha
and beta releases. Views registered without a ``route_name`` route
shadowed views registered with a ``route_name`` inappropriately.
|
|
of this type will be sent after traversal is completed, but before
any view code is invoked. Like ``repoze.bfg.events.NewRequest``,
This event will have a single attribute: ``request`` representing
the current request. Unlike the request attribute of
``repoze.bfg.events.NewRequest`` however, during an AfterTraversal
event, the request object will possess attributes set by the
traverser, most notably ``context``, which will be the context used
when a view is found and invoked. The interface
``repoze.bfg.events.IAfterTraversal`` can be used to subscribe to
the event. For example::
<subscriber for="repoze.bfg.interfaces.IAfterTraversal"
handler="my.app.handle_after_traverse"/>
Like any framework event, a subscriber function should expect one
parameter: ``event``.
|
|
|
|
:mod:`repoze.bfg.url.model_url` Generates a URL`` to the "Hooks"
narrative chapter of the docs.
|
|
``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.
|
|
This should have no external effects.
- An object implementing the ``IRenderer`` interface (and
``ITemplateRenderer`, which is a subclass of ``IRenderer``) must now
accept an extra ``system`` argument in its ``__call__`` method
implementation. Values computed by the system (as opposed to by the
view) are passed by the system in the ``system`` parameter, which
will always be a dictionary. Keys in the dictionary include:
``view`` (the view object that returned the value),
``renderer_name`` (the template name or simple name of the
renderer), ``context`` (the context object passed to the view), and
``request`` (the request object passed to the view). Previously
only ITemplateRenderers received system arguments as elements inside
the main ``value`` dictionary.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
--------
- 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.
|
|
``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.
|
|
|
|
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``.
|
|
--------
- 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.
|
|
|
|
removed, as well as its documentation. It had been deprecated since
0.6.3. Code in ``repoze.bfg.urldispatch.RoutesModelTraverser``
which catered to it has also been removed.
- The semantics of the ``route`` ZCML directive have been simplified.
Previously, it was assumed that to use a route, you wanted to map a
route to an externally registered view. The new ``route`` directive
instead has a ``view`` attribute which is required, specifying the
dotted path to a view callable. When a route directive is
processed, a view is *registered* using the name attribute of the
route directive as its name and the callable as its value. The
``view_name`` and ``provides`` attributes of the ``route`` directive
are therefore no longer used. Effectively, if you were previously
using the ``route`` directive, it means you must change a pair of
ZCML directives that look like this::
<route
name="home"
path=""
view_name="login"
factory=".models.root.Root"
/>
<view
for=".models.root.Root"
name="login"
view=".views.login_view"
/>
To a ZCML directive that looks like this::
<route
name="home"
path=""
view=".views.login_view"
factory=".models.root.Root"
/>
In other words, to make old code work, remove the ``view``
directives that were only there to serve the purpose of backing
``route`` directives, and move their ``view=`` attribute into the
``route`` directive itself.
This change also necessitated that the ``name`` attribute of the
``route`` directive is now required. If you were previously using
``route`` directives without a ``name`` attribute, you'll need to
add one (the name is arbitrary, but must be unique among all
``route`` and ``view`` statements).
The ``provides`` attribute of the ``route`` directive has also been
removed. This directive specified a sequence of interface types
that the generated context would be decorated with. Since route
views are always generated now for a single interface
(``repoze.bfg.IRoutesContext``) as opposed to being looked up
arbitrarily, there is no need to decorate any context to ensure a
view is found.
- The Routes ``Route`` object used to resolve the match is now put
into the environment as ``bfg.route`` when URL dispatch is used.
|
|
only used as a deprecation mechanism, so where possible we've kept around
the deprecation warnings and we've used zope.deprectation instead. However,
when cross-module deprecations were included, rather than introducing a
cyclic dependency, we just removed the deprecation itself.
As a result:
- Since version 0.6.1, a deprecation warning has been emitted when the
name ``model_url`` is imported from the ``repoze.bfg.traversal``
module. This import alias (and the deprecation warning) has been
removed. Any import of the ``model_url`` function will now need to
be done from ``repoze.bfg.url``; any import of the name
``model_url`` from ``repoze.bfg.traversal`` will now fail. This was
done to remove a dependency on zope.deferredimport.
- Since version 0.6.5, a deprecation warning has been emitted when the
name ``RoutesModelTraverser`` is imported from the
``repoze.bfg.traversal`` module. This import alias (and the
deprecation warning) has been removed. Any import of the
``RoutesModelTraverser`` class will now need to be done from
``repoze.bfg.urldispatch``; any import of the name
``RoutesModelTraverser`` from ``repoze.bfg.traversal`` will now
fail. This was done to remove a dependency on zope.deferredimport.
|
|
|
|
``repoze.bfg.location.ClassAndInstanceDescr`` class have both been
removed in order to be able to eventually shed a dependency on
``zope.proxy``. Neither of these classes was ever an API.
- In all previous releases, the ``repoze.bfg.location.locate``
function worked like so: if a model did not explicitly provide the
``repoze.bfg.interfaces.ILocation`` interface, ``locate`` returned a
``LocationProxy`` object representing ``model`` with its
``__parent__`` attribute assigned to ``parent`` and a ``__name__``
attribute assigned to ``__name__``. In this release, the
``repoze.bfg.location.locate`` function simply jams the ``__name__``
and ``__parent__`` attributes on to the supplied model
unconditionally, no matter if the object implements ILocation or
not, and it never returns a proxy. This was done because the
LocationProxy behavior has now moved into an add-on package
(``repoze.bfg.traversalwrapper``), in order to eventually be able to
shed a dependency on ``zope.proxy``.
- In all previous releases, by default, if traversal was used (as
opposed to URL-dispatch), and the root object supplied
the``repoze.bfg.interfaces.ILocation`` interface, but the children
returned via its ``__getitem__`` returned an object that did not
implement the same interface, :mod:`repoze.bfg` provided some
implicit help during traversal. This traversal feature wrapped
subobjects from the root (and thereafter) that did not implement
``ILocation`` in proxies which automatically provided them with a
``__name__`` and ``__parent__`` attribute based on the name being
traversed and the previous object traversed. This feature has now
been removed from the base ``repoze.bfg`` package for purposes of
eventually shedding a dependency on ``zope.proxy``.
In order to re-enable the wrapper behavior for older applications
which cannot be changed, register the "traversalwrapper"
``ModelGraphTraverser`` as the traversal policy, rather than the
default ``ModelGraphTraverser``. To use this feature, you will need
to install the ``repoze.bfg.traversalwrapper`` package (an add-on
package, available at
http://svn.repoze.org/repoze.bfg.traversalwrapper) Then change your
application's ``configure.zcml`` to include the following stanza:
<adapter
factory="repoze.bfg.traversalwrapper.ModelGraphTraverser"
provides="repoze.bfg.interfaces.ITraverserFactory"
for="*"
/>
When this ITraverserFactory is used instead of the default, no
object in the graph (even the root object) must supply a
``__name__`` or ``__parent__`` attribute. Even if subobjects
returned from the root *do* implement the ILocation interface,
these will still be wrapped in proxies that override the object's
"real" ``__parent__`` and ``__name__`` attributes.
See also changes to the "Models" chapter of the documentation (in
the "Location-Aware Model Instances") section.
|
|
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.
|
|
--------
- 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``.
|
|
consults a utility to generate the base model url (without extra
elements or a query string). Eventually this will service virtual
hosting; for now it's undocumented and should not be hooked.
|
|
``ACLSecurityPolicy`` now does what it did inline.
- Get rid of ``repoze.bfg.interfaces.NoAuthorizationInformation``
exception: it was used only by ``ACLAuthorizer``.
|
