Respuestas:
La especificación actual de cookies es RFC 6265 , que reemplaza RFC 2109 y RFC 2965 (ambos RFC ahora están marcados como "Históricos") y formaliza la sintaxis para el uso de cookies en el mundo real. Establece claramente:
- Introducción
...
Por razones históricas, las cookies contienen una serie de infelicidades de seguridad y privacidad. Por ejemplo, un servidor puede indicar que una cookie determinada está destinada a conexiones "seguras", pero el atributo Seguro no proporciona integridad en presencia de un atacante de red activo. Del mismo modo, las cookies para un host determinado se comparten en todos los puertos de ese host, aunque la "política del mismo origen" habitual utilizada por los navegadores web aísla el contenido recuperado a través de diferentes puertos.
Y también:
8.5. Confidencialidad débil
Las cookies no proporcionan aislamiento por puerto . Si un servicio que se ejecuta en un puerto puede leer una cookie, un servicio que se ejecuta en otro puerto del mismo servidor también puede leer la cookie. Si un servicio puede escribir una cookie en un puerto, un servicio que se ejecuta en otro puerto del mismo servidor también puede escribir la cookie. Por esta razón, los servidores NO DEBEN ejecutar servicios de desconfianza mutua en diferentes puertos del mismo host y utilizar cookies para almacenar información confidencial de seguridad.
De acuerdo con RFC2965 3.3.1 (que podría ser seguido o no por los navegadores), a menos que el puerto se especifique explícitamente a través del portparámetro del Set-Cookieencabezado, las cookies pueden o no enviarse a cualquier puerto.
El Manual de seguridad del navegador de Google dice: de forma predeterminada, el alcance de las cookies está limitado a todas las URL en el nombre de host actual, y no está vinculado a la información del puerto o protocolo. y algunas líneas más adelante. No hay forma de limitar las cookies a un solo nombre DNS [...] de la misma manera, no hay forma de limitarlas a un puerto específico. (Además, tenga en cuenta, que el IE hace números de puerto no tener en cuenta en su política del mismo origen en absoluto .)
Por lo tanto, no parece seguro confiar en un comportamiento bien definido aquí.
Esta es una pregunta muy antigua, pero pensé que agregaría una solución alternativa que utilicé.
Tengo dos servicios ejecutándose en mi computadora portátil (uno en el puerto 3000 y el otro en 4000). Cuando saltaría entre ( http://localhost:3000yhttp://localhost:4000 ), Chrome pasaría la misma cookie, cada servicio no entendería la cookie y generaría una nueva.
Descubrí que si accedía http://localhost:3000yhttp://127.0.0.1:4000 el problema desaparecía, ya que Chrome mantenía una cookie para localhost y otra para 127.0.0.1.
Nuevamente, a nadie le puede importar en este punto, pero fue fácil y útil para mi situación.
localhostno se puede compartir con 127.0.0.1y viceversa. Pero las cookies en el mismo host / dominio, independientemente del puerto, son compartibles.
Esta es un área gris grande en SOP de cookies (Política del mismo origen).
Teóricamente, puede especificar el número de puerto en el dominio y la cookie no se compartirá. En la práctica, esto no funciona con varios navegadores y se encontrará con otros problemas. Por lo tanto, esto solo es factible si sus sitios no son para el público en general y usted puede controlar qué navegadores usar.
El mejor enfoque es obtener 2 nombres de dominio para la misma IP y no depender de los números de puerto para las cookies.
Una forma alternativa de solucionar el problema es hacer que el nombre de la cookie de sesión esté relacionado con el puerto. Por ejemplo:
Su código podría acceder a la configuración del servidor web para averiguar qué puerto usa su servidor y nombrar la cookie en consecuencia.
Tenga en cuenta que su aplicación recibirá ambas cookies, y debe solicitar la que corresponda a su puerto.
No es necesario tener el número de puerto exacto en el nombre de la cookie, pero esto es más conveniente.
En general, el nombre de la cookie podría codificar cualquier otro parámetro específico de la instancia del servidor que utilice, por lo que puede decodificarse según el contexto correcto.
Estaba experimentando un problema similar al ejecutar (e intentar depurar) dos aplicaciones de Django diferentes en la misma máquina.
Los estaba ejecutando con estos comandos:
./manage.py runserver 8000
./manage.py runserver 8001
Cuando inicié sesión en el primero y luego en el segundo, siempre cerré sesión en el primero y viceversa.
Agregué esto en mi / etc / hosts
127.0.0.1 app1
127.0.0.1 app2
Luego comencé las dos aplicaciones con estos comandos:
./manage.py runserver app1:8000
./manage.py runserver app2:8001
Problema resuelto :)
127.0.0.1:8000por uno, localhost:8000por un segundo y posiblemente ::1:8000(tal vez [::1]:8080) por un tercero sin tener que tocar el archivo de hosts.
::1 app1 app2 app3 app4 app5 appN
Es opcional.
El puerto puede especificarse para que las cookies puedan ser específicas del puerto. No es necesario, el servidor web / aplicación debe ocuparse de esto.
Fuente: artículo de Wikipedia en alemán , RFC2109 , capítulo 4.3.1
Portparámetro en elSet-Cookieencabezado (porque casi nadie lo usó en la práctica), y hace muy explícito que las cookies en el mismo host ya NO son distinguibles por los puertos.