Comment fonctionnent les domaines de cookies du navigateur?

En raison de problèmes de cookies de domaine / sous-domaine étranges, je voudrais savoir comment les navigateurs gèrent les cookies. S’ils le font de différentes manières, il serait également intéressant 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’access. Ou pas, auquel cas le navigateur les remplace probablement par des valeurs par défaut. Question 1: quels sont-ils?

Plus tard, lorsque le navigateur est sur le sharepoint 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 requêtes. Question 2: quelles sont les règles correspondantes?


Ajoutée:

La raison pour laquelle je pose cette question est que je suis intéressé par certains cas extrêmes. Comme:

  • Un cookie pour .example.com sera-t-il disponible pour www.example.com ?
  • Un cookie pour .example.com sera-t-il disponible pour example.com ?
  • Un cookie pour example.com sera-t-il disponible pour www.example.com ?
  • Un cookie pour example.com sera-t-il disponible pour anotherexample.com ?
  • Est-ce que www.example.com pourra définir des cookies pour example.com ?
  • Est-ce que www.example.com pourra définir des cookies pour www2.example.com ?
  • Est-ce que www.example.com pourra définir des cookies pour .com ?
  • Etc.

Ajouté 2:

En outre, quelqu’un pourrait-il suggérer comment définir un cookie pour que:

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

    Bien qu’il y ait le RFC 2965 ( Set-Cookie2 , déjà obsolète de la 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 à la spécification originale de Netscape .

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

    • Si le champ d’en tête Set-Cookie n’a pas d’atsortingbut Domain , le domaine effectif est le domaine de la demande.
    • Si un atsortingbut Domain 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 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 requête.


    Mappant cette connaissance sur vos questions, les éléments suivants doivent s’appliquer:

    • Cookie avec Domain=.example.com sera disponible pour http://www.example.com
    • Cookie avec Domain=.example.com sera disponible pour example.com
    • Cookie avec Domain=example.com sera converti en .example.com et sera donc également disponible pour http://www.example.com
    • Cookie avec Domain=example.com ne sera pas disponible pour anotherexample.com
    • http://www.example.com pourra définir des cookies pour example.com
    • http://www.example.com ne pourra pas définir de cookie pour www2.example.com
    • http://www.example.com ne pourra pas définir de cookie pour .com

    Et pour définir et lire un cookie pour / by http://www.example.com et example.com , définissez-le respectivement pour .www.example.com et .example.com . Mais le premier ( .www.example.com ) ne sera accessible que pour les autres domaines situés sous ce domaine (par exemple, foo.www.example.com ou bar.www.example.com ) où autre domaine ci-dessous example.com (par exemple, foo.example.com ou bar.example.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 des navigateurs à ce moment-là. Depuis lors, il y a eu des complications avec les domaines de suffixe public. J’ai écrit un article expliquant la situation actuelle – http://bayou.io/draft/cookie.domain.html

    En résumé, 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 adresse IP, l’atsortingbut de domaine du cookie ne doit pas être défini.

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

    • Si l’atsortingbut 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 identique 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 devrait pas avoir de point, comme dans .foo.com – utilisez simplement foo.com

    Par exemple,

    • xyzcom peut définir un domaine de cookie pour lui-même ou ses parents – xyzcom , yzcom , z.com . Mais pas com , qui est un suffixe public.
    • un cookie avec domain = yzcom est applicable à yzcom , xyzcom , axyzcom etc.

    Exemples de suffixes publics – com , edu , uk , co.uk , blogspot.com , compute.amazonaws.com

    Pour une couverture complète, 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 général, la règle pour le chemin par défaut si aucun n’est 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 à partir de laquelle le cookie Set-Cookie est arrivé.

    Les règles de correspondance pour le domaine requièrent que le domaine du cookie corresponde à l’hôte sur lequel la demande est faite. Le cookie peut spécifier une correspondance de domaine plus large par include *. dans l’atsortingbut domain de Set-Cookie (cette zone que les navigateurs peuvent varier). Faire correspondre le chemin d’access (en supposant que le domaine correspond) est une simple affaire que le chemin demandé doit se trouver dans le chemin spécifié sur le cookie. Les cookies de session sont généralement définis avec path = / ou path = / nom_application / afin que le cookie soit disponible pour toutes les demandes dans l’application.


    Réponse à l’ajout:

    • Un cookie pour .example.com sera-t-il disponible pour http://www.example.com? Oui
    • Un cookie pour .example.com sera-t-il disponible pour example.com? Ne sais pas
    • Un cookie pour exemple.com sera-t-il disponible pour http://www.example.com? Ne devrait pas mais … *
    • Un cookie pour exemple.com sera-t-il disponible pour anotherexample.com? Non
    • Est-ce que http://www.example.com pourra définir des cookies pour example.com? Oui
    • Est-ce que http://www.example.com pourra définir des cookies pour www2.example.com? Non (sauf via .example.com)
    • Est-ce que http://www.example.com pourra définir des cookies pour .com? Non (impossible de définir un cookie aussi haut dans l’espace de noms, ni d’en définir un autre comme .co.uk) .

    * Je ne peux pas tester cela maintenant, mais je pense que IE7 / 6 au moins traiterait le chemin example.com comme s’il s’agissait de .example.com .

    La dernière (troisième à être exactement) RFC pour ce numéro est la RFC-6265 (RFC-2965 obsolètes obsolètes RFC-2109).

    Selon lui, si le serveur omet l’atsortingbut Domain, l’agent utilisateur renvoie le cookie uniquement au serveur d’origine (le serveur sur lequel réside une ressource donnée). Mais il est également averti que certains agents utilisateurs existants traitent un atsortingbut Domain absent comme si l’atsortingbut Domain était présent et contenait le nom d’hôte actuel (par exemple, si example.com renvoie un en-tête Set-Cookie sans atsortingbut Domain, ces agents utilisateur seront envoyer à tort le cookie à http://www.example.com également).

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

    Donc, par exemple:

    • atsortingbut de cookie Domain=.example.com équivaut à Domain=example.com
    • Les cookies avec de tels atsortingbuts de domaine seront disponibles pour example.com et http://www.example.com
    • les cookies avec de tels atsortingbuts de domaine ne seront pas disponibles pour un autre-exemple.com
    • la spécification d’un atsortingbut de cookie tel que Domain=www.example.com fermera le chemin pour www4.example.com

    PS: la virgule de fin dans l’atsortingbut Domain provoquera que l’agent utilisateur ignore l’atsortingbut = (

    Certaines règles déterminent si un navigateur acceptera l’en-tête de réponse Set-header (écriture de cookie côté serveur), des règles / interprétations légèrement différentes pour les cookies créés avec Javascript (je n’ai pas testé VBScript).

    Il existe ensuite des règles qui déterminent si le navigateur envoie un cookie avec la demande de page.

    Il existe des différences entre les principaux moteurs de navigation en ce qui concerne la gestion des correspondances de domaines et la manière dont les parameters 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 de manière différente

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

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

    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 la 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 http://www.yyy.example.com? Non.

    Un cookie défini par le serveur d’origine http://www.yyy.example.com, avec le domaine .example.com, aura-t-il une valeur envoyée par l’agent utilisateur à xxx.exemple.com? Non.

    Est-ce que www.example.com pourra définir des cookies pour .com ?

    Non, mais example.com.fr peut être en mesure de définir un cookie pour example2.com.fr . Firefox protège contre cela en conservant 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, je suppose, explique pourquoi o2.ie redirige simplement vers o2online.ie . Je me suis souvent demandé ça.