Pyramid

Latest version: v2.0.2

Safety actively analyzes 638646 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 20 of 30

0.9a4

==================

Bug Fixes
---------

- Try checking for an "old style" security policy *after* we parse
ZCML (thinko).

0.9a3

==================

Features
--------

- Allow IAuthenticationPolicy and IAuthorizationPolicy to be
overridden via ZCML registrations (do ZCML parsing after
registering these in router.py).

Documentation
-------------

- Added "BFG Wiki" tutorial to documentation; it describes
step-by-step how to create a traversal-based ZODB application with
authentication.

Deprecations
------------

- Added deprecations for imports of ``ACLSecurityPolicy``,
``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``.

Deprecated Import Alias Removals
--------------------------------

- Remove ``repoze.bfg.template`` module. All imports from this
package have been deprecated since 0.3.8. Instead, import
``get_template``, ``render_template``, and
``render_template_to_response`` from the
``repoze.bfg.chameleon_zpt`` module.

- Remove backwards compatibility import alias for
``repoze.bfg.traversal.split_path`` (deprecated since 0.6.5). This
must now be imported as ``repoze.bfg.traversal.traversal_path``).

- Remove backwards compatibility import alias for
``repoze.bfg.urldispatch.RoutesContext`` (deprecated since 0.6.5).
This must now be imported as
``repoze.bfg.urldispatch.DefaultRoutesContext``.

- Removed backwards compatibility import aliases for
``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``.

- Removed backwards compatibility import alias for
``repoze.bfg.interfaces.IRootPolicy`` (deprecated since 0.6.2). It
must be imported as ``repoze.bfg.interfaces.IRootFactory`` now.

- Removed backwards compatibility import alias for
``repoze.bfg.interfaces.ITemplate`` (deprecated since 0.4.4). It
must be imported as ``repoze.bfg.interfaces.ITemplateRenderer`` now.

- Removed backwards compatibility import alias for
``repoze.bfg.interfaces.ITemplateFactory`` (deprecated since 0.4.4).
It must be imported as
``repoze.bfg.interfaces.ITemplateRendererFactory`` now.

- Removed backwards compatibility import alias for
``repoze.bfg.chameleon_zpt.ZPTTemplateFactory`` (deprecated since
0.4.4). This must be imported as ``repoze.bfg.ZPTTemplateRenderer``
now.

0.9a2

==================

Features
--------

- A paster command has been added named "bfgshell". This command can
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.

Deprecations
------------

- The name ``repoze.bfg.registry.registry_manager`` was never an API,
but scripts in the wild were using it to set up an environment for
use under a debug shell. A backwards compatibility shim has been
added for this purpose, but the feature is deprecated.

0.9a1

=================

Features
--------

- New API functions named ``forget`` and ``remember`` are available in
the ``security`` module. The ``forget`` function returns headers
which will cause the currently authenticated user to be logged out
when set in a response. The ``remember`` function (when passed the
proper arguments) will return headers which will cause a principal
to be "logged in" when set in a response. See the Security API
chapter of the docs for more info.

- New keyword arguments to the ``repoze.bfg.router.make_app`` call
have been added: ``authentication_policy`` and
``authorization_policy``. These should, respectively, be an
implementation of an authentication policy (an object implementing
the ``repoze.bfg.interfaces.IAuthenticationPolicy`` interface) and
an implementation of an authorization policy (an object implementing
``repoze.bfg.interfaces.IAuthorizationPolicy)``. Concrete
implementations of authentication policies exist in
``repoze.bfg.authentication``. Concrete implementations of
authorization policies exist in ``repoze.bfg.authorization``.

Both ``authentication_policy`` and ``authorization_policy`` default
to ``None``.

If ``authentication_policy`` is ``None``, but
``authorization_policy`` is *not* ``None``, then
``authorization_policy`` is ignored (the ability to do authorization
depends on authentication).

If the ``authentication_policy`` argument is *not* ``None``, and the
``authorization_policy`` argument *is* ``None``, the authorization
policy defaults to an authorization implementation that uses ACLs
(``repoze.bfg.authorization.ACLAuthorizationPolicy``).

We no longer encourage configuration of "security policies" using
ZCML, as previously we did for ``ISecurityPolicy``. This is because
it's not uncommon to need to configure settings for concrete
authorization or authentication policies using paste .ini
parameters; the app entry point for your application is the natural
place to do this.

- Two new abstractions have been added in the way of adapters used by
the system: an ``IAuthorizationPolicy`` and an
``IAuthenticationPolicy``. A combination of these (as registered by
the ``securitypolicy`` ZCML directive) take the place of the
``ISecurityPolicy`` abstraction in previous releases of repoze.who.
The API functions in ``repoze.who.security`` (such as
``authentication_userid``, ``effective_principals``,
``has_permission``, and so on) have been changed to try to make use
of these new adapters. If you're using an older ``ISecurityPolicy``
adapter, the system will still work, but it will print deprecation
warnings when such a policy is used.

- The way the (internal) IViewPermission utilities registered via ZCML
are invoked has changed. They are purely adapters now, returning a
boolean result, rather than returning a callable. You shouldn't have
been using these anyway. ;-)

- New concrete implementations of IAuthenticationPolicy have been
added to the ``repoze.bfg.authentication`` module:
``RepozeWho1AuthenticationPolicy`` which uses ``repoze.who``
identity to retrieve authentication data from and
``RemoteUserAuthenticationPolicy``, which uses the ``REMOTE_USER``
value in the WSGI environment to retrieve authentication data.

- A new concrete implementation of IAuthorizationPolicy has been added
to the ``repoze.bfg.authorization`` module:
``ACLAuthorizationPolicy`` which uses ACL inheritance to do
authorization.

- It is now possible to register a custom
``repoze.bfg.interfaces.IForbiddenResponseFactory`` for a given
application. This feature replaces the
``repoze.bfg.interfaces.IUnauthorizedAppFactory`` feature previously
described in the Hooks chapter. The IForbiddenResponseFactory will
be called when the framework detects an authorization failure; it
should accept a context object and a request object; it should
return an IResponse object (a webob response, basically). Read the
below point for more info and see the Hooks narrative chapter of the
BFG docs for more info.

Backwards Incompatibilities
---------------------------

- Custom NotFound and Forbidden (nee' Unauthorized) WSGI applications
(registered as 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 deprecated in favor of using the new
``repoze.bfg.interfaces.IForbiddenResponseFactory`` mechanism.

- The ``view_execution_permitted`` API should now be imported from the
``repoze.bfg.security`` module instead of the ``repoze.bfg.view``
module.

- The ``authenticated_userid`` and ``effective_principals`` APIs in
``repoze.bfg.security`` used to only take a single argument
(request). They now accept two arguments (``context`` and
``request``). Calling them with a single argument is still
supported but issues a deprecation warning. (NOTE: this change was
reverted in 0.9a7; meaning the 0.9 versions of these functions
again accept ``request`` only, just like 0.8 and before).

- Use of "old-style" security policies (those base on ISecurityPolicy)
is now deprecated. See the "Security" chapter of the docs for info
about activating an authorization policy and an authentication poicy.

0.8.1

==================

Features
--------

- Class objects may now be used as view callables (both via ZCML and
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.

- Removed the pickling of ZCML actions (the code that wrote
``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.

0.8

================

Features
--------

- 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.

Page 20 of 30

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.