Respostas:
A especificação atual de cookies é a RFC 6265 , que substitui a RFC 2109 e a RFC 2965 (agora as duas RFCs estão marcadas como "Histórico") e formaliza a sintaxe para o uso no mundo real de cookies. Afirma claramente:
- Introdução
...
Por razões históricas, os cookies contêm várias infelicidades de segurança e privacidade. Por exemplo, um servidor pode indicar que um determinado cookie é destinado a conexões "seguras", mas o atributo Secure não fornece integridade na presença de um invasor de rede ativo. Da mesma forma, os cookies de um determinado host são compartilhados em todas as portas desse host, mesmo que a "política de mesma origem" usada pelos navegadores da Web isole o conteúdo recuperado por diferentes portas.
E também:
8.5 Fraca confidencialidade
Os cookies não fornecem isolamento por porta . Se um cookie for legível por um serviço em execução em uma porta, ele também poderá ser lido por um serviço em execução em outra porta do mesmo servidor. Se um cookie for gravável por um serviço em uma porta, o cookie também será gravável por um serviço em execução em outra porta do mesmo servidor. Por esse motivo, os servidores NÃO devem executar serviços desconfiados em portas diferentes do mesmo host e usar cookies para armazenar informações confidenciais de segurança.
De acordo com o RFC2965 3.3.1 (que pode ou não ser seguido pelos navegadores), a menos que a porta seja especificada explicitamente pelo portparâmetro do Set-Cookiecabeçalho, os cookies podem ou não ser enviados para qualquer porta.
O Manual de segurança do navegador do Google diz: por padrão, o escopo dos cookies é limitado a todos os URLs no nome do host atual - e não está vinculado às informações de porta ou protocolo. e algumas linhas depois Não há como limitar os cookies a um único nome DNS [...] da mesma forma, não há como limitá-los a uma porta específica. (Além disso, mantenha em mente, que o IE faz números de porta não fator na sua política de mesma origem em tudo .)
Portanto, não parece seguro confiar em nenhum comportamento bem definido aqui.
Esta é uma pergunta muito antiga, mas pensei em adicionar uma solução alternativa que usei.
Eu tenho dois serviços em execução no meu laptop (um na porta 3000 e outro na 4000). Quando eu pularia entre ( http://localhost:3000e http://localhost:4000), o Chrome passaria o mesmo cookie, cada serviço não entenderia o cookie e geraria um novo.
Descobri que, se eu acessasse http://localhost:3000e http://127.0.0.1:4000, o problema desaparecesse, pois o Chrome mantinha um cookie para localhost e um para 127.0.0.1.
Mais uma vez, ninguém pode se importar neste momento, mas foi fácil e útil para a minha situação.
localhostnão pode ser compartilhado 127.0.0.1e vice-versa. Mas os cookies no mesmo host / domínio, independentemente da porta, são compartilháveis.
Essa é uma grande área cinza no SOP do cookie (mesma política de origem).
Teoricamente, você pode especificar o número da porta no domínio e o cookie não será compartilhado. Na prática, isso não funciona com vários navegadores e você encontrará outros problemas. Portanto, isso só é possível se seus sites não são para o público em geral e você pode controlar quais navegadores usar.
A melhor abordagem é obter dois nomes de domínio para o mesmo IP e não depender de números de porta para cookies.
Uma maneira alternativa de contornar o problema é tornar o nome do cookie da sessão relacionado à porta. Por exemplo:
Seu código pode acessar a configuração do servidor da web para descobrir qual porta seu servidor usa e nomeie o cookie de acordo.
Lembre-se de que seu aplicativo receberá os dois cookies e é necessário solicitar o que corresponde à sua porta.
Não é necessário ter o número exato da porta no nome do cookie, mas isso é mais conveniente.
Em geral, o nome do cookie pode codificar qualquer outro parâmetro específico para a instância do servidor usada, para que possa ser decodificado no contexto correto.
Eu estava com um problema semelhante ao executar (e tentar depurar) dois aplicativos Django diferentes na mesma máquina.
Eu os estava executando com estes comandos:
./manage.py runserver 8000
./manage.py runserver 8001
Quando eu entrei no primeiro e depois no segundo, sempre saí do primeiro e vice-versa.
Adicionei isso em meus / etc / hosts
127.0.0.1 app1
127.0.0.1 app2
Então iniciei os dois aplicativos com estes comandos:
./manage.py runserver app1:8000
./manage.py runserver app2:8001
Problema resolvido :)
127.0.0.1:8000por um, localhost:8000por um segundo e possivelmente ::1:8000(talvez [::1]:8080) por um terceiro sem precisar tocar no arquivo de hosts.
::1 app1 app2 app3 app4 app5 appN
É opcional.
A porta pode ser especificada para que os cookies possam ser específicos da porta. Não é necessário, o servidor / aplicativo da web deve cuidar disso.
Fonte: Artigo alemão da Wikipedia , RFC2109 , capítulo 4.3.1
Portparâmetro noSet-Cookiecabeçalho (porque quase ninguém realmente o usou na prática) e torna muito explícito que os cookies no mesmo host não são mais distintos pelas portas.