Bug 63865 - Cookie Attribute SameSite=None is default to unset in Chrome browser
Summary: Cookie Attribute SameSite=None is default to unset in Chrome browser
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 8
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 8.5.x-trunk
Hardware: PC Mac OS X 10.1
: P2 normal (vote)
Target Milestone: ----
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
: 63947 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-10-18 17:27 UTC by Pushyami Gundala
Modified: 2020-02-28 10:41 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pushyami Gundala 2019-10-18 17:27:33 UTC
This PR for Tomcat added support for SameSite Cookie attribute, https://github.com/apache/tomcat/pull/162/files. One thing I noticed is if I configure SameSite=None then Tomcat is setting to unset in Broswer, documentation echo that behviour.

With Chrome 77, I see a warning which is trying to say that SameSite should be either be Set to None, Lax, Strict.
Chrome Warning:
"A cookie associated with a cross-site resource at http://localhost/ 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`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032"

I have an application(Which we call it an LTI tool(https://www.imsglobal.org/activity/learning-tools-interoperability) that is embeded inside another application so that user have seamless experience and that's how it need to operate. In my Case SameSite=None is approperaite setting for application running, current tomcat 8 if set to None it is unseting in the value in browser. And it looks like future browsers what it to set to either od those options None, Lax, Strict.

Can you allow in Tomcat to set to None if user choose that option instead of defaulting to unset?
context.xml
<Context>
   <CookieProcessor sameSiteCookies="None" />
</Context>
Comment 1 Prakash Saraf 2019-10-18 18:50:35 UTC
Google Chrome will also default all cookies without "SameSite" attribute to "Samesite=LAX" effective from Chrome v80. So, its important that if the value is set to NONE, tomcat does honor that and put SameSite=NONE rather unsetting it. 
Reference for upcoming Chrome change - https://www.chromestatus.com/feature/5088147346030592
Comment 2 Mark Thomas 2019-10-24 10:33:21 UTC
Fixed in:
- master for 9.0.28 onwards
- 8.5.x for 8.5.48 onwards

Thanks to John Kelly for the PR.
https://github.com/apache/tomcat/pull/219
Comment 3 Pushyami Gundala 2019-11-13 16:15:55 UTC
Thanks for the fix. When will 8.5.48 going to be released? as Chrome 80 is scheduled to release Feb 4, 2020 https://www.chromestatus.com/features/schedule
Comment 4 Christopher Schultz 2019-11-13 17:50:29 UTC
(In reply to Pushyami Gundala from comment #3)
> Thanks for the fix. When will 8.5.48 going to be released? as Chrome 80 is
> scheduled to release Feb 4, 2020
> https://www.chromestatus.com/features/schedule

Looks like markt has just proposed a round of releases, including what will (likely) be 8.5.48. You should certainly have plenty of time before Chrome 80 is released.

If you have further questions, please post to the users' mailing list as Bugzilla is not a support forum but a bug-tracker.
Comment 5 Remy Maucherat 2019-11-13 17:57:23 UTC
There's a release batch almost every month, so please stop asking "when" ...
Comment 6 Mark Thomas 2019-11-21 12:30:01 UTC
*** Bug 63947 has been marked as a duplicate of this bug. ***
Comment 7 Bob 2020-02-28 10:38:22 UTC
It seems that -unlike whatthe release notes say- this patch is NOT in 8.5.50 , at least not in the sources tagged with it (also no .51 !)

Check https://github.com/apache/tomcat/blob/8.5.50/java/org/apache/tomcat/util/http/CookieProcessorBase.java
Comment 8 Mark Thomas 2020-02-28 10:41:43 UTC
Yes, it clearly is.