summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMichael Merickel <michael@merickel.org>2017-06-26 23:41:28 -0500
committerMichael Merickel <michael@merickel.org>2017-06-26 23:41:28 -0500
commit32c61ca8eb935c3d4ffbe844c526aad1bf3366d1 (patch)
treee17eb6374e5818f28d554449b8ee1109fd8b24f7
parent14c5425d4f031476e38bc4115c2f88b7eb62b21a (diff)
downloadpyramid-32c61ca8eb935c3d4ffbe844c526aad1bf3366d1.tar.gz
pyramid-32c61ca8eb935c3d4ffbe844c526aad1bf3366d1.tar.bz2
pyramid-32c61ca8eb935c3d4ffbe844c526aad1bf3366d1.zip
explain more clearly the exception view changes
-rw-r--r--docs/whatsnew-1.9.rst1
1 files changed, 1 insertions, 0 deletions
diff --git a/docs/whatsnew-1.9.rst b/docs/whatsnew-1.9.rst
index ea3b4b350..17d6126d6 100644
--- a/docs/whatsnew-1.9.rst
+++ b/docs/whatsnew-1.9.rst
@@ -18,6 +18,7 @@ Major Feature Additions
The first library to use this feature is `pyramid_retry <https://docs.pylonsproject.org/projects/pyramid-retry/en/latest/>`_.
+ Pyramid's default :term:`execution policy` will attempt to handle and render uncaught exceptions. This is a subtle, but fundamental, change indicating that an :term:`exception view` may expect to be called outside of the default ``EXCVIEW`` tween. There are various predicates available to assist in defining valid exception views for various parts of the pipeline. For example, ``pyramid_tm`` defines the ``tm_active=True`` predicate which can be applied to exception views that require access to the default transaction. In general this means that exception views may be expected to cover more possible error conditions, including when exceptions occur from tweens that are placed **OVER** the ``EXCVIEW`` tween. If necessary, when provided a ``response`` object, you may inspect ``request.exception`` or ``request.exc_info`` to determine if the response was generated as the result of an exception.
See https://github.com/Pylons/pyramid/pull/2964
- CSRF support has been refactored out of sessions and into its own independent API in the :mod:`pyramid.csrf` module. It supports a pluggable :class:`pyramid.interfaces.ICSRFStoragePolicy` which can be used to define your own mechanism for generating and validating CSRF tokens. By default, Pyramid continues to use the :class:`pyramid.csrf.LegacySessionCSRFStoragePolicy` that uses the ``request.session.get_csrf_token`` and ``request.session.new_csrf_token`` APIs under the hood to preserve compatibility with older Pyramid applications. Two new policies are shipped as well, :class:`pyramid.csrf.SessionCSRFStoragePolicy` and :class:`pyramid.csrf.CookieCSRFStoragePolicy` which will store the CSRF tokens in the session and in a standalone cookie, respectively. The storage policy can be changed by using the new :meth:`pyramid.config.Configurator.set_csrf_storage_policy` config directive.