O que significa o prefixo de ponto no domínio do cookie?


93

insira a descrição da imagem aqui

Qual é a diferença entre local.test.come .local.test.com? A captura de tela é do Chrome.




No comentário do user2864740 26 de setembro de 16 às 16:44 - O link está morto, aparentemente o domínio erik.io foi transferido para outro usuário ou registrador de domínio.
qxotk

Respostas:


59

local.test.comserá usado para o domínio, enquanto .local.test.comserá usado para subdomínios também.


11
Portanto local.test.com, não se aplica a x.local.test.com, mas .local.test.comse aplica a local.test.come a x.local.test.com?
ripper234

29
Eu acredito que isso está incorreto. Os cookies são compartilhados com todo e qualquer subdomínio downstream, com ou sem um ponto. Você pode pensar nos subdomínios como cookies "herdados" de seus pais. Portanto, definir um cookie em example.com define-o em blog.example.com e my.blog.example.com. Definir um cookie em blog.example.com define-o em this.is.my.blog.example.com e em todos os subdomínios intermediários. Mas, assim como a herança, o inverso não é verdadeiro. Definir um cookie em blog.example.com não o define em example.com.
geddski

6
Dito isso, você PODE limitar o cookie apenas ao host, não definindo o domínio do cookie (ou definindo como string vazia). Isso, estranhamente, definirá o cookie apenas para o host (example.com) e não para nenhum de seus subdomínios.
geddski

8
Para esclarecer com base em outra resposta, o ponto costumava fazer a diferença, mas agora não faz. O cookie será enviado para qualquer subdomínio do domínio especificado, com ou sem o ponto inicial. O que realmente controla se é passado para subdomínios é se você define um domínio no cookie ou não. Se você não definir nenhum domínio, o cookie será enviado apenas para o domínio exato que o emitiu. Ele nunca será enviado para domínios pai menos específicos (por exemplo, "local.test.com" não será incluído nas solicitações para "test.com") e só será enviado para subdomínios correspondentes se você definir um valor de domínio.
Triynko

4
@Triynko, o ponto faz diferença quando você está tentando atualizar um cookie. Não consegui isolar todas as regras, mas vi que os resultados variam com base na presença do ponto inicial ou não, e não é direto. O modo como isso funciona varia de acordo com o navegador e nem tudo é intuitivo. Controlar se um cookiename tem ou não um ponto inicial no navegador não é a tarefa de programação mais simples que já fiz.
DanAllen

83

O ponto inicial significa que o cookie também é válido para subdomínios; no entanto, as especificações HTTP recentes (RFC 6265) mudaram essa regra, de modo que os navegadores modernos não devem se preocupar com o ponto inicial. O ponto pode ser necessário para navegadores antigos que implementam o RFC 2109 obsoleto.

RFC 6265 seção 4.1.2.3

Por exemplo, se o valor do atributo Domain for "example.com", o agente do usuário incluirá o cookie no cabeçalho do Cookie ao fazer solicitações HTTP para example.com, www.example.com e www.corp.example. com. (Observe que um% x2E (".") À esquerda, se presente, é ignorado mesmo que esse caractere não seja permitido, mas um% x2E (".") À esquerda, se presente, fará com que o agente do usuário ignore o atributo. )


1
O RFC é datado de abril de 2011. Tanto o IE8 quanto o IE9 foram inicialmente lançados antes dessa data e - infelizmente - ainda são usados. Portanto, meu melhor palpite (não tentei) é que eles precisam do ponto inicial. Alguém sabe de uma estimativa de quantos navegadores ainda estão em execução no antigo RFC?
BlaM de

erik.io/blog/2014/03/04/definitive-guide-to-cookie-domains recomenda o uso de um ponto principal para obter a melhor compatibilidade ao desejar incluir subdomínios. Esse requisito de compatibilidade continuará diminuindo. (Não obrigatório para 6255, mas obrigatório e com o mesmo resultado final de 2109.)
usuário2864740

12

Do artigo O guia definitivo para domínios de cookies e por que um prefixo www torna seu site mais seguro :

Conclusão

Embora as definições sejam um pouco diferentes, podemos simplificá-las para qualquer uma dessas implementações como:

  • Quando nenhum domínio é definido no cookie, o cookie deve corresponder apenas ao nome de host exato da solicitação. [NOTA: isso é diferente de retornar um Set-Cookie com um domínio sem um ponto!] Sem subdomínios, sem correspondências parciais. Isso significa simplesmente não incluir o atributo de domínio - não é válido definir um atributo de domínio vazio. Infelizmente, o Internet Explorer parece tratar isso como o nome do host junto com quaisquer subdomínios .

  • Ao definir um domínio no cookie, a escolha segura é que ele seja precedido por um ponto, como .erik.io. O cookie corresponderá a todos os subdomínios.

  • Definir um domínio de cookie sem um ponto precedente, como erik.io, é inválido nas implementações RFC 2109 e produzirá o mesmo comportamento de um ponto anterior em outras implementações. Não há como restringir um cookie a um domínio definido explicitamente específico, sem a inclusão de subdomínios.

Outras observações valiosas:
  • Em todos os RFCs, um domínio de cookie especificado deve corresponder ao nome do host atual, por correspondência normal. Definir um cookie para www.erik.io em uma resposta de erik.io não é válido, pois um cookie com o domínio www.erik.io não corresponde a erik.io, sendo o primeiro mais específico.

  • No RFC 6265, os domínios são explicitamente em letras minúsculas ao analisar o cabeçalho Set-Cookie.


1

O ponto inicial em ".local.test.com" é exatamente como o Chrome visualiza cookies com um "Domain = local.test.com" definido (ou um "Domain = .local.test.com", que é o mesmo).

As definições de Set-Cookie sem "Domain = something" exibem o domínio (= host) sem um ponto inicial.

Portanto, o ponto inicial no cromo não reflete se um ponto inicial foi ou não usado no servidor, mas se esse cookie tinha ou não um "Domínio = algo" em sua definição do servidor. (E se tivesse, o cookie também será enviado para subdomínios).

Pelo menos é isso que meus testes mostram. O Chrome deve tornar isso mais fácil de ler, por exemplo, visualizar a string exata que definiu o cookie e quando ele foi recebido.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.