Como funcionam os domínios de cookies do navegador?

Devido a problemas estranhos de cookies de domínio / subdomínio que estou recebendo, gostaria de saber como os navegadores lidam com os cookies. Se eles fizerem isso de maneiras diferentes, também seria bom conhecer as diferenças.

Em outras palavras – quando um navegador recebe um cookie, esse cookie pode ter um domínio e um caminho anexado a ele. Ou não, caso em que o navegador provavelmente substitui alguns padrões por eles. Pergunta 1: o que são eles?

Mais tarde, quando o navegador está prestes a fazer uma solicitação, ele verifica seus cookies e filtra os que ele deve enviar para essa solicitação. Isso é feito combinando-os com o caminho e o domínio das solicitações. Pergunta 2: quais são as regras de correspondência?


Adicionado:

A razão pela qual estou perguntando isso é porque estou interessado em alguns casos extremos. Gostar:

  • Um cookie para .example.com estará disponível para www.example.com ?
  • Um cookie para .example.com estará disponível para example.com ?
  • Um cookie de example.com estará disponível para www.example.com ?
  • Um cookie de example.com estará disponível para anotherexample.com ?
  • O www.example.com poderá definir cookies para example.com ?
  • O www.example.com poderá definir cookies para www2.example.com ?
  • O www.example.com poderá definir cookies para .com ?
  • Etc.

Adicionado 2:

Além disso, alguém poderia sugerir como eu deveria definir um cookie para que:

  • Pode ser definido por www.example.com ou example.com ;
  • É acessível por www.example.com e example.com .

Embora haja o RFC 2965 ( Set-Cookie2 , já obsoleto RFC 2109 ) que deve definir o cookie hoje em dia, a maioria dos navegadores não suportam totalmente isso, mas apenas cumprem a especificação original da Netscape .

Há uma distinção entre o valor do atributo Domínio e o domínio efetivo: o primeiro é retirado do campo de header Set-Cookie e o segundo é a interpretação desse valor de atributo. De acordo com a RFC 2965, deve aplicar-se o seguinte:

  • Se o campo de header Set-Cookie não tiver um atributo de domínio , o domínio efetivo será o domínio da solicitação.
  • Se houver um atributo de Domínio presente, seu valor será usado como domínio efetivo (se o valor não começar com . Ele será adicionado pelo cliente).

Tendo o domínio efetivo, ele também deve corresponder ao domínio atual solicitado para ser definido; caso contrário, o cookie será revisado. A mesma regra se aplica para escolher os cookies a serem enviados em uma solicitação.


Mapeando este conhecimento para suas perguntas, o seguinte deve ser aplicado:

  • Cookie com Domain=.example.com estará disponível para http://www.example.com
  • Cookie com Domain=.example.com estará disponível por exemplo.com
  • Cookie com Domain=example.com será convertido em .example.com e, portanto , também estará disponível para http://www.example.com
  • Cookie com Domain=example.com não estará disponível para anotherexample.com
  • http://www.example.com poderá definir cookies para example.com
  • http://www.example.com não poderá definir cookies para www2.example.com
  • http://www.example.com não poderá definir cookies para .com

Para definir e ler um cookie para / por http://www.example.com e example.com , defina-o para .www.example.com e .example.com respectivamente. Mas o primeiro ( .www.example.com ) só será acessível para outros domínios abaixo desse domínio (por exemplo, foo.www.example.com ou bar.www.example.com ), onde .example.com também pode ser acessado por qualquer outro domínio abaixo de example.com (por exemplo, foo.example.com ou bar.example.com ).

As respostas anteriores estão um pouco desatualizadas.

O RFC 6265 foi publicado em 2011, com base no consenso de navegadores da época. Desde então, tem havido alguma complicação com domínios públicos do sufixo. Eu escrevi um artigo explicando a situação atual – http://bayou.io/draft/cookie.domain.html

Para resumir, as regras a seguir em relação ao domínio do cookie:

  • O domínio de origem de um cookie é o domínio da solicitação de origem.

  • Se o domínio de origem for um IP, o atributo de domínio do cookie não deve ser definido.

  • Se o atributo de domínio de um cookie não estiver definido, o cookie será aplicável apenas ao seu domínio de origem.

  • Se o atributo de domínio de um cookie estiver definido,

    • o cookie é aplicável a esse domínio e a todos os seus subdomínios;
    • o domínio do cookie deve ser o mesmo ou pai do domínio de origem
    • o domínio do cookie não pode ser um TLD, um sufixo público ou um pai de um sufixo público.

Pode ser derivado que um cookie é sempre aplicável ao seu domínio de origem.

O domínio do cookie não deve ter um ponto inicial, como em .foo.com – simplesmente use foo.com

Como um exemplo,

  • xyzcom pode definir um domínio de cookie para si mesmo ou para os pais – xyzcom , yzcom , z.com . Mas não com , que é um sufixo público.
  • um cookie com domain = yzcom é aplicável a yzcom , xyzcom , axyzcom etc.

Exemplos de sufixos públicos – com , edu , uk , co.uk , blogspot.com , compute.amazonaws.com

Para uma extensa cobertura, revise o conteúdo da RFC2965 . Claro que isso não significa necessariamente que todos os navegadores se comportam exatamente da mesma maneira.

No entanto, em geral, a regra para o Caminho padrão, se nenhum for especificado no cookie, é o caminho no URL a partir do qual o header Set-Cookie chegou. Da mesma forma, o padrão para o Domínio é o nome completo do host na URL a partir da qual o Set-Cookie chegou.

As regras de correspondência para o domínio exigem que o cookie Domínio corresponda ao host para o qual a solicitação está sendo feita. O cookie pode especificar uma correspondência de domínio mais ampla por include *. no atributo de domínio do Set-Cookie (esta área que os navegadores podem variar). A correspondência do caminho (supondo que o domínio corresponda) é simples, pois o caminho solicitado deve estar dentro do caminho especificado no cookie. Normalmente, os cookies de session são definidos com path = / ou path = / applicationName /, portanto, o cookie está disponível para todas as solicitações no aplicativo.


Resposta para Adicionado:

  • Um cookie para .example.com estará disponível para http://www.example.com? sim
  • Um cookie para .example.com estará disponível para example.com? Não sei
  • Um cookie de example.com estará disponível para http://www.example.com? Não deveria mas …
  • Um cookie de example.com estará disponível para anotherexample.com? Não
  • O http://www.example.com poderá definir cookies para example.com? sim
  • O http://www.example.com poderá definir cookies para www2.example.com? Não (exceto via .example.com)
  • O http://www.example.com poderá definir cookies para .com? Não (Não é possível definir um cookie tão alto no namespace nem você pode definir um para algo como .co.uk) .

* Não posso testar isso agora, mas tenho uma idéia de que pelo menos o IE7 / 6 trataria o caminho example.com como se fosse .example.com .

O último (terceiro a ser exatamente) RFC para esta questão é RFC-6265 (Obsoletes RFC-2965, que por sua vez, obsoleta RFC-2109).

De acordo com ele, se o servidor omitir o atributo Domínio, o agente do usuário retornará o cookie apenas ao servidor de origem (o servidor no qual um determinado recurso reside). Mas também está avisando que alguns agentes de usuário existentes tratam um atributo Domínio ausente como se o atributo Domínio estivesse presente e contivesse o nome do host atual (por exemplo, se example.com retornar um header Set-Cookie sem um atributo Domínio, esses agentes serão erroneamente enviar o cookie para http://www.example.com também).

Quando o atributo Domínio tiver sido especificado, ele será tratado como nome de domínio completo (se houver o ponto inicial no atributo, ele será ignorado). O servidor deve corresponder ao domínio especificado no atributo (ter exatamente o mesmo nome de domínio ou ser um subdomínio dele) para obter esse cookie. Mais precisamente, especificado aqui .

Então, por exemplo:

  • atributo do cookie Domain=.example.com é equivalente a Domain=example.com
  • os cookies com esses atributos de domínio estarão disponíveis para example.com e http://www.example.com
  • cookies com esses atributos de domínio não estarão disponíveis para outro-exemplo.com
  • A especificação do atributo de cookie, como Domain=www.example.com , fechará o caminho para www4.example.com

PS: vírgula final no atributo Domínio fará com que o agente do usuário ignore o atributo = (

Existem regras que determinam se um navegador aceitará o header de resposta Set-header (escrita de cookie do lado do servidor), regras / interpretações ligeiramente diferentes para o conjunto de cookies usando Javascript (eu não testei o VBScript).

Depois, há regras que determinam se o navegador enviará um cookie junto com a solicitação de página.

Existem diferenças entre os principais mecanismos de navegadores como as correspondências de domínio são tratadas e como os parâmetros nos valores de caminho são interpretados. Você pode encontrar algumas evidências empíricas no artigo Como diferentes navegadores lidam com cookies de maneira diferente

Os RFCs são conhecidos por não refletirem a realidade.

Melhor verificar o draft-ietf-httpstate-cookie , trabalho em andamento.

Fiquei surpreso ao ler a seção 3.3.2 sobre a rejeição de cookies:

http://tools.ietf.org/html/rfc2965

Isso diz que um navegador deve rejeitar um cookie do xyzcom com o domínio .z.com, porque ‘xy’ contém um ponto. Então, a menos que eu esteja interpretando mal o RFC e / ou as perguntas acima, pode haver perguntas adicionadas:

Um cookie para .example.com estará disponível para http://www.yyy.example.com? Não.

Um cookie definido pelo servidor de origem http://www.yyy.example.com, com domínio .example.com, terá seu valor enviado pelo agente do usuário para xxx.example.com? Não.

O www.example.com poderá definir cookies para .com ?

Não, mas example.com.fr pode ser capaz de definir um cookie para example2.com.fr . O Firefox protege contra isso mantendo uma lista de TLDs: http://securitylabs.websense.com/content/Blogs/3108.aspx

Aparentemente, o Internet Explorer não permite que domínios de duas letras definam cookies, o que, suponho, explica por que o2.ie simplesmente redireciona para o2online.ie . Eu frequentemente me perguntava isso.