Ao fazer a transição do seu site para cookies particionados, você poderá encontrar um comportamento inesperado se um cookie particionado e não particionado com os mesmos nomes estiver presente em qualquer cliente.
A definição de um cookie particionado não substitui nem substitui um cookie não particionado atual com o mesmo nome. Ambos existirão, desde que os cookies de terceiros estejam ativados, mas em jars de cookies separados. Quando os cookies de terceiros são desativados, apenas o particionado é aceito. Se ambos os cookies estiverem presentes, não será possível dizer programaticamente qual deles está particionado e qual não está, e isso pode levar a um comportamento inesperado.
Há duas opções possíveis para resolver isso: 1. Expirar o cookie que você está substituindo. 2. Renomear os cookies
Principais considerações
Ao fazer a transição para cookies particionados, lembre-se do seguinte:
- Não há como determinar programaticamente se um cookie é particionado ou não. No entanto, é possível determinar o estado particionado de um cookie no Chrome DevTools.
- Os cookies particionados não substituem os não particionados. Dois cookies que forem exatamente iguais (ou seja, com os mesmos atributos, como nome, domínio ou caminho) serão tratados como cookies separados se apenas um tiver o atributo
Partitioned
. - É melhor evitar uma situação em que você teria um cookie particionado e um cookie não particionado com o mesmo nome sendo retornado na mesma chamada de rede.
Expirar os cookies que você está substituindo
Se o seu site ou serviço não puder acomodar uma alteração no nome, você poderá criar um novo cookie particionado enquanto expira o cookie não particionado atual. Embora não haja como determinar se um cookie é particionado ou não, os cabeçalhos Set-Cookie
sem um atributo Partitioned
não afetam cookies não particionados.
No exemplo a seguir, mostramos como expirar o cookie não particionado chamado example
e deixar os cookies particionados sem impacto, mesmo que eles tenham o mesmo nome. Um novo cookie particionado chamado cookieName
será adicionado ou atualizado se ele já existir.
Set-Cookie: example=-1;HttpOnly;SameSite=None;Secure;Max-Age:0
Set-Cookie: cookieName=value;Secure;SameSite=None;MaxAge=34560000;Partitioned
Renomear os cookies
A maneira mais robusta de garantir que haja uma transição perfeita é usar nomes diferentes para os cookies particionados e não particionados. Por exemplo, se você tiver um cookie não particionado chamado "example", poderá migrá-lo para um cookie particionado.
Set-Cookie: example-partitioned=value;Secure;SameSite=None;MaxAge=34560000;Partitioned
Como a expiração do cookie não é exposto programaticamente, não há como configurar a expiração do novo cookie para coincidir com a expiração do cookie não particionado. Pode ser pragmático atualizar o valor do cookie durante esse processo.
Manter cookies particionados e não particionados
Durante o período de transição, considere manter dois cookies sincronizados separados: um que esteja particionado e outro não. Por exemplo, você pode ter cookies auth
e auth-partitioned
, em que o último foi definido com o atributo Partitioned
.
Sempre que o valor for atualizado, tente definir os dois cookies.
- Em clientes que bloqueiam cookies de terceiros, mas ainda não são compatíveis com os CHIPS, nenhum cookie será aceito.
- Em clientes que bloqueiam cookies de terceiros e aceitam CHIPS: o cookie
auth
é rejeitado, mas o cookieauth-partitioned
é aceito. - Em clientes que não bloqueiam cookies de terceiros, independente de
oferecerem suporte a CHIPS:
auth
eauth-partitioned
são aceitos.
Quando o aplicativo precisar ler o cookie de autenticação, procure auth-partitioned
primeiro. Porém, se você precisar reverter temporariamente a alteração, volte a procurar o cookie auth
.
Depois de estabelecer que a maioria dos usuários teve
os cookies atualizados, o cookie auth-partitioned
pode ser desativado e o
atributo particionado pode ser adicionado ao cookie de autenticação normal.