将网站转换为使用分区 Cookie 时,如果任何给定客户端同时存在名称相同的分区和未分区 Cookie,您可能会遇到意外行为。
设置分区 Cookie 不会替换或覆盖同名的现有非分区 Cookie。只要启用了第三方 Cookie,这两者就会存在,只不过放在单独的 Cookie 罐中。停用第三方 Cookie 后,系统只会接受分屏 Cookie。如果这两个 Cookie 都存在,则无法以编程方式分辨哪个已分区,哪个未分区,这可能会导致意外行为。
您可以通过以下两种方式解决此问题: 1. 使要替换的 Cookie 失效 2. 重命名 Cookie
主要注意事项
在改用分区 Cookie 时,请注意以下几点:
- 无法以编程方式确定在 HTTP 请求中发送的 Cookie 是分区还是非分区 Cookie。不过,您可以在 Chrome 开发者工具中确定 Cookie 的分区状态。您可以使用 CookieStore API 区分不具有
HttpOnly
属性的已分区和未分区 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 中。