Pyramid

Latest version: v2.0.2

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

Scan your dependencies

Page 18 of 30

1.0a6

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

Bug Fixes
---------

- Use ``caller_package`` function instead of ``caller_module``
function within ``templating`` to avoid needing to name the caller
module in resource overrides (actually match docs).

- Make it possible to override templates stored directly in a module
with templates in a subdirectory of the same module, stored directly
within another module, or stored in a subdirectory of another module
(actually match docs).

1.0a5

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

Features
--------

- A new ZCML directive exists named "resource". This ZCML directive
allows you to override Chameleon templates within a package (both
directories full of templates and individual template files) with
other templates in the same package or within another package. This
allows you to "fake out" a view's use of a template, causing it to
retrieve a different template than the one actually named by a
relative path to a call like
``render_template_to_response('templates/mytemplate.pt')``. For
example, you can override a template file by doing::

<resource
to_override="some.package:templates/mytemplate.pt"
override_with="another.package:othertemplates/anothertemplate.pt"
/>

The string passed to "to_override" and "override_with" is named a
"specification". The colon separator in a specification separates
the package name from a package-relative directory name. The colon
and the following relative path are optional. If they are not
specified, the override attempts to resolve every lookup into a
package from the directory of another package. For example::

<resource
to_override="some.package"
override_with="another.package"
/>


Individual subdirectories within a package can also be overridden::

<resource
to_override="some.package:templates/"
override_with="another.package:othertemplates/"
/>

If you wish to override a directory with another directory, you must
make sure to attach the slash to the end of both the ``to_override``
specification and the ``override_with`` specification. If you fail
to attach a slash to the end of a specification that points a
directory, you will get unexpected results. You cannot override a
directory specification with a file specification, and vice versa (a
startup error will occur if you try).

You cannot override a resource with itself (a startup error will
occur if you try).

Only individual *package* resources may be overridden. Overrides
will not traverse through subpackages within an overridden package.
This means that if you want to override resources for both
``some.package:templates``, and ``some.package.views:templates``,
you will need to register two overrides.

The package name in a specification may start with a dot, meaning
that the package is relative to the package in which the ZCML file
resides. For example::

<resource
to_override=".subpackage:templates/"
override_with="another.package:templates/"
/>

Overrides for the same ``to_overrides`` specification can be named
multiple times within ZCML. Each ``override_with`` path will be
consulted in the order defined within ZCML, forming an override
search path.

Resource overrides can actually override resources other than
templates. Any software which uses the ``pkg_resources``
``get_resource_filename``, ``get_resource_stream`` or
``get_resource_string`` APIs will obtain an overridden file when an
override is used. However, the only built-in facility which uses
the ``pkg_resources`` API within BFG is the templating stuff, so we
only call out template overrides here.

- Use the ``pkg_resources`` API to locate template filenames instead
of dead-reckoning using the ``os.path`` module.

- The ``repoze.bfg.templating`` module now uses ``pkg_resources`` to
locate and register template files instead of using an absolute
path name.

1.0a4

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

Features
--------

- Cause ``:segment`` matches in route paths to put a Unicode-decoded
and URL-dequoted value in the matchdict for the value matched.
Previously a non-decoded non-URL-dequoted string was placed in the
matchdict as the value.

- Cause ``*remainder`` matches in route paths to put a *tuple* in the
matchdict dictionary in order to be able to present Unicode-decoded
and URL-dequoted values for the traversal path. Previously a
non-decoded non-URL-dequoted string was placed in the matchdict as
the value.

- Add optional ``max_age`` keyword value to the ``remember`` method of
``repoze.bfg.authentication.AuthTktAuthenticationPolicy``; if this
value is passed to ``remember``, the generated cookie will have a
corresponding Max-Age value.

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

- Add information to the URL Dispatch narrative documentation about
path pattern matching syntax.

Bug Fixes
---------

- Make ``route_url`` URL-quote segment replacements during generation.
Remainder segments are not quoted.

1.0a3

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

Implementation Changes
----------------------

- ``repoze.bfg`` no longer relies on the Routes package to interpret
URL paths. All known existing ``path`` patterns will continue to
work with the reimplemented logic, which lives in
``repoze.bfg.urldispatch``. ``<route>`` ZCML directives which use
certain attributes (uncommon ones) may not work (see "Backwards
Incompatibilities" below).

Bug Fixes
---------

- ``model_url`` when passed a request that was generated as a result
of a route match would fail in a call to ``route.generate``.

- BFG-on-GAE didn't work due to a corner case bug in the fallback
Python implementation of ``threading.local`` (symptom:
"Initialization arguments are not supported"). Thanks to Michael
Bernstein for the bug report.

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

- Added a "corner case" explanation to the "Hybrid Apps" chapter
explaining what to do when "the wrong" view is matched.

- Use ``repoze.bfg.url.route_url`` API in tutorials rather than Routes
``url_for`` API.

Features
--------

- Added the ``repoze.bfg.url.route_url`` API. This API allows you to
generate URLs based on ``<route>`` declarations. See the URL
Dispatch narrative chapter and the "repoze.bfg.url" module API
documentation for more information.

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

- As a result of disusing Routes, using the Routes ``url_for`` API
inside a BFG application (as was suggested by previous iterations of
tutorials) will no longer work. Use the
``repoze.bfg.url.route_url`` method instead.

- The following attributes on the ``<route>`` ZCML directive no longer
work: ``encoding``, ``static``, ``filter``, ``condition_method``,
``condition_subdomain``, ``condition_function``, ``explicit``, or
``subdomains``. These were all Routes features.

- The ``<route>`` ZCML directive no longer supports the
``<requirement>`` subdirective. This was a Routes feature.

1.0a2

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

Bug Fixes
---------

- The ``bfg_routesalchemy`` paster template app tests failed due to a
mismatch between test and view signatures.

Features
--------

- Add a ``view_for`` attribute to the ``route`` ZCML directive. This
attribute should refer to an interface or a class (ala the ``for``
attribute of the ``view`` ZCML directive).

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

- Conditional documentation in installation section ("how to install a
Python interpreter").

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

- The ``callback`` argument of the ``repoze.bfg.authentication``
authentication policies named ``RepozeWho1AuthenticationPolicy``,
``RemoteUserAuthenticationPolicy``, and
``AuthTktAuthenticationPolicy`` now must accept two positional
arguments: the original argument accepted by each (userid or
identity) plus a second argument, which will be the current request.
Apologies, this is required to service finding groups when there is
no "global" database connection.

1.0a1

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

Features
--------

- A new ZCML directive was added named ``notfound``. This ZCML
directive can be used to name a view that should be invoked when the
request can't otherwise be resolved to a view callable. For example::

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

- A new ZCML directive was added named ``forbidden``. This ZCML
directive can be used to name a view that should be invoked when a
view callable for a request is found, but cannot be invoked due to
an authorization failure. For example::

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

- Allow views to be *optionally* defined as callables that accept only
a request object, instead of both a context and a request (which
still works, and always will). The following types work as views in
this style:

- functions that accept a single argument ``request``, e.g.::

def aview(request):
pass

- new and old-style classes that have an ``__init__`` method that
accepts ``self, request``, e.g.::

def View(object):
__init__(self, request):
pass

- Arbitrary callables that have a ``__call__`` method that accepts
``self, request``, e.g.::

def AView(object):
def __call__(self, request):
pass
view = AView()

This likely should have been the calling convention all along, as
the request has ``context`` as an attribute already, and with views
called as a result of URL dispatch, having the context in the
arguments is not very useful. C'est la vie.

- Cache the absolute path in the caller's package globals within
``repoze.bfg.path`` to get rid of repeated (expensive) calls to
os.path.abspath.

- Add ``reissue_time`` and ``timeout`` parameters to
``repoze.bfg.authentication.AuthTktAuthenticationPolicy``
constructor. If these are passed, cookies will be reset every so
often (cadged from the same change to repoze.who lately).

- The matchdict related to the matching of a Routes route is available
on the request as the ``matchdict`` attribute:
``request.matchdict``. If no route matched, this attribute will be
None.

- Make 404 responses slightly cheaper by showing
``environ["PATH_INFO"]`` on the notfound result page rather than the
fullly computed URL.

- Move LRU cache implementation into a separate package
(``repoze.lru``).

- The concepts of traversal and URL dispatch have been unified. It is
now possible to use the same sort of factory as both a traversal
"root factory" and what used to be referred to as a urldispatch
"context factory".

- When the root factory argument (as a first argument) passed to
``repoze.bfg.router.make_app`` is ``None``, a *default* root factory
is used. This is in support of using routes as "root finders"; it
supplants the idea that there is a default
``IRoutesContextFactory``.

- The `view`` ZCML statement and the ``repoze.bfg.view.bfg_view``
decorator now accept an extra argument: ``route_name``. If a
``route_name`` is specified, it must match the name of a previously
defined ``route`` statement. When it is specified, the view will
only be called when that route matches during a request.

- It is now possible to perform traversal *after* a route has matched.
Use the pattern ``*traverse`` in a ``<route>`` ``path`` attribute
within ZCML, and the path remainder which it matches will be used as
a traversal path.

- When any route defined matches, the WSGI environment will now
contain a key ``bfg.routes.route`` (the Route object which matched),
and a key ``bfg.routes.matchdict`` (the result of calling route.match).

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

- Utility registrations against
``repoze.bfg.interfaces.INotFoundView`` and
``repoze.bfg.interfaces.IForbiddenView`` are now deprecated. Use
the ``notfound`` and ``forbidden`` ZCML directives instead (see the
"Hooks" chapter for more information). Such registrations will
continue to work, but the notfound and forbidden directives do
"extra work" to ensure that the callable named by the directive can
be called by the router even if it's a class or
request-argument-only view.

Removals
--------

- The ``IRoutesContext``, ``IRoutesContextFactory``, and
``IContextNotFound`` interfaces were removed from
``repoze.bfg.interfaces``. These were never APIs.

- The ``repoze.bfg.urldispatch.RoutesContextNotFound``,
``repoze.bfg.urldispatch.RoutesModelTraverser`` and
``repoze.bfg.urldispatch.RoutesContextURL`` classes were removed.
These were also never APIs.

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

- Moved the ``repoze.bfg.push`` module, which implemented the ``pushpage``
decorator, into a separate distribution, ``repoze.bfg.pushpage``.
Applications which used this decorator should continue to work after
adding that distribution to their installation requirements.

- Changing the default request factory via an IRequestFactory utility
registration (as used to be documented in the "Hooks" chapter's
"Changing the request factory" section) is no longer supported. The
dance to manufacture a request is complicated as a result of
unifying traversal and url dispatch, making it highly unlikely for
anyone to be able to override it properly. For those who just want
to decorate or modify a request, use a NewRequestEvent subscriber
(see the Events chapter in the documentation).

- The ``repoze.bfg.IRequestFactory`` interface was removed. See the
bullet above for why.

- Routes "context factories" (spelled as the factory argument to a
route statement in ZCML) must now expect the WSGI environ as a
single argument rather than a set of keyword arguments. They can
obtain the match dictionary by asking for
environ['bfg.routes.matchdict']. This is the same set of keywords
that used to be passed to urldispatch "context factories" in BFG 0.9
and below.

- Using the ``zope.component.adapter`` decorator on a bfg view
function no longer works. Use the ``repoze.bfg.view.bfg_view``
decorator instead to mark a function (or a class) as a view.

- The name under which the matching route object is found in the
environ was changed from ``bfg.route`` to ``bfg.routes.route``.

- Finding the root is now done *before* manufacturing a request object
(and sending a new request event) within the router (it used to be
performed afterwards).

- Adding ``*path_info`` to a route no longer changes the PATH_INFO for
a request that matches using URL dispatch. This feature was only
there to service the ``repoze.bfg.wsgi.wsgiapp2`` decorator and it
did it wrong; use ``*subpath`` instead now.

- The values of ``subpath``, ``traversed``, and ``virtual_root_path``
attached to the request object are always now tuples instead of
lists (performance).

Bug Fixes
---------

- The ``bfg_alchemy`` Paster template named "repoze.tm" in its
pipeline rather than "repoze.tm2", causing the startup to fail.

- Move BBB logic for registering an
IAuthenticationPolicy/IForbiddenView/INotFoundView based on older
concepts from the router module's ``make_app`` function into the
``repoze.bfg.zcml.zcml_configure`` callable, to service
compatibility with scripts that use "zope.configuration.xmlconfig"
(replace with ``repoze.bfg.zml.zcml_configure`` as necessary to get
BBB logic)

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

- Add interface docs related to how to create authentication policies
and authorization policies to the "Security" narrative chapter.

- Added a (fairly sad) "Combining Traversal and URL Dispatch" chapter
to the narrative documentation. This explains the usage of
``*traverse`` and ``*subpath`` in routes URL patters.

- A "router" chapter explaining the request/response lifecycle at a
high level was added.

- Replaced all mentions and explanations of a routes "context factory"
with equivalent explanations of a "root factory" (context factories
have been disused).

- Updated Routes bfgwiki2 tutorial to reflect the fact that context
factories are now no longer used.

Page 18 of 30

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.