将您的网站转换为分区 Cookie 时,如果任何给定客户端同时存在同名的分区和未分区 Cookie,您都可能会遇到意外行为。
设置分区 Cookie 不会替换或替换同名的现有未分区 Cookie。只要启用了第三方 Cookie,两者都存在,但它们位于不同的 Cookie JAR 中。停用第三方 Cookie 后,系统仅接受已分区的 Cookie。如果两个 Cookie 同时存在,系统就无法以编程方式判断哪个已分区,哪个没有,这可能会导致意外行为。
解决此问题的方法有两种: 1. 使您要替换的 Cookie 过期 2. 重命名 Cookie
主要注意事项
在改用分区 Cookie 时,请注意以下几点:
- 您无法以程序化方式确定 Cookie 是已分区还是未分区。不过,您可以在 Chrome 开发者工具中确定 Cookie 的分区状态。
- 分区 Cookie 不会覆盖未分区的 Cookie。如果两个 Cookie 完全相同(即具有相同属性(例如名称、网域或路径)的 Cookie),只要其中一个 Cookie 具有
Partitioned
属性,系统就会将其视为不同的 Cookie。 - 最好避免在同一网络调用中返回具有相同名称的分区 Cookie 和未分区 Cookie。
使您要替换的 Cookie 过期
如果您的网站或服务无法应对名称的变更,您可以在现有的未分区 Cookie 失效时创建新的分区 Cookie。虽然无法确定 Cookie 是否已分区,但不带 Partitioned
属性的 Set-Cookie
标头不会影响未分区的 Cookie。
以下示例展示了如何使名为 example
的未分区 Cookie 失效,并让任何分区 Cookie 不受影响,即使它们具有相同的名称也是如此。系统将添加或更新名为 cookieName
的新分区 Cookie(如果已存在)。
Set-Cookie: example=-1;HttpOnly;SameSite=None;Secure;Max-Age:0
Set-Cookie: cookieName=value;Secure;SameSite=None;MaxAge=34560000;Partitioned
重命名 Cookie
确保无缝转换的最可靠方法是为分区和未分区 Cookie 使用不同的名称。例如,如果您有一个名为“example”的未分区 Cookie,则可以将其迁移到分区 Cookie。
Set-Cookie: example-partitioned=value;Secure;SameSite=None;MaxAge=34560000;Partitioned
由于 Cookie 的有效期并非以编程方式公开,因此无法将新 Cookie 的有效期设置为与未分区 Cookie 的有效期一致。在此过程中,更新 Cookie 的值可能比较实用。
维护分区 Cookie 和未分区 Cookie
在过渡期间,请考虑维护两个单独的已分区 Cookie:一个已分区,另一个未分区。例如,您可能同时拥有 auth
和 auth-partitioned
Cookie,其中后者使用 Partitioned
属性进行设置。
每次该值更新时,您都应尝试设置这两个 Cookie。
- 在已阻止第三方 Cookie 但尚不支持 CHIPS 的客户端上:两种 Cookie 都不会被接受。
- 在阻止第三方 Cookie 和支持 CHIPS 的客户端上:
auth
Cookie 将被拒绝,但auth-partitioned
Cookie 会被接受。 - 在不阻止第三方 Cookie 的客户端上,无论它们是否支持 CHIPS:
auth
和auth-partitioned
都会被接受。
当您的应用需要读取身份验证 Cookie 时,您应该先查找 auth-partitioned
;但如果您必须临时回滚更改,可以回退到查找 auth
Cookie。
当您确定大多数用户的 Cookie 均已刷新后,就可以停用 auth-partitioned
Cookie,并将 Partitioned 属性添加到常规身份验证 Cookie 中。