最近，浏览器正在通过将samesite cookie默认值增强为Lax来提高安全性，以防止CSRF攻击，即，如果服务器在通过响应set-cookie标头设置cookie时未设置samesite属性，浏览器会将其视为Lax，而不是存储，因此在后续调用中，如果这些请求失败，则cookie不会发送回服务器。这是在跨域通信中发生的，其中跨域应用程序在主网站的iFrame中运行。
我们有一个这样的服务器应用程序，它在成功的身份验证请求的响应上设置两个cookie，并且应该将这些cookie随每个后续调用一起发送回服务器，以使服务器认为请求已被身份验证以进行进一步处理。这些Cookie没有显式设置任何samesite属性，因此新的浏览器（Chrome 80）不会在后续调用中将它们发送回去。
服务器应用程序托管在tomcat上。因此，为了缓解此问题，我们使用了tomcat的cookieprocessor将cookie的samesite属性设置为“ none”，以便进行跨域调用。不幸的是，这没有用。尽管通过cookieprocessor显式设置了samesite属性，但通过开发人员工具进行检查时，响应并未显示出samesite属性的任何痕迹。
所以这里的问题是：我是否正确地认为tomcat应该修改服务器的响应，以便将相同站点属性添加到通过响应上的set-cookie标头设置的cookie中？我尝试通过设置远程调试来调试cookieprocessor代码，但是看起来响应没有被拦截，因此cookie标头被修改了。我在这里做错了什么？
注意：我已经在应用程序的meta-inf / context.xml中配置了Cookie处理器。
答案 0 :(得分：3)
那么您正在使用Tomcat，但是您正在使用哪个版本的Tomcat？
CookieProcessor SameSite支持的初始版本使用“无”来指代取消设置SameSite值的行为。
https://bz.apache.org/bugzilla/show_bug.cgi?id=63865
Fixed in:
- master for 9.0.28 onwards
- 8.5.x for 8.5.48 onwards
我不确定Tomcat的CookieProcessor是否考虑了客户端的用户代理。
如果以这种方式实现，则您的应用程序可能不支持已知的不兼容客户端：Chrome 51-66，MacOSX Mojave（10.14）Safari /嵌入式，iOS 12、12.13.2之前的UCBrowser
https://www.chromium.org/updates/same-site/incompatible-clients
我们使用addHeader支持SameSite解决了我们的常规Cookie。
我们在nginx层中解决了会话cookie。
对于JSESSIONID，似乎每次创建新会话时，您也可以使用Filter来包装HttpServletRequest，以附加具有适当属性的会话cookie副本。尽管它为覆盖的JSESSIONID添加了〜80B。
答案 1 :(得分：2)
我实际上自己解决了这个谜。 Cookieprocessor仅在通过response.addCookie（）方法添加cookie时才有效。因此，如果cookie是通过set / add标头方法设置的，则cookieporcessor不会执行任何操作。实际上，我们的服务器应用程序执行标头方法来添加cookie，而不是addCookie（）方法。