Pyramid

Latest version: v2.0.2

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

Scan your dependencies

Page 16 of 30

1.1a3

Not secure
==================

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

- The "Views" narrative chapter in the documentation has been updated
extensively to discuss "renderers".

Features
--------

- A ``renderer`` attribute has been added to view configurations,
replacing the previous (1.1a2) version's ``template`` attribute. A
"renderer" is an object which accepts the return value of a view and
converts it to a string. This includes, but is not limited to,
templating systems.

- A new interface named ``IRenderer`` was added. The existing
interface, ``ITemplateRenderer`` now derives from this new
interface. This interface is internal.

- A new interface named ``IRendererFactory`` was added. An existing
interface named ``ITemplateRendererFactory`` now derives from this
interface. This interface is internal.

- The ``view`` attribute of the ``view`` ZCML directive is no longer
required if the ZCML directive also has a ``renderer`` attribute.
This is useful when the renderer is a template renderer and no names
need be passed to the template at render time.

- A new zcml directive ``renderer`` has been added. It is documented
in the "Views" narrative chapter of the documentation.

- A ZCML ``view`` directive (and the associated ``bfg_view``
decorator) can now accept a "wrapper" value. If a "wrapper" value
is supplied, it is the value of a separate view's *name* attribute.
When a view with a ``wrapper`` attribute is rendered, the "inner"
view is first rendered normally. Its body is then attached to the
request as "wrapped_body", and then a wrapper view name is looked up
and rendered (using ``repoze.bfg.render_view_to_response``), passed
the request and the context. The wrapper view is assumed to do
something sensible with ``request.wrapped_body``, usually inserting
its structure into some other rendered template. This feature makes
it possible to specify (potentially nested) "owrap" relationships
between views using only ZCML or decorators (as opposed always using
ZPT METAL and analogues to wrap view renderings in outer wrappers).

Dependencies
------------

- When used under Python < 2.6, BFG now has an installation time
dependency on the ``simplejson`` package.

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

- The ``repoze.bfg.testing.registerDummyRenderer`` API has been
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"; its existence has been removed from the
documentation, however.

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

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

- The ``ITemplateRenderer`` interface has been changed. Previously
its ``__call__`` method accepted ``**kw``. It now accepts a single
positional parameter named ``kw`` (REVISED: it accepts two
positional parameters as of 1.1a4: ``value`` and ``system``). This
is mostly an internal change, but it was exposed in APIs in one
place: if you've used the
``repoze.bfg.testing.registerDummyRenderer`` API in your tests with
a custom "renderer" argument with your own renderer implementation,
you will need to change that renderer implementation to accept
``kw`` instead of ``**kw`` in its ``__call__`` method (REVISED: make
it accept ``value`` and ``system`` positional arguments as of 1.1a4).

- The ``ITemplateRendererFactory`` interface has been changed.
Previously its ``__call__`` method accepted an ``auto_reload``
keyword parameter. Now its ``__call__`` method accepts no keyword
parameters. Renderers are now themselves responsible for
determining details of auto-reload. This is purely an internal
change. This interface was never external.

- The ``template_renderer`` ZCML directive introduced in 1.1a2 has
been removed. It has been replaced by the ``renderer`` directive.

- The previous release (1.1a2) added a view configuration attribute
named ``template``. In this release, the attribute has been renamed
to ``renderer``. This signifies that the attribute is more generic:
it can now be not just a template name but any renderer name (ala
``json``).

- In the previous release (1.1a2), the Chameleon text template
renderer was used if the system didn't associate the ``template``
view configuration value with a filename with a "known" extension.
In this release, you must use a ``renderer`` attribute which is a
path that ends with a ``.txt`` extension
(e.g. ``templates/foo.txt``) to use the Chameleon text renderer.

1.1a2

Not secure
==================

Features
--------

- A ZCML ``view`` directive (and the associated ``bfg_view``
decorator) can now accept an "attr" value. If an "attr" value is
supplied, it is considered a method named of the view object to be
called when the response is required. This is typically only good
for views that are classes or instances (not so useful for
functions, as functions typically have no methods other than
``__call__``).

- A ZCML ``view`` directive (and the associated ``bfg_view``
decorator) can now accept a "template" value. If a "template" value
is supplied, and the view callable returns a dictionary, the
associated template is rendered with the dictionary as keyword
arguments. See the section named "Views That Have a ``template``"
in the "Views" narrative documentation chapter for more information.

1.1a1

Not secure
==================

Bug Fixes
---------

- "tests" module removed from the bfg_alchemy paster template; these
tests didn't work.

- Bugfix: the ``discriminator`` for the ZCML "route" directive was
incorrect. It was possible to register two routes that collided
without the system spitting out a ConfigurationConflictError at
startup time.

Features
--------

- Feature addition: view predicates. These are exposed as the
``request_method``, ``request_param``, and ``containment``
attributes of a ZCML ``view`` declaration, or the respective
arguments to a ``bfg_view`` decorator. View predicates can be used
to register a view for a more precise set of environment parameters
than was previously possible. For example, you can register two
views with the same ``name`` with different ``request_param``
attributes. If the ``request.params`` dict contains 'foo'
(request_param="foo"), one view might be called; if it contains
'bar' (request_param="bar"), another view might be called.
``request_param`` can also name a key/value pair ala ``foo=123``.
This will match only when the ``foo`` key is in the request.params
dict and it has the value '123'. This particular example makes it
possible to write separate view functions for different form
submissions. The other predicates, ``containment`` and
``request_method`` work similarly. ``containment`` is a view
predicate that will match only when the context's graph lineage has
an object possessing a particular class or interface, for example.
``request_method`` is a view predicate that will match when the HTTP
``REQUEST_METHOD`` equals some string (eg. 'POST').

- The ``bfg_view`` decorator now accepts three additional arguments:
``request_method``, ``request_param``, and ``containment``.
``request_method`` is used when you'd like the view to match only a
request with a particular HTTP ``REQUEST_METHOD``; a string naming
the ``REQUEST_METHOD`` can also be supplied as ``request_type`` for
backwards compatibility. ``request_param`` is used when you'd like
a view to match only a request that contains a particular
``request.params`` key (with or without a value). ``containment``
is used when you'd like to match a request that has a context that
has some class or interface in its graph lineage. These are
collectively known as "view predicates".

- The ``route`` ZCML directive now honors ``view_request_method``,
``view_request_param`` and ``view_containment`` attributes, which
pass along these values to the associated view if any is provided.
Additionally, the ``request_type`` attribute can now be spelled as
``view_request_type``, and ``permission`` can be spelled as
``view_permission``. Any attribute which starts with ``view_`` can
now be spelled without the ``view_`` prefix, so ``view_for`` can be
spelled as ``for`` now, etc. Both forms are documented in the
urldispatch narrative documentation chapter.

- The ``request_param`` ZCML view directive attribute (and its
``bfg_view`` decorator cousin) can now specify both a key and a
value. For example, ``request_param="foo=123"`` means that the foo
key must have a value of ``123`` for the view to "match".

- Allow ``repoze.bfg.traversal.find_interface`` API to use a class
object as the argument to compare against the ``model`` passed in.
This means you can now do ``find_interface(model, SomeClass)`` and
the first object which is found in the lineage which has
``SomeClass`` as its class (or the first object found which has
``SomeClass`` as any of its superclasses) will be returned.

- Added ``static`` ZCML directive which registers a route for a view
that serves up files in a directory. See the "Views" narrative
documentation chapter's "Serving Static Resources Using a ZCML
Directive" section for more information.

- The ``repoze.bfg.view.static`` class now accepts a string as its
first argument ("root_dir") that represents a package-relative name
e.g. ``somepackage:foo/bar/static``. This is now the preferred
mechanism for spelling package-relative static paths using this
class. A ``package_name`` keyword argument has been left around for
backwards compatibility. If it is supplied, it will be honored.

- The API ``repoze.bfg.testing.registerView`` now takes a
``permission`` argument. Use this instead of using
``repoze.bfg.testing.registerViewPermission``.

- The ordering of route declarations vs. the ordering of view
declarations that use a "route_name" in ZCML no longer matters.
Previously it had been impossible to use a route_name from a route
that had not yet been defined in ZCML (order-wise) within a "view"
declaration.

- The repoze.bfg router now catches both
``repoze.bfg.security.Unauthorized`` and
``repoze.bfg.view.NotFound`` exceptions while rendering a view.
When the router catches an ``Unauthorized``, it returns the
registered forbidden view. When the router catches a ``NotFound``,
it returns the registered notfound view.

Internal
--------

- Change urldispatch internals: Route object is now constructed using
a path, a name, and a factory instead of a name, a matcher, a
generator, and a factory.

- Move (non-API) default_view, default_forbidden_view, and
default_notfound_view functions into the ``repoze.bfg.view`` module
(moved from ``repoze.bfg.router``).

- Removed ViewPermissionFactory from ``repoze.bfg.security``. View
permission checking is now done by registering and looking up an
ISecuredView.

- The ``static`` ZCML directive now uses a custom root factory when
constructing a route.

- The interface ``IRequestFactories`` was removed from the
repoze.bfg.interfaces module. This interface was never an API.

- The function named ``named_request_factories`` and the data
structure named ``DEFAULT_REQUEST_FACTORIES`` have been removed from
the ``repoze.bfg.request`` module. These were never APIs.

- The ``IViewPermissionFactory`` interface has been removed. This was
never an API.

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

- Request-only-convention examples in the "Views" narrative
documentation were broken.

- Fixed documentation bugs related to forget and remember in security API
docs.

- Fixed documentation for ``repoze.bfg.view.static`` (in narrative
``Views`` chapter).

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

- The API ``repoze.bfg.testing.registerViewPermission`` has been
deprecated.

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

- The interfaces ``IPOSTRequest``, ``IGETRequest``, ``IPUTRequest``,
``IDELETERequest``, and ``IHEADRequest`` have been removed from the
``repoze.bfg.interfaces`` module. These were not documented as APIs
post-1.0. Instead of using one of these, use a ``request_method``
ZCML attribute or ``request_method`` bfg_view decorator parameter
containing an HTTP method name (one of ``GET``, ``POST``, ``HEAD``,
``PUT``, ``DELETE``) instead of one of these interfaces if you were
using one explicitly. Passing a string in the set (``GET``,
``HEAD``, ``PUT``, ``POST``, ``DELETE``) as a ``request_type``
argument will work too. Rationale: instead of relying on interfaces
attached to the request object, BFG now uses a "view predicate" to
determine the request type.

- Views registered without the help of the ZCML ``view`` directive are
now responsible for performing their own authorization checking.

- The ``registry_manager`` backwards compatibility alias importable
from "repoze.bfg.registry", deprecated since repoze.bfg 0.9 has been
removed. If you are tring to use the registry manager within a
debug script of your own, use a combination of the
"repoze.bfg.paster.get_app" and "repoze.bfg.scripting.get_root" APIs
instead.

- The ``INotFoundAppFactory`` interface has been removed; it has
been deprecated since repoze.bfg 0.9. If you have something like
the following in your ``configure.zcml``::

<utility provides="repoze.bfg.interfaces.INotFoundAppFactory"
component="helloworld.factories.notfound_app_factory"/>

Replace it with something like::

<notfound
view="helloworld.views.notfound_view"/>

See "Changing the Not Found View" in the "Hooks" chapter of the
documentation for more information.

- The ``IUnauthorizedAppFactory`` interface has been removed; it has
been deprecated since repoze.bfg 0.9. If you have something like
the following in your ``configure.zcml``::

<utility provides="repoze.bfg.interfaces.IUnauthorizedAppFactory"
component="helloworld.factories.unauthorized_app_factory"/>

Replace it with something like::

<forbidden
view="helloworld.views.forbidden_view"/>

See "Changing the Forbidden View" in the "Hooks" chapter of the
documentation for more information.

- ``ISecurityPolicy``-based security policies, deprecated since
repoze.bfg 0.9, have been removed. If you have something like this
in your ``configure.zcml``, it will no longer work::

<utility
provides="repoze.bfg.interfaces.ISecurityPolicy"
factory="repoze.bfg.security.RemoteUserInheritingACLSecurityPolicy"
/>

If ZCML like the above exists in your application, you will receive
an error at startup time. Instead of the above, you'll need
something like::

<remoteuserauthenticationpolicy/>
<aclauthorizationpolicy/>

This is just an example. See the "Security" chapter of the
repoze.bfg documentation for more information about configuring
security policies.

- Custom ZCML directives which register an authentication or
authorization policy (ala "authtktauthenticationpolicy" or
"aclauthorizationpolicy") should register the policy "eagerly" in
the ZCML directive instead of from within a ZCML action. If an
authentication or authorization policy is not found in the component
registry by the view machinery during deferred ZCML processing, view
security will not work as expected.

1.0.1

Not secure
==================

- Added support for ``has_resource``, ``resource_isdir``, and
``resource_listdir`` to the resource "OverrideProvider"; this fixes
a bug with a symptom that a file could not be overridden in a
resource directory unless a file with the same name existed in the
original directory being overridden.

- Fixed documentation bug showing invalid test for values from the
``matchdict``: they are stored as attributes of the ``Article``, rather
than subitems.

- Fixed documentation bug showing wrong environment key for the ``matchdict``
produced by the matching route.

- Added a workaround for a bug in Python 2.6, 2.6.1, and 2.6.2 having
to do with a recursion error in the mimetypes module when trying to
serve static files from Paste's FileApp:
https://bugs.python.org/issue5853. Symptom: File
"/usr/lib/python2.6/mimetypes.py", line 244, in guess_type return
guess_type(url, strict) RuntimeError: maximum recursion depth
exceeded. Thanks to Armin Ronacher for identifying the symptom and
pointing out a fix.

- Minor edits to tutorials for accuracy based on feedback.

- Declared Paste and PasteDeploy dependencies.

1.0

Not secure
================

- Retested and added some content to GAE tutorial.

- Edited "Extending" narrative docs chapter.

- Added "Deleting the Database" section to the "Defining Models"
chapter of the traversal wiki tutorial.

- Spell checking of narratives and tutorials.

1.0b3

Not secure
==================

Bug Fixes
---------

- Use &copy; instead of copyright symbol in paster templates / tutorial
templates for the benefit of folks who cutnpaste and save to a non-UTF8
format.

- ``pyramid.view.append_slash_notfound_view`` now preserves GET query
parameters across redirects.

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

- Beef up documentation related to ``set_default_permission``: explicitly
mention that default permissions also protect exception views.

- Paster templates and tutorials now use spaces instead of tabs in their HTML
templates.

Page 16 of 30

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.