Partager le cookie entre le sous-domaine et le domaine

J'ai deux questions. Je comprends que si je spécifie le domaine comme .mydomain.com(avec le premier point) dans le cookie, tous les sous-domaines peuvent partager un cookie.

Peut subdomain.mydomain.comaccéder à un cookie créé dans mydomain.com(sans le wwwsous - domaine)?

Peut mydomain.com(sans le wwwsous - domaine) accéder au cookie s'il est créé en subdomain.mydomain.com?

Les 2 domaines mydomain.comet subdomain.mydomain.comne peuvent partager des cookies que si le domaine est explicitement nommé dans l'en- Set-Cookietête. Sinon, la portée du cookie est limitée à l'hôte de la demande. (Il s'agit d'un "cookie d'hôte uniquement". Voir Qu'est-ce qu'un cookie d'hôte uniquement? )

Par exemple, si vous avez envoyé l'en-tête suivant subdomain.mydomain.com, le cookie ne sera pas envoyé pour les demandes à mydomain.com:

Set-Cookie: name=value

Cependant, si vous utilisez ce qui suit, il sera utilisable sur les deux domaines:

Set-Cookie: name=value; domain=mydomain.com

Ce cookie sera envoyé pour tout sous-domaine de mydomain.com, y compris les sous-domaines imbriqués comme subsub.subdomain.mydomain.com.

Dans la RFC 2109 , un domaine sans point de tête signifiait qu'il ne pouvait pas être utilisé sur des sous-domaines, et seul un point de tête ( .mydomain.com) lui permettrait d'être utilisé sur plusieurs sous-domaines (mais pas le domaine de niveau supérieur, donc ce que vous demandez était pas possible dans l'ancienne spécification).

Cependant, tous les navigateurs modernes respectent la nouvelle spécification RFC 6265 et ignoreront tout point de tête, ce qui signifie que vous pouvez utiliser le cookie sur les sous-domaines ainsi que le domaine de premier niveau.

En résumé, si vous définissez un cookie comme le deuxième exemple ci-dessus mydomain.com, il serait accessible par subdomain.mydomain.com, et vice versa. Cela peut également être utilisé pour autoriser sub1.mydomain.comet sub2.mydomain.compartager des cookies.

Voir également:

• www vs no-www et cookies
• cookies test de script pour l'essayer

Je ne suis pas sûr que la réponse @cmbuckley montre l'image complète. Ce que je lis c'est:

Sauf indication contraire des attributs du cookie, le cookie est renvoyé uniquement au serveur d'origine (et non, par exemple, à des sous-domaines), et il expire à la fin de la session en cours (tel que défini par l'agent utilisateur). Les agents utilisateurs ignorent les cookies non reconnus.

RFC 6265

Aussi

8.6.  Weak Integrity

   Cookies do not provide integrity guarantees for sibling domains (and
   their subdomains).  For example, consider foo.example.com and
   bar.example.com.  The foo.example.com server can set a cookie with a
   Domain attribute of "example.com" (possibly overwriting an existing
   "example.com" cookie set by bar.example.com), and the user agent will
   include that cookie in HTTP requests to bar.example.com.  In the
   worst case, bar.example.com will be unable to distinguish this cookie
   from a cookie it set itself.  The foo.example.com server might be
   able to leverage this ability to mount an attack against
   bar.example.com.

Pour moi, cela signifie que vous pouvez protéger les cookies contre la lecture par sous-domaine / domaine mais ne pouvez pas empêcher l'écriture de cookies dans les autres domaines. Ainsi, quelqu'un peut réécrire les cookies de votre site en contrôlant un autre sous-domaine visité par le même navigateur. Ce qui pourrait ne pas être une grande préoccupation.

Site de test de cookies génial fourni par @cmbuckley / pour ceux qui l'ont manqué dans sa réponse comme moi; vaut la peine de faire défiler et de voter /:

• http://scripts.cmbuckley.co.uk/cookies.php

Voici un exemple utilisant l'API de cookie DOM ( https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie ), afin que nous puissions voir par nous-mêmes le comportement.

Si nous exécutons le JavaScript suivant:

document.cookie = "key = value"

Il semble être identique à l'exécution:

document.cookie = "key = value; domain = mydomain.com"

La clé de cookie devient disponible (uniquement) sur le domaine mydomain.com .

Maintenant, si vous exécutez le JavaScript suivant sur mydomain.com:

document.cookie = "key = value; domain = .mydomain.com"

La clé de cookie devient disponible pour mydomain.com ainsi que subdomain.mydomain.com .

Enfin, si vous deviez essayer d'exécuter ce qui suit sur subdomain.mydomain.com:

document.cookie = "key = value; domain = .mydomain.com"

La clé de cookie est-elle disponible sur subdomain.mydomain.com ? J'ai été un peu surpris que cela soit permis; J'avais supposé que ce serait une violation de la sécurité pour un sous-domaine de pouvoir définir un cookie sur un domaine parent.

Veuillez noter que vous pouvez définir un cookie à partir d'un sous-domaine sur un domaine.

(envoyé dans la réponse pour la demande subdomain.mydomain.com)

Set-Cookie: name=value; Domain=mydomain.com // GOOD

Mais vous NE POUVEZ PAS définir un cookie à partir d'un domaine sur un sous-domaine.

(envoyé dans la réponse pour la demande mydomain.com)

Set-Cookie: name=value; Domain=subdomain.mydomain.com // Browser rejects cookie

POURQUOI ?

Selon les spécifications RFC 6265 section 5.3.6 Modèle de stockage

Si l'hôte de requête canonisé ne correspond pas au domaine de l'attribut de domaine: ignorez complètement le cookie et abandonnez ces étapes.

et RFC 6265 section 5.1.3 Correspondance de domaine

Correspondance de domaine

Une chaîne de domaine correspond à une chaîne de domaine donnée si au moins une des conditions suivantes est remplie:

1. La chaîne de domaine et la chaîne sont identiques. (Notez que la chaîne de domaine et la chaîne auront été canonisées en minuscules à ce stade.)

2. Toutes les conditions suivantes s'appliquent:

   • La chaîne de domaine est un suffixe de la chaîne.

   • Le dernier caractère de la chaîne qui n'est pas inclus dans la chaîne de domaine est un caractère% x2E (".").

   • La chaîne est un nom d'hôte (c'est-à-dire pas une adresse IP).

Ainsi, le domaine "subdomain.mydomain.com" correspond à "mydomain.com", mais "mydomain.com" ne correspond pas au domaine "subdomain.mydomain.com".

Vérifiez également cette réponse .

Dans les deux cas, c'est possible, et c'est le comportement par défaut pour IE et Edge.

Les autres réponses apportent des informations précieuses, mais décrivent principalement le comportement dans Chrome. il est important de noter que le comportement est complètement différent dans IE. Le script de test très utile de CMBuckley démontre que dans (disons) Chrome, les cookies ne sont pas partagés entre la racine et les sous-domaines quand aucun domaine n'est spécifié. Cependant, le même test dans IE montre qu'ils sont partagés. Ce cas IE est plus proche de la description à retenir dans le lien www-or-not-www de CMBuckley. Je sais que c'est le cas parce que nous avons un système qui utilise différents cookies de pile de service sur la racine et le sous-domaine. Tout a bien fonctionné jusqu'à ce que quelqu'un y accède dans IE et que les deux systèmes se disputent le cookie de session qui gagnerait jusqu'à ce que nous fassions exploser le cache.

Soyez prudent si vous travaillez sur localhost! Si vous stockez votre cookie dans js comme ceci:

document.cookie = "key=value;domain=localhost"

Il pourrait ne pas être accessible à votre sous-domaine, comme sub.localhost. Pour résoudre ce problème, vous devez utiliser l' hôte virtuel . Par exemple, vous pouvez configurer votre hôte virtuel avec ServerName localhost.comensuite vous pourrez stocker votre cookie sur votre domaine et sous-domaine comme ceci:

document.cookie = "key=value;domain=localhost.com"

Solution simple

setcookie("NAME", "VALUE", time()+3600, '/', EXAMPLE.COM);

Le 5ème paramètre de Setcookie détermine les (sous) domaines auxquels le cookie est disponible. Le paramétrer sur (EXAMPLE.COM) le rend disponible pour tout sous-domaine (par exemple: SUBDOMAIN.EXAMPLE.COM)

Référence: http://php.net/manual/en/function.setcookie.php