Pyramid 1.9b1 released

[Michael Merickel]

Hey folks, I'm happy to announce 1.9b1. If there are no issues with this release, expect the final in a week or so.

This release has several excellent contributions from the Pycon 2017 sprints. Thanks everyone! In a change of pace, I've decided to avoid providing a summary of changes here and instead just link directly to the changelog.

Please view the list of changes from 1.9a2 at http://docs.pylonsproject.org/projects/pyramid/en/1.9-branch/changes.html#b1-2017-06-19 .

A comprehensive "What's New In Pyramid 1.9" document exists at

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

You will be able to see the 1.9 release documentation

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

You can install it via PyPI:

  pip install pyramid==1.9b1

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

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

Thanks!

- Pyramid core developers

[Jonathan Vanasco]

has anyone written a migration guide for the CSRF stuff yet?

[Michael Merickel]

On Tue, Jun 20, 2017 at 10:40 AM, Jonathan Vanasco <jona...@findmeon.com> wrote:

has anyone written a migration guide for the CSRF stuff yet?

I guess I felt like the notes at [1] were fairly informative. What did you have in mind?

In reality the biggest change in this release is how Pyramid deals with exception views and I need to write at least a little bit more about that in the docs/whatsnew.

[1] http://docs.pylonsproject.org/projects/pyramid/en/1.9-branch/whatsnew-1.9.html#major-feature-additions.

[Mike Orr]

On Mon, Jun 19, 2017 at 8:39 PM, Michael Merickel <mmer...@gmail.com> wrote:
> Hey folks, I'm happy to announce 1.9b1. If there are no issues with this
> release, expect the final in a week or so.
>
> This release has several excellent contributions from the Pycon 2017
> sprints. Thanks everyone! In a change of pace, I've decided to avoid
> providing a summary of changes here and instead just link directly to the
> changelog.

That's fine, the changes don't have to be here, they just have to be somewhere.

> A comprehensive "What's New In Pyramid 1.9" document exists at
> http://docs.pylonsproject.org/projects/pyramid/en/1.9-branch/whatsnew-1.9.html

These "What's New"'s are incredibly useful.

> has anyone written a migration guide for the CSRF stuff yet?

One question is, how do you configure one handling class or another?
How is the default legacy handler set, and will it always be so or
should we do something to future-proof our application?

[Michael Merickel]

On Tue, Jun 20, 2017 at 11:38 AM, Mike Orr <slugg...@gmail.com> wrote:

> has anyone written a migration guide for the CSRF stuff yet?

One question is, how do you configure one handling class or another?
How is the default legacy handler set, and will it always be so or
should we do something to future-proof our application?

Just start using the new pyramid.csrf APIs instead of request.session.get_csrf_token() etc and things will work with any policy instead of just the legacy one. The get_csrf_token() function is injected into templates as well for convenience in writing forms.

[Jonathan Vanasco]

On Tuesday, June 20, 2017 at 12:23:44 PM UTC-4, Michael Merickel wrote:

 I guess I felt like the notes at [1] were fairly informative. What did you have in mind?

I was hoping for someone to handle any gotchas, stuff like "you did that, now do this", and potential ways the CSRF stuff may have been previously integrated.

I'm just paranoid about security related concepts like this and expect unit/integrated tests to miss a bunch of edge ccases, so want to make sure I migrate everything and regex the source code & site-packages for anything that touches it.

I'll start to draft some notes to share for others when I get around to migrating.

The exception view change is a large fundamental change, but I feel like that is easier to deal with -- but migration errors will just lead to a route triggering a 5xx view -- not potential security issues.

[Mike Orr]

On Tue, Jun 20, 2017 at 11:38 AM, Jonathan Vanasco
<jona...@findmeon.com> wrote:
> I'm just paranoid about security related concepts like this and expect
> unit/integrated tests to miss a bunch of edge ccases, so want to make sure I
> migrate everything and regex the source code & site-packages for anything
> that touches it.

Do you think CSRF tokens are that important? In some cases you really
don't want people submitting anything without going through the form,
but in other cases it doesn't really matter, and in other cases you
*want* them to be able to submit inter-application search requests
from their own programs. I've talked with some people about this and
what I've heard is that if you have HTTPS then that takes care of some
of the things CSRF tokens were invented for. We just did an evaluation
of one application and decided that the only form that needs CSRF
tokens is the login form.

--
Mike Orr <slugg...@gmail.com>

[Jonathan Vanasco]

On Wednesday, June 21, 2017 at 12:28:33 AM UTC-4, Mike Orr wrote:

Do you think CSRF tokens are that important? In some cases you really
don't want people submitting anything without going through the form,
but in other cases it doesn't really matter, and in other cases you
*want* them to be able to submit inter-application search requests
from their own programs. I've talked with some people about this and
what I've heard is that if you have HTTPS then that takes care of some
of the things CSRF tokens were invented for. We just did an evaluation
of one application and decided that the only form that needs CSRF
tokens is the login form.

HTTPS doesn't prevent CSRF -- you can still exploit HTTPS endpoints with CSRF attacks.  HTTPS secures communication between the browser and the server, but a CSRF attack happens within the browser.

I typically spec out applications like this:

* Everything in `/account` is via HTTPS with a secondary HTTPS-only session (that has a different timeout the default session), and login-status requires a recent user/pass entry (no autologin). All forms implement CSRF.

* Everything not in `/account` can be https or not (though https is preferred).  CSRF is usually irrelevant for these actions.

This does a lot to safeguard against sensitive/personally identifiable data being accessed or manipulated by malicious 3rd parties.

 

[Mike Orr]

On Wed, Jun 21, 2017 at 9:28 AM, Jonathan Vanasco <jona...@findmeon.com> wrote:
> I typically spec out applications like this:
>
> * Everything in `/account` is via HTTPS with a secondary HTTPS-only session
> (that has a different timeout the default session), and login-status
> requires a recent user/pass entry (no autologin). All forms implement CSRF.

How do you get a secondary session? Can you do that with Pyramid's
session infrastructure?

What do you mean by "a recent user/pass entry"?

[Jonathan Vanasco]

On Wednesday, June 21, 2017 at 10:47:26 PM UTC-4, Mike Orr wrote:

How do you get a secondary session?  Can you do that with Pyramid's  session infrastructure? 

 

Originally I extended Pyramid to have a ISessionHttpsFactory class that binds to `request.session_https` and basically copies what ISessionHttpFactory does.  it's pretty simple, but i dropped it on pypi/github for others https://github.com/jvanasco/pyramid_https_session_core

I've been moving away from that to simply use request properties with a finished callback.  

What do you mean by "a recent user/pass entry"?

One app supports a handful of auth mechanisms:

- Form Login (user+pass entered into the site via https)
- 3rd party login (Facebook/Twitter/etc)
- Auto-Login (via secure cookie)
- I think there may be another method or two...

When someone logs in, we store in the session:

* the timestamp
* the login type + timestamp

Most sections of our /account require a username+password entered within 15minutes.  You'll see this common to a lot of finance, medical and enterprise software apps.

If someone is "logged in" but hasn't provided a username+password within the last 15minutes, they can't view data in /account or modify settings.  they are redirected to enter the credentials again.

they still have a "logged in" status on the site, and are considered "logged in", they session is just considered "untrusted" for viewing or editing certain data.