WebOb 1.8.6 has been released

[Bert JW Regeer]

Good evening,

A new version of WebOb has been released, version 1.8.6

This adds a new option for the SameSite cookie attribute to match the draft RFC that Google has implemented in their browser Chrome.

Install it from pypi:

pip install webob==1.8.6

For more information see:

https://pypi.org/project/WebOb/1.8.6/

Bert JW Regeer

[Mike Orr]

On Tue, Jan 21, 2020 at 9:26 PM Bert JW Regeer <xist...@0x58.com>
wrote [on pylons-devel]:

> A new version of WebOb has been released, version 1.8.6
>
> This adds a new option for the SameSite cookie attribute to match the draft RFC that Google has implemented in their browser Chrome.
>

> https://pypi.org/project/WebOb/1.8.6/

I'm trying to get my head around this 'samesite=none' and
'samesite=lax' issue. I have a Pylons application with Beaker sessions
that share the cookie between two sites: the main website
(mysite.parent.com) and a mobile-optimized view (m.mysite.parent.com).
Users can switch to the other site via "Mobile Site" and "Main Site"
links, and their session state should follow them. Currently this
works with the configuration:

beaker.session.cookie_domain = .mysite.parent.com
beaker.session.httponly = true
beaker.session.save_accessed_time = true
beaker.session.secret = ...
beaker.session.secure = true
beaker.session.timeout = 172800
beaker.session.type = ext:redis
beaker.session-url = redis://redis/1

The "cookie_domain" setting allows the cookie to be shared within the
domain familly. My question is, will Chrome's changes in February
break the session sharing? Should I set 'beaker.session.samesite =
none' or 'beaker.session.samesite = lax'? Do I need to upgrade from
Beaker 1.10.0 to 1.11.0? The site is working now on Chrome
78.0.3945.117.

From what I've gathered in the WebOb description and issues, linked
references to Chrome blogs and OWASP, and Beaker's changelong and
commits, the 'samesite' attribute was added to Beaker before 1,10.0
and defaults to 'lax', and Beaker 1.10.1 filled some gaps in the
default But now the Chrome reference seems to say 'lax' won't be good
enough anymore, you need to set 'none', but 'none' is not implemented
yet in many browsers. And a WebOb issue comment says Google
implemented an expired draft spec and is shoving it onto users to
railroad the web industry into its vision, and the spec itself is
rapidly changing so I may have to update my site mulitple times as it
evolves.

There are also explanations of cross-site vs same-site activity, and
that cross-domain GET hyperlinks are usually safe and give the example
of a cross-site request (an advertising link or an image on another
site) vs same-site request (a link to the same domain as in the
address bar). My use case seems to fall in between, sharing within a
family of domains as specified by the 'cookie_domain' attribute. So is
it "same-site" or "cross-site", and do I need to change my
configuraton to keep it working in future browsers?

Beaker changelog (see 1.11.0, 1.10.1, 1.10.0)
https://github.com/bbangert/beaker/blob/master/CHANGELOG

Beaker session doc (see section "Cookie security")
https://github.com/bbangert/beaker/blob/master/beaker/docs/sessions.rst

Beaker commit in 1.11.0
https://github.com/bbangert/beaker/commit/111ad13fc57350eddd8972dae0c82a92f6327f29

Beaker commit in 1.10.1
https://github.com/bbangert/beaker/commit/b60a46db0baf59caa817f12634dea183be2e38a4

OWASP samesite recommendation
https://www.owasp.org/index.php/SameSite

WebOb changelog
https://pypi.org/project/WebOb/

WebLog samesite issue
https://github.com/Pylons/webob/issues/406

WebOb pull request
https://github.com/Pylons/webob/pull/407

WebOb samesite issue 2
https://github.com/Pylons/webob/pull/407

IETF draft spec (expired)
https://tools.ietf.org/html/draft-west-cookie-incrementalism-00

Chromium: explanation
https://blog.chromium.org/2019/10/developers-get-ready-for-new.html

Chromium: list of incompatible clients (i.e., browsers)
https://www.chromium.org/updates/same-site/incompatible-clients

Mozilla: explanation
https://blog.mozilla.org/security/2018/04/24/same-site-cookies-in-firefox-60/

P.S. The site is still on Python 2.7. Is there any hope of Pylons
becoming Python 3 compatible? We don't have the resources to migrate
it to Pyramid; the next migration will probably be Javascript. (We
already have a Javascript mobile app; we just need to port it to the
web and work around it needing a SQLite database.)

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

[Jonathan Vanasco]

1. Bert, thank you!

2. Mike, this stuff is generally a mess:

There are now 4 valid options for a cookie:

Python Value | Cookie Value (all strings)
None         |
"None"       | None    < this is the new "experimental" one that google has forced
"Strict"     | Strict
"Lax"        | Lax

You are supposed to still have the behavior you desire as long as the samesite is "lax" and the cookie has a "domain" attribute.  That's the public hope, at least.  There are some releases of specific browsers that are broken.  It is a mess.

However, you need to understand these changes mean that the experience is definitely going to break for some amount of users, as some browsers can't handle the samesite values.  Browser sniffing can help get around that.

My approach would be deciding which users to prioritize and if you need to work on browser sniffing.  I would look at your traffic logs to decide that.  

If you have a lot of chrome traffic, you need to do browser testing WITH SPECIFIC CHROME FLAGS SET.  Not all installations of chrome have these set.

IIRC the flags you want to enable are:

chrome://flags/#same-site-by-default-cookies
chrome://flags/#cookies-without-same-site-must-be-secure

[Bert JW Regeer]

SameSite as a whole is still experimental. To date there is no accepted RFC that updates the cookie RFC. All we have are RFC drafts filed by Google, that are all expired.

The only real "standard" is what the majority of browsers implement, and even that is not something I can point to because each of the browsers may treat cookies differently as there is not standard.

--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/63b211be-0190-4458-a376-8efc2817644a%40googlegroups.com.

[Bert JW Regeer]

Not unless you are either:

- Willing to do the work yourself

or

- Pay someone to do the work and provide it back upstream

Pylons has no further development.