SameSite Cookie Support

[glassfishrobot]

Good morning,

I'm not sure if this is the best avenue to communicate this feedback, but while working on lift/framework#1828 we discovered that the current version of the Servlet API doesn't support the same-site cookie attribute.

I would like to propose an addition to javax.servlet.http.Cookie to add support for this attribute in Servlet API 4.0, which would give us a path forward in the Lift Framework for supporting it.

[glassfishrobot]

@farmdawgnation Commented
@edburns @shingwaichan You two seem to be active on this project, but this issue hasn't gotten any attention since I opened it back in May. Am I in the wrong place for this discussion? Would you be open to a contribution to the API to support this?

[glassfishrobot]

@dcominottim Commented
I am also interested in this. It definitely seems like an important addition.

[glassfishrobot]

@edburns Commented
Hello @farmdawgnation and @dcominottim Same site cookie support is indeed important, but by the time this issue was filed, we were already in the rampdown for Servlet 4.0. Perhaps we can get to it in a future version. Thanks.

Ed

[glassfishrobot]

@farmdawgnation Commented
Got it. What's the best way to get involved in future iterations?
On Wed, Aug 16, 2017 at 7:01 PM Edward Burns notifications@github.com
wrote:

Hello @farmdawgnation https://github.com/farmdawgnation and @dcominottim
https://github.com/dcominottim Same site cookie support is indeed
important, but by the time this issue was filed, we were already in the
rampdown for Servlet 4.0. Perhaps we can get to it in a future version.
Thanks.

Ed

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/javaee/servlet-spec/issues/175#issuecomment-322922905,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAl2nQ3Cx-H-SmrTO2ZN6DB1hEnGr84Oks5sY3S8gaJpZM4NOM7F
.

[glassfishrobot]

@edburns Commented
I'm told there will be an announcement of some kind soon. It's a good idea to keep an eye on < https://blogs.oracle.com/developers/java-3 >.

[glassfishrobot]

@asgs Commented
Just FYI - The HTTP WG has recently proposed an update to RFC 6265 to include SameSite attribute.

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/servlet-spec/issues/175
• Original Issue Raised By:@farmdawgnation
• Original Issue Assigned To: Unassigned

[bes]

Hi!

This issue is quite important for web security, but many of the links in this thread are dead and there seems to be little or no movement for a while on this issue.

I have tried searching the internet for more information about the Servlet API and work on SameSite but this is the best thread I could find.

Could anyone with knowledge jump in and clarify what release this could potentially end up in, or at least what the status is?

Thanks!

[markt-asf]

It is on the TODO list (i.e. is an open issue here) for the next release of the Servlet spec.

[aldaris]

Are PRs welcome for this RFE?

[markt-asf]

Yes, but...

1. We don't yet have the text for the spec document and I'd expect that would need updates as well as the code.
2. While the Servlet spec document references RFC 6265, the Javadoc references the Netscape Cookie spec and RFC 2109. I think the Javadoc needs some updates to better align it with RFC 6265 (and that might trigger some debates about backwards compatibility)
3. I don't know if anything in 2) would impact on the changes required for this issue.

Overall having a PR is better than not having one, I'm just trying to set the expectation that it might not get merged quickly.

[aldaris]

Not sure if support for SameSite cookies have to be covered at the same time as when the JavaDocs need to get restructured. I have filed #271 just in case.

[joakime]

Google Chrome is going to start enforcing the SameSite Cookie attribute.

Chrome plans to implement the new model with Chrome 80 in February 2020. Mozilla and Microsoft have also indicated intent to implement the new model in Firefox and Edge, on their own timelines.

https://blog.chromium.org/2019/10/developers-get-ready-for-new.html

[cleankod]

Some browsers (for example Google Chrome) announced that they would require the SameSite directive to be present as a Cookie attribute. Otherwise the Cookie will not be sent by the browser. This was supposed to be required starting from April 2020, but due to COVID-19 crisis it was delayed (source). This means we have a little more time to get everything in place.

I would therefore reconsider making it a part of 5.x release and add it sooner, to the 4.x since 5.x may require other changes in dependent servers/frameworks thus making it that harder to introduce the SameSite support.

[lack3r]

Hi all. Google Chrome has released released a new version that blocks all cross-site cookies that do not have the SameSite attribute set. For more info have a look here https://www.chromium.org/updates/same-site. This applies to all chrome users. Therefore, I was wondering whether servlet-api will support this?

[joakime]

@lack3r the discussion on the open PR at #271 seems to be that this change will be push out to Servlet 5.1 and not be part of Jakarta EE 9.

That means ...

• The jakarta.servlet namespace is in use. (not the javax.servlet namespace of Servlet API 4.0 and older, which will never have another API update)
• It will likely be part of the Jakarta EE 10 release process. (the first release of Jakarta EE that allows for API changes)
• It will likely requires Java 11 or newer JVM.

But all is not lost, most containers, even ones on javax.servlet 3.x series, have container specific configurations to control the SameSite cookies now.

[fabianfrz]

Since this may make Jakarta EE entirely unusable if your links go cross domain, may I ask that there could be a Servlet API 4.1 at least which sill contain that and maybe some minor changes which are breaking? When those methods are not existing, the app will simply not use it and the current behaviour may be in place. The problem is that maybe you loose the JSESSIONID cookie so a back url in a request to another application will not work.

[stuartwdouglas]

For legal reasons we are not allowed to do a Servlet 4.1 API, Oracle did not grant us permission to modify the javax namespace, so those API's are effectively frozen.

[fabianfrz]

@stuartwdouglas thanks for the information. Sounds stupid but that is nothing we can change. In that case we need to wait for Jakarta EE servlet API which supports that feature.

[gregw]

Is there something we can do to say least make a defacto standard for setting it using the existing API? Eg a context attribute to configure the session cookie setting and perhaps a cookie comment to control it for arbitrary set cookies?

I think most containers now support the mechanism, we just need to agree how to activate it within the 4.0 API in a portable way.

[stuartwdouglas]

This seems reasonable. If we use jakarta. names for the attributes we could actually standardise this for 5.1, and then containers targeting the older versions could just implement it as well.

[fabianfrz]

@stuartwdouglas I think it would be better to implement it as an context attribute in v4 and mark it immediately as deprecated in the docs and 5.x only supports the new version (maybe still handle the old flag until the grace period is over).

It also does not work since the Cookie class does not support the flag. So since it must be configurable by cookie, The issue is, that this is some kind of a Map because a Cookie is identified by the combination {hostname, path, name}. The hostname is given by the container and the HTTP headers but the path and the name depend on the application. This means that you need to provide structured data in the context attribute.

[erik-brangs]

Will this be in Servlet 5.1? The associated pull request #271 hasn't been updated in a while.

[markt-asf]

I was thinking of something along the lines of Cookie.setAttribute(String name,String value) to provide a generic solution that handles these, and any future attributes. We'd need to think about things like how to remove attributes, how to set attributes that don't have a value, what happens if this is used for an attribute where a method already exists etc. but I think those issues are all relatively simple to solve and it would provide a (hopefully) future proof solution. Similar functionality could be added to

I am very uneasy about adding a hack based on the existing API. I'd rather rely on the existing container specific mechanisms for current and previous spec versions.

[BalusC]

Big +1 for Cookie#setAttribute as fallback for future attributes. The sooner this gets into API the better.

Once a new cookie attribute ends up in RFC, then it deserves its own API method and <cookie-config> entry such as as we already have for setSecure/<secure> and setHttpOnly/<http-only>.

Do note that SameSite is currently still in draft in RFC, so it's not more than reasonable that it's still not final in Servlet API.

[BalusC]

I've prepped a PR to add Cookie#setAttribute: #399

[markt-asf]

Fixed with #401