Comment fonctionnent les domaines de cookies du navigateur?

En raison de problèmes de cookies de domaine / sous-domaine étranges que j'obtiens, j'aimerais savoir comment les navigateurs gèrent les cookies. S'ils le font de différentes manières, ce serait aussi bien de connaître les différences.

En d'autres termes - lorsqu'un navigateur reçoit un cookie, ce cookie PEUT avoir un domaine et un chemin d'accès qui lui sont attachés. Ou non, auquel cas le navigateur leur substitue probablement des valeurs par défaut. Question 1: quels sont-ils?

Plus tard, lorsque le navigateur est sur le point de faire une demande, il vérifie ses cookies et filtre ceux qu'il doit envoyer pour cette demande. Il le fait en les comparant au chemin et au domaine des demandes. Question 2: quelles sont les règles de correspondance?

La raison pour laquelle je pose cette question est que je m'intéresse à certains cas marginaux. Comme:

• Un cookie .example.comsera-t-il disponible pour www.example.com?
• Un cookie .example.comsera-t-il disponible pour example.com?
• Un cookie example.comsera-t-il disponible pour www.example.com?
• Un cookie example.comsera-t-il disponible pour anotherexample.com?
• Sera www.example.comen mesure de mettre en biscuit pour example.com?
• Sera www.example.comen mesure de mettre en biscuit pour www2.example.com?
• Sera www.example.comen mesure de mettre en biscuit pour .com?
• Etc.

Ajouté 2:

Aussi, quelqu'un pourrait-il suggérer comment définir un cookie afin que:

• Il peut être défini par www.example.comou example.com;
• Il est accessible à la fois par www.example.comet example.com.

Bien qu'il existe le RFC 2965 ( Set-Cookie2, avait déjà obsolète le RFC 2109 ) qui devrait définir le cookie de nos jours, la plupart des navigateurs ne le prennent pas entièrement en charge, mais se conforment simplement aux spécifications originales de Netscape .

Il existe une distinction entre la valeur d'attribut de domaine et le domaine effectif: le premier est tiré du Set-Cookiechamp d'en-tête et le second est l'interprétation de cette valeur d'attribut. Selon la RFC 2965, ce qui suit devrait s'appliquer:

• Si le champ d'en - tête Set-Cookie n'a pas d' attribut Domain , le domaine effectif est le domaine de la demande.
• Si un attribut Domaine est présent, sa valeur sera utilisée comme domaine effectif (si la valeur ne commence pas par un, .elle sera ajoutée par le client).

Ayant le domaine effectif, il doit également correspondre au domaine du domaine actuellement demandé pour être défini; sinon le cookie sera révisé. La même règle s'applique pour choisir les cookies à envoyer dans une demande.

En associant ces connaissances à vos questions, les éléments suivants devraient s'appliquer:

• Un cookie avec Domain=.example.com sera disponible pour www.example.com
• Un cookie avec Domain=.example.com sera disponible pour example.com
• Le cookie avec Domain=example.comsera converti .example.comet sera donc également disponible pour www.example.com
• Le cookie avec neDomain=example.com sera pas disponible pour un autreexemple.com
• www.example.com sera en mesure de mettre en biscuit pour example.com
• www.example.com sera pas en mesure de définir cookies pour www2.example.com
• www.example.com sera pas en mesure de définir cookies pour .com

Et pour définir et lire un cookie pour / par www.example.com et example.com , définissez-le pour .www.example.comet .example.comrespectivement. Mais le premier ( .www.example.com) ne sera accessible que pour les autres domaines en dessous de ce domaine (par exemple foo.www.example.com ou bar.www.example.com ) où il .example.comest également possible d'accéder à tout autre domaine en dessous de example.com (par exemple foo. exemple.com ou bar.exemple.com ).

Les réponses précédentes sont un peu dépassées.

La RFC 6265 a été publiée en 2011, sur la base du consensus du navigateur à l'époque. Depuis lors, il y a eu quelques complications avec les domaines de suffixe publics. J'ai écrit un article expliquant la situation actuelle - http://bayou.io/draft/cookie.domain.html

Pour résumer, les règles à suivre concernant le domaine des cookies:

• Le domaine d'origine d'un cookie est le domaine de la demande d'origine.

• Si le domaine d'origine est une IP, l'attribut de domaine du cookie ne doit pas être défini.

• Si l'attribut de domaine d'un cookie n'est pas défini, le cookie ne s'applique qu'à son domaine d'origine.

• Si l'attribut de domaine d'un cookie est défini,

  • le cookie est applicable à ce domaine et à tous ses sous-domaines;
  • le domaine du cookie doit être le même ou un parent du domaine d'origine
  • le domaine du cookie ne doit pas être un TLD, un suffixe public ou un parent d'un suffixe public.

On peut déduire qu'un cookie est toujours applicable à son domaine d'origine.

Le domaine des cookies ne doit pas avoir de point de tête, comme dans .foo.com- utilisez simplementfoo.com

Par exemple,

• x.y.z.compeut définir un domaine de cookie pour lui - même ou les parents - x.y.z.com, y.z.com, z.com. Mais non com, qui est un suffixe public.
• un cookie avec le domaine = y.z.comest applicable à y.z.com, x.y.z.com, a.x.y.z.cometc.

Des exemples de suffixes publics - com, edu, uk, co.uk, blogspot.com,compute.amazonaws.com

Pour une couverture étendue, consultez le contenu de la RFC2965 . Bien sûr, cela ne signifie pas nécessairement que tous les navigateurs se comportent exactement de la même manière.

Cependant, en règle générale, la règle pour le chemin par défaut, si aucun spécifié dans le cookie, est le chemin dans l'URL à partir de laquelle l'en-tête Set-Cookie est arrivé. De même, la valeur par défaut pour le domaine est le nom d'hôte complet dans l'URL d'où le Set-Cookie est arrivé.

Les règles de correspondance pour le domaine nécessitent que le domaine de cookie corresponde à l'hôte auquel la demande est adressée. Le cookie peut spécifier une correspondance de domaine plus large en incluant *. dans l'attribut de domaine de Set-Cookie (cette zone que les navigateurs peuvent varier). Faire correspondre le chemin (en supposant que le domaine correspond) est une simple question que le chemin demandé doit être à l'intérieur du chemin spécifié sur le cookie. En règle générale, les cookies de session sont définis avec path = / ou path = / applicationName / afin que le cookie soit disponible pour toutes les demandes dans l'application.

• Un cookie pour .example.com sera-t-il disponible pour www.example.com? Oui
• Un cookie pour .example.com sera-t-il disponible pour example.com? Je ne sais pas
• Un cookie pour example.com sera-t-il disponible pour www.example.com? Ne devrait pas mais ... *
• Un cookie pour exemple.com sera-t-il disponible pour un autre exemple.com? Non
• Www.example.com pourra-t-il installer des cookies pour example.com? Oui
• Www.example.com pourra-t-il définir des cookies pour www2.example.com? Non (sauf via .example.com)
• Www.example.com pourra-t-il définir des cookies pour .com? Non (vous ne pouvez pas définir un cookie aussi haut dans l'espace de noms, ni en créer un pour quelque chose comme .co.uk) .

*Je ne peux pas tester cela pour le moment mais j'ai une idée qu'au moins IE7 / 6 traiterait le chemin example.comcomme s'il l'était .example.com.

Le dernier (troisième pour être exactement) RFC pour ce problème est RFC-6265 (Obsolète RFC-2965 qui à son tour obsolète RFC-2109).

Selon lui, si le serveur omet l'attribut Domaine, l'agent utilisateur ne renverra le cookie qu'au serveur d'origine (le serveur sur lequel réside une ressource donnée). Mais il avertit également que certains agents utilisateurs existants traitent un attribut de domaine absent comme si l'attribut de domaine était présent et contenait le nom d'hôte actuel (par exemple, si example.com renvoie un en-tête Set-Cookie sans attribut de domaine, ces agents utilisateurs envoyer à tort le cookie à www.example.com également).

Lorsque l'attribut de domaine a été spécifié, il sera traité comme un nom de domaine complet (s'il y a le premier point dans l'attribut, il sera ignoré). Le serveur doit correspondre au domaine spécifié dans l'attribut (avoir exactement le même nom de domaine ou être un sous-domaine de celui-ci) pour obtenir ce cookie. Plus précisément, il est spécifié ici .

Ainsi, par exemple:

• l'attribut cookie Domain=.example.comest équivalent àDomain=example.com
• des cookies avec de tels attributs de domaine seront disponibles pour example.com et www.example.com
• les cookies avec de tels attributs de domaine ne seront pas disponibles pour un autre-exemple.com
• spécifier un attribut de cookie comme Domain=www.example.comfermera la voie à www4.example.com

PS: la virgule de fin dans l'attribut de domaine obligera l'agent utilisateur à ignorer l'attribut = (

J'ai testé tous les cas dans les derniers Chrome, Firefox, Safari en 2019.

Réponse à Ajouté:

• Un cookie pour .example.com sera-t-il disponible pour www.example.com? OUI
• Un cookie pour .example.com sera-t-il disponible pour example.com? OUI
• Un cookie pour example.com sera-t-il disponible pour www.example.com? NON , le domaine sans caractère générique ne correspond qu'à lui-même.
• Un cookie pour exemple.com sera-t-il disponible pour un autre exemple.com? NON
• Www.example.com pourra-t-il installer des cookies pour example.com? NON , il pourra définir des cookies pour '.example.com', mais pas pour 'example.com'.
• Www.example.com pourra-t-il définir des cookies pour www2.example.com? Non . Mais il peut définir des cookies pour .example.com, auxquels www2.example.com peut accéder.
• Www.example.com pourra-t-il définir des cookies pour .com? NON

Les RFC sont connus pour ne pas refléter la réalité.

Mieux vaut vérifier draft-ietf-httpstate-cookie , travail en cours.

Il existe des règles qui déterminent si un navigateur acceptera l'en-tête de réponse Set-header (écriture de cookies côté serveur), des règles / interprétations légèrement différentes pour les cookies définis à l'aide de Javascript (je n'ai pas testé VBScript).

Ensuite, il existe des règles qui déterminent si le navigateur enverra un cookie avec la demande de page.

Il existe des différences entre les principaux moteurs de navigation, la façon dont les correspondances de domaine sont traitées et la façon dont les paramètres des valeurs de chemin sont interprétés. Vous pouvez trouver des preuves empiriques dans l'article Comment différents navigateurs gèrent les cookies différemment

J'ai été surpris de lire la section 3.3.2 sur le rejet des cookies:

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

Cela signifie qu'un navigateur doit rejeter un cookie de xyzcom avec le domaine .z.com, car 'xy' contient un point. Donc, à moins que j'interprète mal le RFC et / ou les questions ci-dessus, il pourrait y avoir des questions ajoutées:

Un cookie pour .example.com sera-t-il disponible pour www.yyy.example.com? Non.

Un cookie défini par le serveur d'origine www.yyy.example.com, avec le domaine .example.com, aura-t-il sa valeur envoyée par l'agent utilisateur à xxx.example.com? Non.

Sera www.example.comen mesure de mettre en biscuit pour .com?

Non, mais example.com.frpeut être en mesure de définir un cookie pour example2.com.fr. Firefox protège contre cela en maintenant une liste de TLD: http://securitylabs.websense.com/content/Blogs/3108.aspx

Apparemment, Internet Explorer ne permet pas aux domaines à deux lettres de définir des cookies, ce qui explique pourquoi je o2.ieredirige simplement vers o2online.ie. Je me le demandais souvent.