Pyramid 1.7a1 released

[Michael Merickel]

Pyramid 1.7a1 has been released. This is the first alpha in the 1.7 series.

There is one major change I want people to be aware of first:

- The AuthTktAuthenticationPolicy has switched its default hash algorithm to sha512 from md5. The default of md5 had been deprecated since Pyramid 1.4. If you are not specifying an explicit hashalg when creating your policy and you upgrade then all of your users will be logged out. You may specify hashalg='md5' to keep the old behavior and migrate when you see fit.

There have been several excellent documentation enhancements:

- All documentation has been updated to recommend pip and Python 3.4+.

- The alchemy scaffold is completely reworked thanks to several contributors going all the way back to the Pycon 2015 sprints. The scaffold no longer uses a global DBSession object but rather a more deterministic request.dbsession property.

- The Wiki2 SQLAlchemy + URL Dispatch tutorial has been completely overhauled to reflect the changes in the alchemy scaffold as well as a new chapter to separate authentication examples from authorization examples (including a new object-level example).

Finally, there are some great new features:

- Dropped Python 2.6 and Python 3.2 support.

- View derivers have been added to allow framework authors full control over Pyramid's view pipeline. This will be of use to people who have decorators they are using on many views. For example... CSRF.

- CSRF checking has been integrated into Pyramid in a much more significant way than it had been previously. You can now specify "require_csrf=True" on any view to have unsafe methods like POST/PUT/PATCH/DELETE checked for CSRF tokens.

- You may also set "pyramid.require_default_csrf = yes" to globally enable CSRF on your entire application and turn it off on a per-view basis using "require_csrf=False" on individual views.

- A new event was added immediately after URL dispatch has matched (or not) a route. The event is "BeforeTraversal".

- And much more in the changelog!

A "What's New In Pyramid 1.7" document exists at

http://docs.pylonsproject.org/projects/pyramid/en/1.7-branch/whatsnew-1.7.html .

You will be able to see the 1.7 release documentation (across all

alphas and betas, as well as when it eventually gets to final release)

at http://docs.pylonsproject.org/projects/pyramid/1.7-branch/ .

You can install it via PyPI (now with a pip example!!):

  pip install pyramid==1.7a1

Enjoy, and please report any issues you find to the issue tracker at

https://github.com/Pylons/pyramid/issues

Thanks!

- Michael

[Christoph Zwerschke]

Am 16.04.2016 um 23:27 schrieb Michael Merickel:
> - You may also set "pyramid.require_default_csrf = yes" to globally
> enable CSRF on your entire application and turn it off on a per-view
> basis using "require_csrf=False" on individual views.

This requires to enable a session factory, though. I tried to avoid this
where a server side session was not needed, e.g. in a single page app
where the state apart from authentication is kept on the client.

Any recommendation for a simple session factory just to support CSRF
protection? I'm asking because the default session is unencrypted and
not recommended when security is important, and pyramid_redis/beaker
don't look really actively maintained and add dependencies which need to
be taken care of. What do people here use for server side sessions?

-- Christoph

[Michael Merickel]

On Sun, Apr 17, 2016 at 5:45 AM, Christoph Zwerschke <ci...@online.de> wrote:

Any recommendation for a simple session factory just to support CSRF protection? I'm asking because the default session is unencrypted and not recommended when security is important, and pyramid_redis/beaker don't look really actively maintained and add dependencies which need to be taken care of. What do people here use for server side sessions?

The unencrypted sessions are perfectly fine for storing workflow-based data such as flash messages, csrf tokens and many other types of info. The only things you must avoid when using a session cookies are large data and secrets (passwords and the like).

pyramid_nacl_session exists if you feel you need an encrypted cookie. For backend cookies the are the ones you mentioned, I'm not aware of others but I'm sure they exist.

[Jonathan Vanasco]

If you serve content via https, you may not need/want encrypted cookies.  You can get free SSL certs trusted in most browsers from LetsEncrypt.org

If your desire to encrypt the data is to keep the consumer from accessing the payload, it's not that hard to stuff an encrypted payload in the session or another cookie.

I use a heavily forked version of pyramid_redis_sessions.  the actual distribution hits redis way too much and caused bottlenecks for us.  it uses multiple calls when only one is needed, and sets a new expire on every attribute access (only one is needed per request, or redis could be configured as a LRU cache and no expires are needed).

[Christoph Zwerschke]

Am 18.04.2016 um 06:04 schrieb Jonathan Vanasco:
> I use a heavily forked version of pyramid_redis_sessions. the actual
> distribution hits redis way too much and caused bottlenecks for us. it
> uses multiple calls when only one is needed, and sets a new expire on
> every attribute access (only one is needed per request, or redis could
> be configured as a LRU cache and no expires are needed).

Right, it would make sense to leave the expiration handling to Redis.
Another possible improvement of pyramdid_redis_session would be to also
support Vedis (vedis-python) which works like Redis but doesn't need an
additional server component. For most apps this could suffice even in
production and you could still easily upgrade to Redis using a config
setting if you're hitting a limit.