Document that session cookies are now SameSite=Strict

[BGehrels]

Issue Description When upgrading from CakePHP3 to CakePHP4, the integration with our external SSO solution broke, but there was no hint in the update/upgrade documentation why.

What do we do?

• User opens our app
• We see that there is no authentication data for the user in the session yet
• We redirect user to an external SSO provider https://externalProvder/login
• After Login, the external Provider redirects back to a /afterLogin?token=foo url on our cake app
• We fetch user profile from the auth provider using the token and store it to the session
• We redirect the user to /

In the last step, the session is not sent, because Cake 4 decided to go for SameSite=Strict by default in https://github.com/cakephp/cakephp/commit/7d37bfd75eac2ae175e619bbaee7c559ef829f67#diff-0f7ea695bfce9d833eb7dbf3fc999244 This leads to an endless redirect loop between app and auth provider.

While the change might be good, there is no documentation about it at all.

Proposal:

1. Add a note to the Migration/Upgrade docs that Session Cookie flags have changed and that users should check their cookie handling during upgrade
2. Add (and link it from the migration docs) a description on how to manipulate this behaviour.

---

Side Note This does not only affect external SSO solutions but also the basic deep-linkability of apps.

The RFC draft on SameSite describes this quite well:

Consider the scenario in which a user reads their email at MegaCorp Inc's webmail provider "https://example.com/". They might expect that clicking on an emailed link to "https://projects.com/secret/ project" would show them the secret project that they're authorized to see, but if "projects.com" has marked their session cookies as "SameSite", then this cross-site navigation won't send them along with the request. "projects.com" will render a 404 error to avoid leaking secret information, and the user will be quite confused.

For this reason, i guess the decision to set Session Cookies to SameSite=Strict might bring quite a lot of confusion to Cake Developers if it's not very clearly documented - including it's side effects and configuration options.

Do you want to address this issue? If you can point me to a good place to add the information from No. 2, i'm happy to open a PR for this. Also addressing the side note would sadly exceed my current capacity.

[markstory]

Perhaps we should change the default setting to Lax to help with the side note problem.

[dereuromark]

Hah, GitHub cant get it done right either..^^

Refused to load the font '' because it violates the following Content Security Policy directive: "font-src github.githubassets.com".

If you look into the chrome debug bar here..

But on a more serious note:

A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure.

is also issued by chrome - and doesn't that mean adapting this by default for us would also make sense?

[markstory]

We can't set the Secure flag on cookies as we can't ensure that the application is behind an SSL connection.

[BGehrels]

@dereuromark From what i understand from this site the message is a bit misleading, it sounds more like:

Cookies flagged with SameSite=None will be rejected, if the are not also flagged with Secure. I don't think this will affect the Behaviour of SameSite=Lax cookies.

Therefore i also think that the idea of @markstory to make Lax the default value is a good idea.

[ADmad]

Is the scenario described is "Side Note" common enough? Don't links to protected content in email generally have tokens in URL itself for authentication?

[BGehrels]

I would say so, especially since most webapps i use have a "Keep me signed in" feature - i rarely even recognize that i'm browsing protected content.

Especially in office settings, literally all content is protected and "Sharing" content by Link is quite common: "Could you have a look at this customer order $link? In Support Ticket $Link the customer says she didn't receive the package but our logistics app $link says it was delivered".

Talking about sharing: Take the typical share button on most websites: Share a private FB Event with your friends via whatsapp, share your bosses announcements with your co-Workers via Slack. Newspaper Paywalls are another example. The content is deep-linkable, but only parts are accessible without the login cookie.

Even if the content itself would be accessible, most of the personalization features of the target website would be disabled (The +1 button, for example) because the user is not recognized to be logged in. Many websites look very different when viewed by externals, even if the content is partly accessible. (LinkedIn, FB Profiles, ...)

[ADmad]

Okay, I am fine changing the default to Lax in that case.

[BGehrels]

It's really great how fast you act on user feedback, thanks a lot!