-
Notifications
You must be signed in to change notification settings - Fork 82
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.
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
SameSite Cookie Support #175
Comments
@farmdawgnation Commented |
@dcominottim Commented |
@edburns Commented Ed |
@farmdawgnation Commented
|
@edburns Commented |
@asgs Commented |
|
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! |
It is on the TODO list (i.e. is an open issue here) for the next release of the Servlet spec. |
Are PRs welcome for this RFE? |
Yes, but...
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. |
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. |
Google Chrome is going to start enforcing the
https://blog.chromium.org/2019/10/developers-get-ready-for-new.html |
Signed-off-by: Peter Major <peter.major@forgerock.com>
Signed-off-by: Peter Major <peter.major@forgerock.com>
Signed-off-by: Peter Major <peter.major@forgerock.com>
Some browsers (for example Google Chrome) announced that they would require the I would therefore reconsider making it a part of |
See jakartaee#175 Signed-off-by: Adam Klinkosz <spyro@o2.pl>
Signed-off-by: Peter Major <peter.major@forgerock.com>
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? |
@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 ...
But all is not lost, most containers, even ones on |
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. |
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. |
@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. |
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. |
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. |
@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. |
Will this be in Servlet 5.1? The associated pull request #271 hasn't been updated in a while. |
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. |
Big +1 for Once a new cookie attribute ends up in RFC, then it deserves its own API method and Do note that |
I've prepped a PR to add Cookie#setAttribute: #399 |
* Add Cookie#setAttribute #175 #271 * Skip null value from check for reserved token * Alternative approach to cookie attribute handling github.com//pull/399#discussion_r624276777 * Make sure path is referenced via constant * In hindsight, token check doesn't need to be performed on value * Match casing with spec; mapping is case insensitive anyway * Optimized Cookie to lazily create attribute map * Added junit test * Updates from review * Fixed quote * surefire plugin * Updates from review * Updates from review Co-authored-by: Bauke Scholtz <balusc@gmail.com>
Fixed with #401 |
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.The text was updated successfully, but these errors were encountered: