tomcat 的 cookie 处理器未修改响应中设置的 cookie 的 Samesite 属性
Samesite attribute of cookies set in response are not getting modifed by tomcat's cookieprocessor
最近浏览器通过将 samesite cookie 默认值增强为 Lax 来提高安全性以防止 CSRF 攻击，即，如果在通过响应设置 cookie 时服务器未设置 samesite 属性 set-cookie header ，浏览器会将它们视为 Lax，并且不会存储，因此在后续调用中，如果这些请求失败，cookie 不会发送回服务器。这发生在跨域通信中，其中跨域应用程序在主网站的 iFrame 中 运行。
我们有一个这样的服务器应用程序，它在成功的身份验证请求的响应上设置两个 cookie，这些 cookie 应该在每次后续调用时发送回服务器，以使服务器相信请求已通过身份验证以进行进一步处理.这些 cookie 没有明确设置任何 samesite 属性，因此新浏览器 (Chrome 80) 不会在后续调用中将它们发回。
服务器应用程序托管在 tomcat 上。所以为了缓解这个问题我们使用tomcat的cookieprocessor设置cookie的samesite属性设置为"none"，这样就可以进行跨域调用了。不幸的是，这没有用。尽管通过 cookieprocessor 显式设置了 samesite 属性，但通过开发人员工具检查时的响应不会显示任何 samesite 属性的痕迹。
所以这里的问题是：tomcat 应该修改服务器的响应以将 samesite 属性添加到通过 set-cookie header 在回复？我尝试通过设置远程调试来调试 cookieprocessor 代码，但看起来响应没有被拦截，因此 cookie header 正在被修改。我在这里做错了什么？
注意：我已经在应用程序的 meta-inf/context.xml.
中配置了 cookieprocessor
所以您使用的是 Tomcat，但是您使用的 Tomcat 是哪个版本？
CookieProcessor SameSite 支持的初始版本使用 "None" 来引用取消设置 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/Embedded、iOS 12、UCBrowser prior至 12.13.2
https://www.chromium.org/updates/same-site/incompatible-clients
我们通过使用 addHeader 来支持 SameSite 来解决我们的正常 cookie。
我们在 nginx 层解决了会话 cookie。
对于 JSESSIONID，似乎您还可以使用过滤器来包装 HttpServletRequest，以便在创建新会话时附加具有适当属性的会话 cookie 的副本。尽管它为重写的 JSESSIONID 添加了 ~80B。
我居然自己解开了谜团。只有通过 response.addCookie() 方法添加 cookie 时，Cookieprocessor 才有效。因此，如果通过 set/add header 方法设置 cookie，cookieporcessor 将不会执行任何操作。实际上，我们的服务器应用程序使用 header 方法来添加 cookie 而不是 addCookie() 方法。
最近浏览器通过将 samesite cookie 默认值增强为 Lax 来提高安全性以防止 CSRF 攻击，即，如果在通过响应设置 cookie 时服务器未设置 samesite 属性 set-cookie header ，浏览器会将它们视为 Lax，并且不会存储，因此在后续调用中，如果这些请求失败，cookie 不会发送回服务器。这发生在跨域通信中，其中跨域应用程序在主网站的 iFrame 中 运行。
我们有一个这样的服务器应用程序，它在成功的身份验证请求的响应上设置两个 cookie，这些 cookie 应该在每次后续调用时发送回服务器，以使服务器相信请求已通过身份验证以进行进一步处理.这些 cookie 没有明确设置任何 samesite 属性，因此新浏览器 (Chrome 80) 不会在后续调用中将它们发回。
服务器应用程序托管在 tomcat 上。所以为了缓解这个问题我们使用tomcat的cookieprocessor设置cookie的samesite属性设置为"none"，这样就可以进行跨域调用了。不幸的是，这没有用。尽管通过 cookieprocessor 显式设置了 samesite 属性，但通过开发人员工具检查时的响应不会显示任何 samesite 属性的痕迹。
所以这里的问题是：tomcat 应该修改服务器的响应以将 samesite 属性添加到通过 set-cookie header 在回复？我尝试通过设置远程调试来调试 cookieprocessor 代码，但看起来响应没有被拦截，因此 cookie header 正在被修改。我在这里做错了什么？
注意：我已经在应用程序的 meta-inf/context.xml.
中配置了 cookieprocessor所以您使用的是 Tomcat，但是您使用的 Tomcat 是哪个版本？
CookieProcessor SameSite 支持的初始版本使用 "None" 来引用取消设置 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/Embedded、iOS 12、UCBrowser prior至 12.13.2
https://www.chromium.org/updates/same-site/incompatible-clients
我们通过使用 addHeader 来支持 SameSite 来解决我们的正常 cookie。
我们在 nginx 层解决了会话 cookie。
对于 JSESSIONID，似乎您还可以使用过滤器来包装 HttpServletRequest，以便在创建新会话时附加具有适当属性的会话 cookie 的副本。尽管它为重写的 JSESSIONID 添加了 ~80B。
我居然自己解开了谜团。只有通过 response.addCookie() 方法添加 cookie 时，Cookieprocessor 才有效。因此，如果通过 set/add header 方法设置 cookie，cookieporcessor 将不会执行任何操作。实际上，我们的服务器应用程序使用 header 方法来添加 cookie 而不是 addCookie() 方法。