Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 2020-01-28 19:58:41

michaelkpate
Moderator
From: Avon Park, FL
Registered: 2004-02-24
Posts: 1,292
Website

SameSite cookies

Edit by gaekwad: split from here

Here is some more information on what Google is doing.

Google is going to fix their own products but third-party developers (and the people who rely on them) are on their own.

Last edited by gaekwad (2020-01-29 09:28:57)

Offline

#2 2020-01-28 20:57:21

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,481
Website

Re: SameSite cookies

Thanks, Michael.

Is there anything we need to change in our core login cookie implementation? (besides rewriting it one day!) As far as I recall, it sets a first-party cookie – even on multi-site – so that means we’re immune at the core level, right? I presume this just means that any third-party tracking scripts might need to be updated somehow.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#3 2020-01-28 21:59:10

michaelkpate
Moderator
From: Avon Park, FL
Registered: 2004-02-24
Posts: 1,292
Website

Re: SameSite cookies

Bloke wrote #321398:

Thanks, Michael.

Is there anything we need to change in our core login cookie implementation? (besides rewriting it one day!) As far as I recall, it sets a first-party cookie – even on multi-site – so that means we’re immune at the core level, right? I presume this just means that any third-party tracking scripts might need to be updated somehow.

I think I found the definitive documentation: SameSite cookie recipes

And also:

Developers: Get Ready for New SameSite=None; Secure Cookie Settings

Tough Cookies

SameSite Cookies

The end of CSRF in WordPress?

PHP setcookie SameSite=Strict?

Unfortunately, most of the examples seem to be aimed at banks and institutions that are always going to use https connections. I am a bit confused on how this works for regular websites.

Offline

#4 2020-01-28 22:08:24

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 3,851
Website

Re: SameSite cookies

Bloke wrote #321398:

Is there anything we need to change in our core login cookie implementation? (besides rewriting it one day!) As far as I recall, it sets a first-party cookie – even on multi-site – so that means we’re immune at the core level, right?

It looks like the default is to assume a cookie is first-party, so I would tend to agree.

But I’m not sure about multi-site setups where the backend and public site have different subdomains. At present the login cookie is set for the root domain name and can be read by both admin and public subdomains, making it possible to do things like front-end “edit this page” links or “site is in maintenance mode {switch off button}” notice banners when you are logged into the back end.


TXP Builders – finely-crafted code, design and txp

Offline

#5 2020-01-28 22:19:53

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 2,015
Website

Re: SameSite cookies

Bloke wrote #321398:

Is there anything we need to change in our core login cookie implementation? (besides rewriting it one day!)

As far as I can tell, what Google is doing is minimally catching up with what Safari and Firefox have been doing in this field. If you don’t have problems with Firefox or Safari in this regard, then TXP is good to go.

OK rewriting it one day, secure cookies and what not… One day, not the most hurry-hurry thing on the list.

Offline

#6 2020-01-28 22:38:45

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,481
Website

Re: SameSite cookies

Interesting reading. So it seems we could (and probably should) have been passing SameSite= Lax in all our cookies. In a perfect world, we’d just add the attribute to the setCookie() function in textpattern.js and anywhere we use PHP’s setcookie() – currently in include/txp_auth.php and publish/comment.php.

Is that backwards-compatible? Not sure. Might require someone to log in again, but that’s hardly a deal breaker.

However, it appears that in PHP it wasn’t possible to arbitrarily pass unsupported attributes into the function signature until they added the options array feature… in PHP 7.3.0. That’s a BIG step up from the minimum PHP 5.5 we’re targeting for 4.8.0.

Conversely, we could do nothing. When the latest versions of the browsers trickle through from February, we should automatically gain this protection for our site-based cookies. The problem, as Jools says, is multi-site where the domain is potentially different. We can’t enforce SameSite=Lax here for all cookies, and can’t just leave them unset or they’ll be rejected.

Have I understood that correctly? And, if so, what can we do?

Last edited by Bloke (2020-01-28 22:47:27)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#7 2020-02-01 08:03:36

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 2,015
Website

Re: SameSite cookies

If you have energy to navigate through twitter discussions and related, it seems this cookie feature will only be gradually (to some users only and bits by bits or something) be implemented. See this and previous or follow-up tweets.

Offline

Board footer

Powered by FluxBB