Affects: \spring-web-6.0.12.jar
Chrome is going to deprecate third party cookies in near future. There are some suggested ways to mitigate cross site issues depends on cookies
Cookies having independent partitioned state(CHIPS) is one of the proposals(https://developer.chrome.com/docs/privacy-sandbox/chips/).
To try it out in cookie parameters ResponseCookie not yet supported the partitioned parameter(spring-web/src/main/java/org/springframework/http/ResponseCookie.java)
For testing purposes tried extending httpcookie and created custom cookie class but to add that cookie in exchange response, they are expecting only of type ResponseCookie spring-web/src/main/java/org/springframework/http/server/reactive/ServerHttpResponse.java - getCookies() and addCookie()
We have many integration applications depends on cross site cookies, we want to try it out how it impacts our applications. Expecting this support from Spring as early as possible
Comment From: svankamamidi
We also have same issue
Comment From: rstoyanchev
Even if you could pass a custom cookie class, it would still need to be adapted and passed to the underlying server, which would also need to support this. Have you worked out yet how ResponseCookie would need to change?
Comment From: aramired
In ResponseCookie need a boolean attribute called partitioned similar to secure
private final boolean partitioned;
/* * Add the "Partitioned" attribute to the cookie. / ResponseCookieBuilder partitioned(boolean partitioned);
Comment From: bclozel
Note: this is currently not supported by all major browsers and I haven't seen any proposal for this in Java Servlet containers.
Comment From: bclozel
I'm going to close this issue for now since there is no official support from supported servers at this point. Adding a field to our ResponseCookie
is not enough, we would need actual API offered by Servlet containers to support this. Also, broader support in the industry would be also a prerequesite in my opinion.
We can reopen this issue once those conditions are met.
Comment From: svankamamidi
@bclozel This would be show stopper issue for us and for many once 3rd party cookies are not supported, kindly re-open it or suggest alternatives
Comment From: bclozel
@svankamamidi do you have a timeline for this, when is chips is going to be widely supported and when 3rd party cookies are won't be supported anymore?
This issue is about supporting chips in WebFlux which means we would need to adapt it to the supported servers. Which server are you deploying your WebFlux application to? Is it supporting chips already in their cookie implementation? If not, can you create an issue there to request an enhancement?
If you are using Spring MVC, I believe this is already possible through the Cookie#setAttribute
Servlet API.
Comment From: svankamamidi
@bclozel Chrome is going to start disabling from first quarter of 2024 and is clearly mentioned here.
We are deploying to Netty. Should we create a jira in Netty project also? We are using Spring Gateway also.
Comment From: vseetha2007
@bclozel , Do we have any solution for this? We are also impacted by this change.
Comment From: bclozel
Reopening to consider our options.
Comment From: bclozel
Quick update. We could support this feature with some servers, adapting the ResponseCookie
partitioned attribute into the native HTTP response. I've got a local change for that. But support is incomplete:
- Tomcat and Jetty work with ServletServerHttpResponse.
- Reactor Netty works with ReactorServerHttpResponse.
- Undertow would not be supported because we can't set the cookie value manually in UndertowServerHttpResponse.
Still, the current situation is not great because this feature would be incomplete and would lack official support. If you're interested in official support, please consider creating an issue on the relevant projects explaining the use case and why this is important:
- if you a are using a Servlet container like Tomcat or Jetty, see https://github.com/jakartaee/servlet/issues - note: I don't think we can rely on https://github.com/jakartaee/servlet/pull/401 as this attribute has no value and the
setAttribute("Partitioned", null)
would remove the "Partitioned" attribute from the cookie, not add the "Partitioned" attribute with no value - for Netty, see https://github.com/netty/netty/issues/
- for Undertow, see https://issues.redhat.com/projects/UNDERTOW/issues
Once you've created an issue, please report back here with a link so we can subscribe to it. Such issues (and votes) have more weight if they're coming from the community with real world use cases.
I'll discuss the matter further with the web team to consider this issue.
Comment From: aramired
@bclozel Created the below issue in Netty project https://github.com/netty/netty/issues/13740
Thank you
Comment From: bclozel
Closing for now as it's blocked by missing server support. We'll reopen once servers start supporting this.
Please create enhancement requests in the issue tracker of the server you're using to improve the adoption.
Comment From: svankamamidi
@bclozel This may need only API change from your side so that in our code wherever we are creating ResponseCookie and returning such as by setting on ServerWebExchange object using exchange.getResponse().addCookie(cookie); or on set() method we could include Partitioned attribute in the cookie. So wondering how this is dependent on http server. Can't it handled by changes in the ResponseCookie and ServerWebExchange.class
Comment From: bclozel
@svankamamidi our goal here as a Framework is to support many web servers with a single API. Right now we first need server support before we can consider surfacing an API. Working around a temporary issue is fine but completely ignoring a lack of support is not. At this stage, setting yourself the cookie header value is the best approach.
Comment From: bclozel
I have created https://github.com/jakartaee/servlet/issues/571 for Servlet support.
Comment From: derkoe
Tomcat now supports that https://bz.apache.org/bugzilla/show_bug.cgi?id=68348
pom.xml
<tomcat.version>10.1.18</tomcat.version>
So, this should do the trick for Tomcat after the upgrade:
@Bean
public TomcatContextCustomizer tomcatContextCustomizer()
{
Rfc6265CookieProcessor cookieProcessor = new Rfc6265CookieProcessor();
cookieProcessor.setSameSiteCookies("None");
cookieProcessor.setPartitioned(true);
return context -> context.setCookieProcessor(cookieProcessor);
}
Comment From: petsomers
@derkoe Your suggestion didn't work until I added "context.setUsePartitioned(true);" as well
return context -> {
context.setUsePartitioned(true);
context.setCookieProcessor(cookieProcessor);
};
Comment From: derkoe
@petsomers actually setting setUsePartitioned
is enough for the JSESSIONID - if you set any other cookies (like XSRF) you'll need both.
Only session cookie:
@Bean
public TomcatContextCustomizer tomcatContextCustomizer() {
return context -> context.setUsePartitioned(true);
}
Session cookie + all others:
@Bean
public TomcatContextCustomizer tomcatContextCustomizer() {
Rfc6265CookieProcessor cookieProcessor = new Rfc6265CookieProcessor();
cookieProcessor.setPartitioned(true);
return context -> {
context.setUsePartitioned(true);
context.setCookieProcessor(cookieProcessor);
};
}
Comment From: aramired
Hi,
Tomcat has context customizer to set partitioned attribute for all cookies, need the same support for Netty.
Could you please reopen this issue to support it for the same(Partitioned parameter in DefaultCookie is available for Netty now - https://github.com/spring-projects/spring-framework/issues/31454)
Thanks, Arpitha
Comment From: violetagg
@aramired Netty does not support anything that can set cookie configuration on a global level, so imo Spring Framework should provide a way for setting Partitioned
parameter in DefaultCookie
.
Comment From: bclozel
@violetagg I'm not sure I understand - this is not about a global flag, but a per-cookie setting. Netty implemented support in netty/netty#13740 - maybe we should follow up when a version is released?
Comment From: violetagg
@bclozel I was thinking that @aramired wants to apply the same workaround as for Tomcat i.e. setting on a global level i.e. Context in terms of Tomcat. So such thing is not possible with Netty.
Comment From: aramired
@bclozel @violetagg
Netty provided the Partitioned parameter in DefaultCookie class - 4.1.107.Final-SNAPSHOT and we tested with that in local but cannot make use of it as ResponseCookie not updated. I have asked like any context customizer available for Netty to apply for all cookies but it is not available any how.
This should be supported from Spring web, could you please reopen this issue and provide fix ASAP. We have been waiting for the fix to push it as part of release promotion.
Please do needful.
Thanks, Arpitha
Comment From: bclozel
@aramired see https://github.com/spring-projects/spring-framework/issues/31454#issuecomment-1878398157 that still applies.
We will add support in that class once the support has settled in servers. Netty only has snapshots for now and the situation in Servlet is still being discussed in jakartaee/servlet#571
Comment From: svankamamidi
@bclozel seems Netty 4.1.107.Final would be available in this week or by early of next week. Can you please add this support at the earliest, otherwise we will have challenges.
Comment From: violetagg
Actually Netty 4.1.107.Final is released https://github.com/netty/netty/releases/tag/netty-4.1.107.Final
Comment From: bclozel
We can't raise the minimum Netty or Reactor Netty versions in maintenance releases. The earliest support would be in Spring Framework 6.2.0, which is not scheduled at the moment. Again, setting the cookie header manually for now until the situation is more stable in server support is the best approach.
Comment From: svankamamidi
@bclozel by using Spring framework, SESSION cookie would be added default by the framework right, so how can we stop adding this cookie and instead we manually add SESSION cookie header.
Comment From: bclozel
We don't create sessions automatically. Your application must do it.
Comment From: diego-sousa-st
Good afternoon guys. Do we have some news in this discussion? I was studying some projects here and making some tests I verified that Single Sign On with SpringSecuritySaml using SAML2 will fail with the removal of 3rd party cookies by GoogleChrome.
Comment From: bclozel
Thanks for the reminder @diego-sousa-st - I'll revisit this and check whether we can do this for 6.2.
Comment From: bclozel
I'm scheduling this for Spring Framework 6.2. We'll have to implement this defensively for Servlet 6.1, as https://github.com/jakartaee/servlet/issues/571 will change the behavior for managing Cookie attributes. Spring Framework 6.2 still retains a Servlet 6.0 baseline and will not require Servlet 6.1.
Reactor and most Servlet containers will support this feature. There is no possible support for this with Undertow right now.
Comment From: 4braincells
We are still on Spring Boot v2.7.18, using Spring v5.3.31. Just have a bunch of 120 customers with 10000 end users using the app in IFRAME and this will force customers to remove IFRAME, which will be a royal pain for us.
Comment From: bclozel
@4braincells Are you using WebFlux? Which web server are you using?