Skip to content

SameSite not supported by Symfony 3.4 LTS on PHP 7.4.2 #35520

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
jayesbe opened this issue Jan 30, 2020 · 10 comments
Closed

SameSite not supported by Symfony 3.4 LTS on PHP 7.4.2 #35520

jayesbe opened this issue Jan 30, 2020 · 10 comments
Labels
Bug HttpFoundation Status: Needs Review

Comments

@jayesbe
Copy link

jayesbe commented Jan 30, 2020 •
edited
Loading

Symfony version(s) affected: 3.4.36

Description
Chrome is currently throwing a warning:

A cookie associated with a cross-site resource at was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure.

How to reproduce

  session:
      # storage_id: app.dynamic.session.storage
      handler_id: ~
      name: "%session.name%"
      cookie_secure: true
      cookie_httponly: true
      cookie_lifetime: 2630000 # 1-Month
      cookie_samesite: strict

Add the cookie_samesite option. The value does not matter as adding the option results in

Unrecognized option "cookie_samesite" under "framework.session"

Possible Solution

Additional context

Symfony 3.4 LTS is still a maintained branch, SameSite is now going into affect in browsers with Chrome expected to deploy soon. I am currently trying to implement this

https://www.chromium.org/updates/same-site/incompatible-clients

which is supposed to help determine when SameSite is required. Without Symfony 3.4 LTS support, this isn't possible.

The application is being deployed to a Ubuntu 18.04 LTS server with PHP 7.4.2.
@nicolas-grekas
Copy link
Member

Since Symfony 3.4 is in maintenance mode, it means we cannot add features to it.
But I think you can already define the setting using the session.cookie_samesite php.ini setting so there is a way to send this attribute if you're using PHP 7.4.

@jayesbe
Copy link
Author

jayesbe commented Jan 30, 2020

The value needs to be dynamic though.. I don't understand how a static value in php.ini helps.

@jayesbe
Copy link
Author

jayesbe commented Jan 30, 2020

Wait.. can I just use ini_set ? Will try that.

@nicolas-grekas
Copy link
Member

You can use ini_set() at runtime so it can also be dynamic.
The alternative is upgrading to Symfony 4.4 of course.

@jayesbe
Copy link
Author

jayesbe commented Jan 30, 2020

Thanks @nicolas-grekas

@fabpot fabpot closed this as completed Jan 30, 2020
@chihiro-adachi chihiro-adachi mentioned this issue Feb 4, 2020
Closed
@jrmyio
Copy link
Contributor

jrmyio commented Feb 5, 2020 •
edited
Loading

@jayesbe @nicolas-grekas @fabpot

I hope I am wrong but I see the impact of not making any changes to Symfony 3.4 will have a tons of sites break if we cannot set the cookie's samesite setting (in the framework session and remember me) before Chrome pushes this update.

Very soon all existing cookies are no longer going to work with cross-domains if you do not specify 'None' for the cookie_samesite. All external APIs that use cookies and are running SF 3.4 will break and devs will have no quick solution to fix their auth process.

If you are using PHP 7.4, yes you can most likely use ini_set to workaround this issue.

However, ini_set('cookie_samesite') does not work in PHP Version <= 7.2.
I am not even sure PHP 7.3 supports the value 'None' as https://php.watch/articles/PHP-Samesite-cookies says it has support for 'Lax' and 'Scrict'.

This effectively means SF 3.4 on PHP 7.2 (or PHP 7.3) is no longer supported for cross domain APIs with cookies. People would have to either update PHP to 7.4 (if they even can?) or go to Symfony 4 (with a dead live site is going to be a complete disaster).

Since the impact of the change that chrome is about to roll out is so fundamentally changing our way to set cookies, I consider configuring samesite configuration in the framework an absolute requirement, not a feature, especially since SF 3.4 is still supported.

What am i missing?

Note: SF3 HTTPFoundation already supports the new cookie settings, it's just the framework that doesn't support it.

@jayesbe
Copy link
Author

jayesbe commented Feb 5, 2020

@ConneXNL it does seem like due to the samesite change that php 7.4 is now the minimum. I finished upgrading my projects over the weekend and deployed this past monday. I am not sure there is any option for < 7.4

@nicolas-grekas
Copy link
Member

Please open an issue if you want anything to happen.

@jrmyio
Copy link
Contributor

jrmyio commented Feb 5, 2020

@nicolas-grekas isn't this supposed to be the issue?

I just elaborated on the issue and tried to make clear why it's important.

@nicolas-grekas nicolas-grekas mentioned this issue Feb 5, 2020
Merged
fabpot added a commit that referenced this issue Feb 7, 2020
@fabpot
bug #35605 [HttpFoundation][FrameworkBundle] fix support for samesite…
f350f53 
… in session cookies (fabpot)

This PR was merged into the 3.4 branch.

Discussion
----------

[HttpFoundation][FrameworkBundle] fix support for samesite in session cookies

| Q             | A
| ------------- | ---
| Branch?       | 3.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       | Fix #35520
| License       | MIT
| Doc PR        | -

This PR cherry-picks #28168 on 3.4, with a rationale given by @ConneXNL in #35520 (comment):

> I hope I am wrong but I see the impact of not making any changes to Symfony 3.4 will have a tons of sites break if we cannot set the cookie's samesite setting (in the framework session and remember me) before Chrome pushes this update.
>
> Very soon all existing cookies are no longer going to work with cross-domains if you do not specify 'None' for the cookie_samesite. All external APIs that use cookies and are running SF 3.4 will break and devs will have no quick solution to fix their auth process.
>
> If you are using PHP 7.4, yes you can most likely use ini_set to workaround this issue.
>
> However, ini_set('cookie_samesite') does not work in PHP Version <= 7.2.
I am not even sure PHP 7.3 supports the value 'None' as php.watch/articles/PHP-Samesite-cookies says it has support for 'Lax' and 'Scrict'.
>
> This effectively means SF 3.4 on PHP 7.2 (or PHP 7.3) is no longer supported for cross domain APIs with cookies. People would have to either update PHP to 7.4 (if they even can?) or go to Symfony 4 (with a dead live site is going to be a complete disaster).
>
> Since the impact of the change that chrome is about to roll out is so fundamentally changing our way to set cookies, I consider configuring samesite configuration in the framework an absolute requirement, not a feature, especially since SF 3.4 is still supported.
>
> What am i missing?
>
> Note: SF3 HTTPFoundation already supports the new cookie settings, it's just the framework that doesn't support it.

Our BC policy embeds the promise that one should be able to keep the same app on a newest infrastructure (eg that's why supporting a PHP version is a bug fix). I think we can consider this for browsers here also. WDYT?

Commits
-------

f46e6cb [HttpFoundation][FrameworkBundle] fix support for samesite in session cookies
@jayesbe
Copy link
Author

jayesbe commented Feb 7, 2020

Thanks @ConneXNL for the support on this.
@nicolas-grekas @fabpot you guys are awesome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug HttpFoundation Status: Needs Review
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@fabpot @nicolas-grekas @jrmyio @xabbuh @jayesbe @carsonbot