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:
.example.com
sera-t-il disponible pour www.example.com
? .example.com
sera-t-il disponible pour example.com
? example.com
sera-t-il disponible pour www.example.com
? example.com
sera-t-il disponible pour anotherexample.com
? www.example.com
pourra définir des cookies pour example.com
? www.example.com
pourra définir des cookies pour www2.example.com
? www.example.com
pourra définir des cookies pour .com
? Ajouté 2:
En outre, quelqu’un pourrait-il suggérer comment définir un cookie pour que:
www.example.com
ou example.com
; 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:
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:
Domain=.example.com
sera disponible pour http://www.example.com Domain=.example.com
sera disponible pour example.com Domain=example.com
sera converti en .example.com
et sera donc également disponible pour http://www.example.com Domain=example.com
ne sera pas disponible pour anotherexample.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,
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. 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:
*
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:
Domain=.example.com
équivaut à Domain=example.com
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.