O que é um cookie?
Cookies HTTP explicados
Os cookies HTTP, na maioria das vezes apenas chamados de "cookies", foram durante algum tempo, mas ainda não são bem compreendidos. O primeiro problema é um monte de equívocos, que vão desde cookies como spyware ou vírus até a simples ignorância sobre como eles funcionam. O segundo problema é a falta de interfaces consistentes para trabalhar com cookies. Apesar de todas as questões em torno deles, os cookies são uma parte tão importante do desenvolvimento web que, se eles desaparecerem sem uma substituição, muitos dos nossos aplicativos web favoritos seriam inúteis.
Origem dos cookies
Um dos maiores problemas nos primeiros dias da web foi como gerenciar o estado. Em suma, o servidor não tinha como saber se dois pedidos eram do mesmo navegador. A abordagem mais fácil, no momento, foi inserir um token na página quando foi solicitada e obter esse token passado de volta com o próximo pedido. Isso requeria usar um formulário com um campo oculto contendo o token ou passar o token como parte da string de consulta do URL. Ambas as soluções eram intensamente operações manuais e propensas a erros.
Lou Montulli , um funcionário da Netscape Communications na época, é creditado com a aplicação do conceito de " cookies mágicos " à comunicação na web em 1994. O problema que ele estava tentando resolver era o primeiro carrinho de compras da web, agora é um pilar de todos sites de compras. Sua especificação original fornece informações básicas sobre como funcionam os cookies, que foi formalizada no RFC 2109 (a referência para a maioria das implementações do navegador) e, eventualmente, evoluiu para o RFC 2965 . Montulli também receberia uma patente dos Estados Unidos para os cookies. O Netscape Navigator suportou cookies desde a sua primeira versão, e os cookies agora são suportados por todos os navegadores da Web.
O que é um cookie?
Simplesmente, um cookie é um pequeno arquivo de texto que é armazenado por um navegador na máquina do usuário. Os cookies são texto simples; eles não contêm nenhum código executável. Uma página da Web ou servidor instrui um navegador para armazenar essas informações e, em seguida, enviá-lo de volta com cada solicitação subseqüente com base em um conjunto de regras. Os servidores da Web podem então usar essas informações para identificar usuários individuais. A maioria dos sites que exigem um login geralmente configurará um cookie uma vez que suas credenciais tenham sido verificadas, e você pode navegar até todas as partes do site, desde que esse cookie esteja presente e validado. Mais uma vez, o cookie apenas contém dados e não é prejudicial por si só.
Criação de Cooke
Um servidor web especifica um cookie para ser armazenado enviando um cabeçalho HTTP chamado
Set-Cookie. O formato do Set-Cookiecabeçalho é uma seqüência de caracteres da seguinte forma (as partes entre colchetes são opcionais):
A primeira parte do cabeçalho, o valor, geralmente é uma string no formato
name=value. Na verdade, a especificação original indica que este é o formato a ser usado, mas os navegadores não fazem tal validação em valores de cookies. Você pode, de fato, especificar uma seqüência de caracteres sem um sinal de igual e será armazenado exatamente o mesmo. Ainda assim, o uso mais comum é especificar um valor de cookie como name=value(e a maioria das interfaces o suporta exclusivamente).
Quando um cookie está presente, e as regras opcionais permitem, o valor do cookie é enviado ao servidor com cada pedido subseqüente. O valor do cookie é armazenado em um cabeçalho HTTP chamado
Cookiee contém apenas o valor do cookie sem nenhuma das outras opções. Tal como:
As opções especificadas
Set-Cookiesão apenas para o uso do navegador e não são recuperáveis uma vez que foram definidas. O valor do cookie é exatamente a mesma string que foi especificada Set-Cookie; não há mais interpretação ou codificação do valor. Se houver vários cookies para a solicitação dada, então eles são separados por um ponto-e-vírgula e espaço, como:
As estruturas do lado do servidor geralmente fornecem funcionalidades para analisar cookies e disponibilizar seus valores programaticamente.
Codificação de cookies
Existe alguma confusão sobre a codificação de um valor de cookie. A crença comum é que os valores de cookies devem ser codificados em URL, mas isso é uma falácia mesmo que seja a implementação de fato. A especificação original indica que apenas três tipos de caracteres devem ser codificados: ponto e vírgula, vírgula e espaço em branco. A especificação indica que a codificação de URL pode ser usada, mas pára de exigi-la. O RFC não menciona a codificação de qualquer tipo. Ainda assim, quase todas as implementações executam algum tipo de codificação de URL em valores de cookies. No caso de
name=valueformatos, o nome e o valor normalmente são codificados separadamente, enquanto o sinal de igual é deixado como está.A opção expira
Cada uma das opções após o valor do cookie são separadas por ponto e vírgula e espaço e cada uma especifica as regras sobre quando o cookie deve ser enviado de volta para o servidor. A primeira opção é
expires, que indica quando o cookie não deve mais ser enviado para o servidor e, portanto, pode ser excluído pelo navegador. O valor dessa opção é uma data no formato Wdy, DD-Mon-YYYY HH:MM:SS GMT, como:
Sem a
expiresopção, um cookie tem uma vida útil de uma única sessão. Uma sessão é definida como terminada quando o navegador é desligado, portanto, os cookies de sessão existem somente enquanto o navegador permanece aberto. É por isso que você verá frequentemente uma caixa de seleção ao se conectar a um aplicativo da Web perguntando se você gostaria que suas informações de login fossem salvas: se você selecionar sim, uma expiresopção é anexada ao cookie de login. Se a expiresopção estiver definida para uma data que aparece no passado, o cookie será imediatamente excluído.A opção de domínio
A próxima opção é
domain, que indica o (s) domínio (s) para o qual o cookie deve ser enviado. Por padrão, domainé definido como o nome do host da página configurando o cookie, então o valor do cookie é enviado sempre que uma solicitação é feita para o mesmo nome do host. Por exemplo, o domínio padrão para um conjunto de cookies neste site seria www.nczonline.net. A domainopção é usada para ampliar o número de domínios para os quais o valor do cookie será enviado. Amostra:
Considere o caso de uma rede grande como o Yahoo! que tem muitos locais na forma de nome.yahoo.com (por exemplo, my.yahoo.com , finance.yahoo.com , etc). Um único valor de cookie pode ser definido para todos esses sites, definindo a
domainopção para simplesmente yahoo.com. O navegador executa uma comparação de cola deste valor e o nome do host para o qual uma solicitação é enviada (ou seja, inicia a comparação a partir do final da string) e envia o Cookiecabeçalho correspondente quando há uma correspondência.
O valor definido para a
domainopção deve fazer parte do nome do host que está enviando o Set-Cookiecabeçalho. Não pude, por exemplo, configurar um cookie no google.com porque isso iria introduzir um problema de segurança. As domainopções inválidas são simplesmente ignoradas.A opção de caminho
Outra maneira de controlar quando o
Cookiecabeçalho será enviado é especificar a pathopção. Semelhante à opção de domínio, pathindica um caminho de URL que deve existir no recurso solicitado antes de enviar o Cookiecabeçalho. Essa comparação é feita comparando o valor da opção caráter por caractere com o início do URL da solicitação. Se os caracteres correspondem, o Cookiecabeçalho será enviado. Amostra:
Neste exemplo, a
pathopção seria combinar /blog, /blogrolletc .; Tudo o que começa com /blogé válido. Observe que essa comparação só é feita assim que a domainopção foi verificada. O valor padrão para a pathopção é o caminho do URL que enviou o Set-Cookiecabeçalho.A opção segura
A última opção é
secure. Ao contrário das outras opções, esta é apenas uma bandeira e não tem nenhum valor adicional especificado. Um cookie seguro só será enviado ao servidor quando uma solicitação for feita usando SSL e o protocolo HTTPS. A idéia de que o conteúdo do cookie é de alto valor e pode ser potencialmente prejudicial para transmitir como texto claro. Amostra:
Na realidade, informações confidenciais ou sensíveis nunca devem ser armazenadas ou transmitidas em cookies, pois todo o mecanismo é inerentemente inseguro. Por padrão, os cookies configurados sobre uma conexão HTTPS são definidos automaticamente como seguros.
Manutenção de cookies e ciclo de vida
Qualquer número de opções pode ser especificado para um único cookie, e essas opções podem aparecer em qualquer ordem. Por exemplo:
Esse cookie tem quatro características de identificação: o cookie
name, a domain, o path, ea securebandeira. Para alterar o valor deste cookie no futuro, outro Set-Cookiecabeçalho deve ser enviado usando o mesmo nome, domínio e caminho do cookie. Por exemplo:
Isso substitui o valor do cookie original por um novo. No entanto, mudar mesmo uma dessas opções cria um cookie completamente diferente, como:
Depois de retornar este cabeçalho, agora há dois cookies com o nome de "nome". Se você acessasse uma página
www.nczonline.net/blog, o seguinte cabeçalho seria incluído na solicitação:
Há dois cookies neste cabeçalho chamado "nome", com o mais específico
pathsendo retornado primeiro. A cadeia de cookies é sempre devolvida na ordem da mais específica domain-path-securetupla a menos específica. Suponha que eu esteja em www.nczonline.net/bloge defina outro cookie com as configurações padrão:
O cabeçalho retornado agora se torna:
Uma vez que o cookie com o valor "Mike" usa o nome do host (
www.nczonline.net) para o seu domínio e o caminho completo ( /blog) como seu caminho, é mais específico do que os outros dois.Usando datas de validade
Quando um cookie é criado com uma data de validade, essa data de validade se refere ao cookie identificado pelo nome
domain- path- - secure. Para alterar a data de validade de um cookie, você deve especificar exatamente a mesma tupla. Ao alterar o valor de um cookie, você não precisa definir a data de validade de cada vez porque não é parte das informações de identificação. Exemplo:
A data de validade do cookie já foi configurada, então a próxima vez que eu quiser mudar o valor do cookie, eu posso usar seu nome:
A data de validade neste cookie não mudou, uma vez que as características de identificação do cookie são as mesmas. Na verdade, a data de validade não mudará até que você o altere manualmente novamente. Isso significa que um cookie de sessão pode se tornar um cookie persistente (um que dura várias sessões) dentro da mesma sessão, mas o contrário não é verdade. Para mudar um cookie persistente para um cookie de sessão, você deve excluir o cookie persistente, definindo a data de validade para uma hora no passado e, em seguida, crie um cookie de sessão com o mesmo nome.
Tenha em mente que a data de validade é verificada em relação ao horário do sistema no computador que está executando o navegador. Não há como verificar se a hora do sistema está sincronizada com a hora do servidor e, portanto, podem ocorrer erros quando houver uma discrepância entre a hora do sistema e a hora do servidor.
Remoção automática de cookies
Existem alguns motivos pelos quais um cookie pode ser removido automaticamente pelo navegador:
- Os cookies de sessão são removidos quando a sessão acabou (o navegador está fechado).
- Os cookies persistentes são removidos quando a data e hora de validade foram atingidas.
- Se o limite de cookies do navegador for atingido, os cookies serão removidos para abrir espaço para o cookie criado pela última vez. Para mais detalhes, veja minha postagem sobre as restrições de cookies .
O gerenciamento de cookies é importante para evitar qualquer desses casos de remoção automática quando não são intencionais.
Restrições de cookies
Há uma série de restrições colocadas em cookies para evitar abusos e proteger tanto o navegador como o servidor de efeitos prejudiciais. Existem dois tipos de restrições: número de cookies e tamanho total de cookies. A especificação original colocou um limite de 20 cookies por domínio, que foi seguido por navegadores iniciais e continuou através do Internet Explorer 7. Durante uma das atualizações da Microsoft, eles aumentaram o limite de cookies no IE 7 para 50 cookies. O IE 8 possui um máximo de 50 cookies por domínio também. O Firefox também possui um limite de 50 cookies enquanto o Opera tem um limite de 30 cookies. Safari e Chrome não têm limite na quantidade de cookies por domínio.
O tamanho máximo para todos os cookies enviados para o servidor permaneceu o mesmo desde a especificação original do cookie: 4 KB. Qualquer coisa acima desse limite está truncada e não será enviada para o servidor.
Subcoocentes
Devido ao limite do número de cookies, os desenvolvedores surgiram com a idéia de subcoocumentos para aumentar a quantidade de armazenamento disponível para eles. Subcoocédios são pares de nome-valor armazenados dentro de um valor de cookie e normalmente possuem um formato semelhante ao seguinte:
Essa abordagem permite que um único cookie segure várias combinações de nome-valor sem ultrapassar o limite de cookies do navegador. A desvantagem para criar cookies neste formato é que a análise personalizada é necessária para extrair os valores em vez de depender do formato de cookie muito mais simples. Alguns frameworks do lado do servidor estão começando a suportar o armazenamento de subcookie. O utilitário YUI Cookie , que escrevi, oferece suporte a leitura / escrita de subcoque de JavaScript.
Cookies em JavaScript
Você pode criar, manipular e remover cookies em JavaScript usando a
document.cookiepropriedade. Esta propriedade funciona como o Set-Cookiecabeçalho quando atribuído e como o Cookiecabeçalho quando lido. Ao criar um cookie, você deve usar uma string que esteja no mesmo formato que Set-Cookieespera:
A definição do valor
document.cookie não exclui todos os cookies armazenados na página. Simplesmente cria ou modifica o cookie especificado na string. Na próxima vez que um pedido for feito para o servidor, esses cookies são enviados junto com outros que foram criados via Set-Cookie. Não há diferença perceptível entre esses cookies.
Para recuperar os valores dos cookies em JavaScript, leia apenas a partir da
document.cookiepropriedade. A cadeia retornada está no mesmo formato que o Cookievalor do cabeçalho, então vários cookies são separados por um ponto e vírgula e espaço. Exemplo:
Por isso, você precisa analisar a seqüência de cookies manualmente para extrair os dados reais do cookie. Existem inúmeros recursos que descrevem abordagens de análise de cookies para JavaScript, incluindo meu livro, JavaScript profissional , então não vou entrar aqui. Muitas vezes, é mais fácil usar uma biblioteca de JavaScript já existente, como o utilitário YUI Cookiepara lidar com cookies em JavaScript ao invés de recriar esses algoritmos à mão.
Os cookies retornados acessando o document.cookie seguem as mesmas regras de acesso que os cookies enviados para o servidor. Para acessar cookies via JavaScript, a página deve estar no mesmo domínio e ter o mesmo caminho e ter o mesmo nível de segurança especificado pelo cookie.
Nota: Não é possível recuperar as opções para os cookies uma vez que já foi definido via JavaScript, assim você vai ter idéia do que o
domain, path, data de validade, ou securebandeira.Cookies somente para HTTP
A Microsoft apresentou uma nova opção para cookies no Internet Explorer 6 SP1: cookies de apenas HTTP. A idéia por trás de cookies somente para HTTP é instruir um navegador que um cookie nunca deve ser acessado via JavaScript através da
document.cookiepropriedade. Este recurso foi projetado como uma medida de segurança para ajudar a prevenir ataques de scripts de sites cruzados (XSS) perpetrados roubando cookies via JavaScript (falarei sobre problemas de segurança com cookies em outro post, este é suficientemente longo como está). Hoje, o Firefox 2.0.0.5+, o Opera 9.5+ e o Chrome também oferecem suporte a cookies apenas para HTTP. Safari a partir de 3,2 ainda não.
Para criar um cookie de apenas HTTP, basta adicionar uma
HttpOnlybandeira ao seu cookie:
Uma vez que este sinalizador está configurado, não há acesso via
document.cookieeste cookie. O Internet Explorer também vai um passo adiante e não permite o acesso a este cabeçalho usando os métodos getAllResponseHeaders()ou enquanto outros navegadores ainda o permitem. O Firefox corrigiu essa vulnerabilidade em 3.0.6, embora ainda existam várias vulnerabilidades do navegador que flutuam ( lista completa de suporte do navegador).getResponseHeader()XMLHttpRequest
Você não pode definir cookies do HTTP apenas do JavaScript, o que faz sentido porque você também não pode lê-los de JavaScript.
Conclusão
Há muito para saber e entender sobre cookies para usá-los efetivamente. É realmente surpreendente como uma técnica criada há mais de dez anos ainda está em uso quase exatamente da mesma forma que foi implementada pela primeira vez. Esta publicação é um guia para os conceitos básicos que todos devem saber sobre os cookies nos navegadores, mas não é, de qualquer forma, uma referência completa. Os cookies são uma parte importante da web hoje e gerenciá-los de forma inadequada pode levar a todos os tipos de problemas, desde a má experiência do usuário até a segurança. Eu espero que este writeup derrame alguma luz sobre a magia dos cookies.
Disclaimer: Qualquer ponto de vista e opinião expressos neste artigo são os de Nicholas C. Zakas e, de qualquer forma, não refletem os do meu empregador, meus colegas, Wrox Publishing , O'Reilly Publishing ou qualquer outra pessoa. Eu falo apenas para mim, não para eles.
Comentários
Postar um comentário