¿Cómo funcionan los dominios de cookies del navegador?

Question

Debido a problemas extraños con las cookies de dominio/subdominio que estoy teniendo, me gustaría saber cómo manejan los navegadores las cookies.Si lo hacen de diferentes maneras, también sería bueno saber las diferencias.

En otras palabras, cuando un navegador recibe una cookie, esa cookie PUEDE tener un dominio y una ruta adjuntos.O no, en cuyo caso el navegador probablemente los sustituya por algunos valores predeterminados.Pregunta 1:¿Qué son?

Posteriormente, cuando el navegador está a punto de realizar una solicitud, comprueba sus cookies y filtra las que debe enviar para esa solicitud.Lo hace comparándolos con la ruta y el dominio de la solicitud.Pregunta 2:¿Cuáles son las reglas de coincidencia?

---

Agregado:

La razón por la que pregunto esto es porque estoy interesado en algunos casos extremos.Como:

• ¿Una galleta para .example.com estar disponible para www.example.com?
• ¿Una galleta para .example.com estar disponible para example.com?
• ¿Una galleta para example.com estar disponible para www.example.com?
• ¿Una galleta para example.com estar disponible para anotherexample.com?
• Voluntad www.example.com poder configurar cookies para example.com?
• Voluntad www.example.com poder configurar cookies para www2.example.com?
• Voluntad www.example.com poder configurar cookies para .com?
• Etc.

Añadido 2:

Además, ¿alguien podría sugerirme cómo debería configurar una cookie para que:

• Puede ser configurado por cualquiera de los dos www.example.com o example.com;
• Es accesible por ambos. www.example.com y example.com.

Answer 1

Aunque existe la RFC 2965 (Set-Cookie2, ya había quedado obsoleto RFC 2109) eso debería definir la cookie hoy en día, la mayoría de los navegadores no lo admiten completamente, pero simplemente cumplen con las especificación original de Netscape.

Hay una distinción entre la Dominio Valor del atributo y dominio efectivo:el primero está tomado del Set-Cookie campo de encabezado y este último es la interpretación de ese valor de atributo.Según el RFC 2965, se debe aplicar lo siguiente:

• Si el Conjunto de cookies campo de encabezado no es tener un Dominio atributo, el dominio efectivo es el dominio de la solicitud.
• Si hay un Dominio atributo presente, su valor se utilizará como dominio efectivo (si el valor no comienza con un . será añadido por el cliente).

Teniendo el dominio efectivo también debe coincidencia de dominio el dominio solicitado actualmente para ser configurado;de lo contrario, la cookie será revisada.La misma regla se aplica para elegir las cookies que se enviarán en una solicitud.

---

Al asignar este conocimiento a sus preguntas, se debe aplicar lo siguiente:

• galleta con Domain=.example.com voluntad estar disponible para www.ejemplo.com
• galleta con Domain=.example.com voluntad estar disponible para ejemplo.com
• galleta con Domain=example.com se convertirá en .example.com y por lo tanto voluntad también estará disponible para www.ejemplo.com
• galleta con Domain=example.com voluntad no estar disponible para otroejemplo.com
• www.ejemplo.com voluntad poder configurar cookies para ejemplo.com
• www.ejemplo.com voluntad no poder configurar cookies para www2.ejemplo.com
• www.ejemplo.com voluntad no poder configurar cookies para .com

Y para configurar y leer una cookie para/por www.ejemplo.com y ejemplo.com, configúrelo para .www.example.com y .example.com respectivamente.Pero el primero (.www.example.com) solo será accesible para otros dominios debajo de ese dominio (p. ej. foo.www.ejemplo.com o barra.www.ejemplo.com) dónde .example.com También se puede acceder desde cualquier otro dominio a continuación. ejemplo.com (p.ej. foo.ejemplo.com o bar.ejemplo.com).

Answer 2

Las respuestas anteriores son un poco anticuadas.

RFC 6265 fue publicado en 2011, basado en el consenso navegador en ese momento. Desde entonces, ha habido alguna complicación con el sufijo dominios públicos. He escrito un artículo que explica la situación actual - http://bayou.io/draft/cookie.domain.html

Para resumir, las reglas a seguir en cuanto al dominio de la cookie:

• El dominio de origen de una cookie es el dominio de la solicitud originaria.

• Si el dominio de origen es una dirección IP, atributo de dominio de la cookie no debe ser ajustado.

• Si el atributo de dominio de una cookie no está establecido, la cookie sólo es aplicable a su dominio de origen.

• Si el atributo de dominio de un cookie se establece,

  • la cookie es aplicable a ese dominio y todos sus subdominios;
  • dominio de la cookie debe ser el mismo que, o uno de los padres de, el dominio de origen
  • dominio de la cookie no debe ser un dominio de nivel superior, un sufijo pública, o un padre de un sufijo público.

Puede ser derivado de que una cookie es siempre aplicable a su dominio de origen.

El dominio de la cookie no debe tener un punto inicial, como en .foo.com - sólo tiene que utilizar foo.com

Como ejemplo,

• x.y.z.com puede establecer un dominio de cookie para sí mismo o los padres - y.z.com, z.com, com. Pero no a.x.y.z.com, que es un sufijo público.
• una cookie con domain = edu es aplicable a uk, co.uk, blogspot.com etc.

Los ejemplos de sufijos públicos - compute.amazonaws.com, <=>, <=>, <=>, <=>, <=>

Answer 3

Para una revisión extensa cobertura de los contenidos de RFC2965 . Por supuesto que no significa necesariamente que todos los navegadores se comportan exactamente de la misma manera.

Sin embargo, en general, la regla para la ruta predeterminada si no se especifica en la cookie es la ruta en la URL desde la que llegó la cabecera Set-Cookie. Del mismo modo el valor predeterminado para el dominio es el nombre de host completo en la URL desde la que llegó el Set-Cookie.

reglas de juego para el dominio requieren el dominio de la cookie para que coincida con el host a la que se realiza la solicitud. La cookie puede especificar un partido de dominio más amplio, incluye *. en el atributo de dominio de Set-Cookie (esta área que los navegadores pueden variar). Coincidencia de la ruta (asumiendo que los partidos de dominio) es una simple cuestión de que la ruta solicitada debe estar dentro de la ruta especificada en la cookie. Normalmente las cookies de sesión se establecen con path = / o path = / applicationName / así que la cookie está disponible para todas las solicitudes en la aplicación.

---

Respuesta al Agregado:

• ¿Estará disponible una galleta para .example.com para www.example.com? Sí
• ¿Estará disponible una galleta para .example.com para example.com? No sabe
• ¿Estará disponible una galleta para example.com a www.example.com? ¿No debería, pero ... *
• ¿Estará disponible una galleta para example.com para anotherexample.com? No
• ¿Se www.example.com ser capaz de establecer cookies para example.com? Sí
• ¿Se www.example.com ser capaz de establecer cookies para www2.example.com? No (excepto a través de .example.com)
• ¿Se www.example.com ser capaz de establecer cookies para los dominios .com? No (No se puede establecer una cookie este alto el espacio de nombres ni se puede establecer una para algo así como .co.uk) .

* Soy incapaz de probar esto ahora, pero tengo una idea de que al menos IE7 / 6 tratarían el camino example.com como si fuera .example.com.

Answer 4

El último (tercer ser exactamente) RFC para este problema es el RFC-6265 (Obsoletes RFC-2965 que a su vez deja obsoleto el RFC-2109).

Según ella si el servidor omite el atributo de dominio, la agente de usuario volverá la cookie sólo a la servidor de origen (el servidor en el que reside un recurso dado). Pero también es Advertencia que algunos agentes de usuario existentes tratan a un atributo de dominio ausentes como si el atributo de dominio estaban presentes y contenía el nombre de host actual (por ejemplo, si example.com retornos una cabecera Set-cookie sin un atributo de dominio, estos agentes de usuario enviará erróneamente la cookie para www.example.com también).

Cuando se han especificado el atributo de dominio, que será tratado como nombre de dominio completo (si no es el punto inicial en el atributo será ignorado). Servidor debe coincidir con el dominio especificado en el atributo (tener exactamente el mismo nombre de dominio o subdominio a ser una de ella) para obtener esta cookie. Más exactamente href="http://tools.ietf.org/html/rfc6265#section-5.1.3" especificado aquí .

Así, por ejemplo:

• atributo galleta Domain=.example.com es equivalente a Domain=example.com
• galletas con tales atributos de dominio será disponible example.com y www.example.com
• galletas con tales atributos de dominio será No disponible another-example.com
• que especifica el atributo de galletas como Domain=www.example.com cerrará el camino para www4.example.com

PS: arrastra coma en atributo de dominio hará que el agente de usuario para ignorar el atributo = (

Answer 5

Los RFC son conocidos por no reflejar la realidad.

proyecto-IETF-httpstate en cookies , el trabajo en curso.

Answer 6

Existen reglas que determinan si un navegador aceptará la cabecera de respuesta Set-cabecera (del lado del servidor escritura cookie), un poco diferentes normas / interpretaciones de conjunto de cookies con Javascript (no he probado VBScript).

A continuación, hay reglas que determinan si el navegador enviará una cookie junto con la solicitud de la página.

Existen diferencias entre los principales motores de navegación cómo se manejan las coincidencias de dominio y cómo se interpretan los parámetros en los valores de ruta. Puede encontrar alguna evidencia empírica en el artículo ¿Qué tan distintos navegadores manejan de forma diferente Galletas

Answer 7

Me sorprendió leer la sección 3.3.2 de rechazar las cookies:

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

Esto dice que un navegador debe rechazar una cookie de x.y.z.com con .z.com de dominio, porque 'x.y' contiene un punto. Por lo tanto, a menos que esté malinterpretando el RFC y / o las preguntas anteriores, podría haber añadido preguntas:

¿Estará disponible una galleta para .example.com para www.yyy.example.com? No.

Será una cookie establecida por www.yyy.example.com servidor de origen, con .example.com dominio, tener su valor enviado por el agente de usuario a xxx.example.com? No.

Answer 8

Ater probado todo el caso en el lastest Chrome, Firefox, Safari en 2019.

Respuesta al Agregado:

• ¿Estará disponible una galleta para .example.com para www.example.com? YES
• ¿Estará disponible una galleta para .example.com para example.com? YES
• ¿Estará disponible una galleta para example.com a www.example.com? NO , de dominio sin comodín sólo coincide en sí.
• ¿Estará disponible una galleta para example.com para anotherexample.com? NO
• ¿Se www.example.com ser capaz de establecer cookies para example.com? NO , que será capaz de establecer cookies para '.example.com', pero no 'example.com'.
• ¿Se www.example.com ser capaz de establecer cookies para www2.example.com? NO . Pero puede establecer cookies para .example.com, que www2.example.com puede acceder.
• ¿Se www.example.com ser capaz de establecer cookies para los dominios .com? NO

Answer 9

  

Se www.example.com ser capaz de establecer cookies para .com?

No, pero example.com.fr puede ser capaz de establecer una cookie para example2.com.fr. Firefox protege contra esto manteniendo una lista de dominios de primer nivel: http://securitylabs.websense.com /content/Blogs/3108.aspx

Al parecer, Internet Explorer no permite que los dominios de dos letras que constituyen las galletas, que supongo explica por qué o2.ie simplemente redirige a o2online.ie. A menudo me había preguntado eso.