| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
``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``.
|
|
|
|
via use of the ``bfg_view`` decorator in Python 2.6 as a class
decorator). The calling semantics when using a class as a view
callable is similar to that of using a class as a Zope "browser
view": the class' ``__init__`` must accept two positional parameters
(conventionally named ``context``, and ``request``). The resulting
instance must be callable (it must have a ``__call__`` method).
When called, the instance should return a response. For example::
from webob import Response
class MyView(object):
def __init__(self, context, request):
self.context = context
self.request = request
def __call__(self):
return Response('hello from %s!' % self.context)
See the "Views" chapter in the documentation and the
``repoze.bfg.view`` API documentation for more information.
|
|
|
|
``configure.zcml.cache`` next to ``configure.zcml`` files in
projects). The code which managed writing and reading of the cache
file was a source of subtle bugs when users switched between
imperative (e.g. ``@bfg_view``) registrations and declarative
registrations (e.g. the ``view`` directive in ZCML) on the same
project. On a moderately-sized project (535 ZCML actions and 15 ZCML
files), executing actions read from the pickle was saving us only
about 200ms (2.5 sec vs 2.7 sec average). On very small projects (1
ZCML file and 4 actions), startup time was comparable, and sometimes
even slower when reading from the pickle, and both ways were so fast
that it really just didn't matter anyway.
|
|
|
|
|
|
--------
- 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.
|
|
|
|
``registerAdapter``, ``registerUtiity``, ``registerSubscriber``, and
``cleanUp``.
- Added glossary entry for "root factory".
|
|
|
|
|
|
|
|
|
|
sets up a BFG project that uses SQAlchemy (with SQLite) and uses
Routes exclusively to resolve URLs (no traversal root factory is
used). This template can be used via ``paster create -t
bfg_routesalchemy``.
|
|
|
|
|
|
to ``repoze.bfg.router.make_app`` became optional if any ``route``
declaration was made in ZCML. The intent was to make it possible to
disuse traversal entirely, instead relying entirely on URL dispatch
(Routes) to resolve all contexts. However a compound set of bugs
prevented usage of a Routes-based root view (a view which responds
to "/"). One bug existed in `repoze.bfg.urldispatch``, another
existed in Routes itself.
To resolve this issue, the urldispatch module was fixed, and a fork
of the Routes trunk was put into the "dev" index named
``Routes-1.11dev-chrism-home``. The source for the fork exists at
`http://bitbucket.org/chrism/routes-home/
<http://bitbucket.org/chrism/routes-home/>`_; its contents have been
reported to the upstream Routes developers and will hopefully be a
part of the final Routes 1.11 release.
|
|
|
|
|
|
|
|
--------
- 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"
/>
|
|
|
|
and cleanUp functions in repoze.bfg.testing. Our dependencies still rely on zope.testing, however.
|
|
application runtime. This allows us to get rid of ``zope.testing``
on platforms like GAE which have file limits.
|
|
|
|
|
|
package within the ``configure.zcml`` of the "repoze.bfg.includes"
package. This has been a no-op for some time now.
-The ``repoze.bfg.chameleon_zpt`` package no longer imports from
``chameleon.zpt`` at module scope, deferring the import until later
within a method call. The ``chameleon.zpt`` package can't be
imported on platforms like GAE.
|
