Cookies, Local Storage e IndexedDB: o que uma sessão realmente é
Fazer login grava em três lugares distintos. Saber qual é qual explica por que as sessões sobrevivem a algumas coisas, quebram com outras e por que sincronizar um perfil precisa mover os três.
"Estar logado" parece uma coisa só. São pelo menos três, guardadas em três lugares diferentes, com três tempos de vida diferentes, e essa diferença explica a maior parte do comportamento confuso que as pessoas encontram ao mover sessões entre máquinas.
Cookies
Pequenos pares chave-valor, enviados automaticamente a cada requisição ao site que os definiu. É aqui que o token de sessão costuma ficar.
- Delimitados por domínio e caminho, com data de expiração.
- Um cookie `Secure` só é enviado por HTTPS; um cookie `HttpOnly` é invisível para o JavaScript da página.
- Um cookie de sessão não tem expiração e deve desaparecer quando o navegador fecha.
Os cookies são o menor dos três e o mais decisivo. Perca-os e você é desconectado.
Local Storage e Session Storage
Armazenamento chave-valor de strings, lido e gravado pelo JavaScript da página, delimitado por origem. Nunca é enviado com uma requisição. A página precisa lê-lo deliberadamente.
Os aplicativos guardam aqui preferências, dados de perfil em cache, feature flags e, muitas vezes, um token de atualização. O Local Storage persiste até ser limpo; o Session Storage dura apenas enquanto a aba existe.
IndexedDB
Um banco de dados de verdade dentro do navegador: registros estruturados, índices, transações. É onde um aplicativo web moderno guarda tudo o que é substancial: históricos de mensagens em cache, filas offline, chaves de criptografia para recursos com criptografia de ponta a ponta.
Por que isso importa para um perfil
Isso dá ao "isolamento" um significado preciso. Dois perfis estão isolados quando os três estão separados, além do cache e do estado das extensões. Uma ferramenta que isola cookies e compartilha o IndexedDB isolou o terço fácil do problema.
Isso também define o nível exigido para mover um perfil entre máquinas. Levar apenas os cookies reproduz a forma de uma sessão sem a sua substância.
| Armazenamento | Gravado por | Normalmente guarda |
|---|---|---|
| Cookies | Servidor e script da página | Token de sessão, preferências, identificadores de rastreamento |
| Local Storage | Script da página | Tokens de atualização, estado da interface, dados de perfil em cache |
| Session Storage | Script da página | Estado por aba, descartado quando a aba fecha |
| IndexedDB | Script da página | Dados em cache, filas offline, chaves de criptografia |
Movendo uma sessão entre as suas próprias máquinas
O PowerOps captura cookies, Local Storage e IndexedDB quando um perfil fecha e os restaura quando ele abre em outro lugar. Cada categoria é uma chave, para o workspace inteiro ou para um único perfil, de modo que você move exatamente o tanto que pretende.
Duas propriedades valem ser conhecidas sobre como isso funciona:
- O snapshot é criptografado na máquina de origem, com uma chave que pertence ao workspace, e descriptografado na máquina que abre o perfil. Isso não é criptografia de ponta a ponta: o serviço guarda uma cópia dessa chave para que os seus outros computadores possam recebê-la.
- Um perfil fica aberto em uma máquina por vez. Enquanto está aberto, ele mantém uma concessão (lease), e a outro dispositivo é informado qual dispositivo o detém, em vez de ser permitido bifurcar a sessão em duas cópias divergentes.
Esse segundo ponto é uma limitação deliberada. Duas máquinas editando uma sessão de forma independente produzem duas sessões meio válidas e, com bastante frequência, uma conta desconectada em ambas. Um conjunto de cookies não tem como resolver um conflito de mesclagem.
O que levar para a prática
Feche os perfis em vez de encerrá-los à força. A gravação ao fechar é o que torna a sessão portátil, e é o hábito mais barato desta lista.
PowerOps
