Hi internals
I opened a PR [1] to implement Partitioned cookie support, as requested on the bugtracker [2], into the setcookie()
PHP function. This is done by adding an option to the $options array, not via an additional argument to the function. The amount of code to support this is tiny.
This cookie option is being pushed by browser vendors (primarily by Google it seems) to eliminate third-party cookies [3, 4]. One of the impacts here is that cookies marked with "SameSite=None; Secured" without "Partitioned" will stop working eventually during 2024.
Although the Partitioned cookie proposal is still a draft, Chrome will apply the change starting in January 2024 for a tiny percentage of users (as a form of A/B testing it seems). Symfony has already implemented support for this option as well [5].
The SameSite option was also added in PHP when it was still in a draft.
Let me know what you think and if you are okay / objecting to merging this PR.
Kind regards
Niels
[1] https://github.com/php/php-src/pull/12652
[2] https://github.com/php/php-src/issues/12646
[3] https://developers.google.com/privacy-sandbox/3pcd
[4] https://developer.mozilla.org/en-US/docs/Web/Privacy/Partitioned_cookies
[5] https://github.com/symfony/symfony/pull/52002
Hi internals
I opened a PR [1] to implement Partitioned cookie support, as requested on the bugtracker [2], into the
setcookie()
PHP function. This is done by adding an option to the $options array, not via an additional argument to the function. The amount of code to support this is tiny.This cookie option is being pushed by browser vendors (primarily by Google it seems) to eliminate third-party cookies [3, 4]. One of the impacts here is that cookies marked with "SameSite=None; Secured" without "Partitioned" will stop working eventually during 2024.
Although the Partitioned cookie proposal is still a draft, Chrome will apply the change starting in January 2024 for a tiny percentage of users (as a form of A/B testing it seems). Symfony has already implemented support for this option as well [5].
The SameSite option was also added in PHP when it was still in a draft.Let me know what you think and if you are okay / objecting to merging this PR.
I've two concerns (none with the PR, as I haven't checked):
- Compatibility: https://developer.mozilla.org/en-US/docs/Web/Privacy/Partitioned_cookies#browser_compatibility
- What happens if it just stays a draft, or doesn't get accepted, or with a different name?
And also, would/should the PHP function enforce that this should only be set if for example Secure is set too? And if so, with a warning or TypeError?
cheers
Derick
Hi
Hi internals
I opened a PR [1] to implement Partitioned cookie support, as requested on the bugtracker [2], into the
setcookie()
PHP function. This is done by adding an option to the $options array, not via an additional argument to the function. The amount of code to support this is tiny.This cookie option is being pushed by browser vendors (primarily by Google it seems) to eliminate third-party cookies [3, 4]. One of the impacts here is that cookies marked with "SameSite=None; Secured" without "Partitioned" will stop working eventually during 2024.
Although the Partitioned cookie proposal is still a draft, Chrome will apply the change starting in January 2024 for a tiny percentage of users (as a form of A/B testing it seems). Symfony has already implemented support for this option as well [5].
The SameSite option was also added in PHP when it was still in a draft.Let me know what you think and if you are okay / objecting to merging this PR.
I've two concerns (none with the PR, as I haven't checked):
Right, indeed it is only supported by Blink-based browsers right now.
It is on the roadmap for Safari and Firefox for 2024 according to https://developer.mozilla.org/en-US/blog/goodbye-third-party-cookies/
- What happens if it just stays a draft, or doesn't get accepted, or with a different name?
Good question, no idea.
And also, would/should the PHP function enforce that this should only be set if for example Secure is set too? And if so, with a warning or TypeError?
This constraint is enforced already in the PR.
If you try to set it without setting Secure, a ValueError is thrown.
This is consistent with how other options can also throw a ValueError if constraints are broken.
cheers
Derick
Kind regards
Niels