Réponses:
La spécification de cookie actuelle est la RFC 6265 , qui remplace la RFC 2109 et la RFC 2965 (les deux RFC sont désormais marquées comme "historiques") et formalise la syntaxe pour les utilisations réelles des cookies. Il indique clairement:
- introduction
...
Pour des raisons historiques, les cookies contiennent un certain nombre de problèmes de sécurité et de confidentialité. Par exemple, un serveur peut indiquer qu'un cookie donné est destiné à des connexions "sécurisées", mais l'attribut Secure ne fournit pas d'intégrité en présence d'un attaquant réseau actif. De même, les cookies pour un hôte donné sont partagés entre tous les ports de cet hôte, même si la «politique d'origine identique» utilisée par les navigateurs Web isole le contenu récupéré via différents ports.
Et aussi:
8.5. Faible confidentialité
Les cookies n'offrent pas d'isolement par port . Si un cookie est lisible par un service s'exécutant sur un port, le cookie est également lisible par un service s'exécutant sur un autre port du même serveur. Si un cookie est accessible en écriture par un service sur un port, le cookie est également accessible en écriture par un service exécuté sur un autre port du même serveur. Pour cette raison, les serveurs NE DEVRAIENT PAS à la fois exécuter des services se méfiant mutuellement sur différents ports du même hôte et utiliser des cookies pour stocker des informations sensibles pour la sécurité.
Selon la RFC2965 3.3.1 (qui peut ou non être suivie par les navigateurs), à moins que le port ne soit explicitement spécifié via le portparamètre de l'en- Set-Cookietête, les cookies peuvent ou non être envoyés à n'importe quel port.
Le manuel de sécurité du navigateur de Google indique: par défaut, la portée des cookies est limitée à toutes les URL du nom d'hôte actuel - et n'est pas liée aux informations de port ou de protocole. et quelques lignes plus tard Il n'y a aucun moyen de limiter les cookies à un seul nom DNS uniquement [...] de même, il n'y a aucun moyen de les limiter à un port spécifique. ( De plus, gardez à l' esprit que IE ne les numéros de port de facteurs ne sont pas dans sa politique d'origine du tout .)
Il ne semble donc pas sûr de s'appuyer sur un comportement bien défini ici.
C'est une très vieille question, mais j'ai pensé ajouter une solution de contournement que j'ai utilisée.
J'ai deux services en cours d'exécution sur mon ordinateur portable (un sur le port 3000 et l'autre sur 4000). Lorsque je sautais entre ( http://localhost:3000et http://localhost:4000), Chrome passait dans le même cookie, chaque service ne comprenait pas le cookie et n'en générait pas un nouveau.
J'ai constaté que si j'y accédais http://localhost:3000et http://127.0.0.1:4000, le problème disparaissait puisque Chrome conservait un cookie pour localhost et un pour 127.0.0.1.
Encore une fois, personne ne s'en soucie peut-être à ce stade, mais cela a été facile et utile à ma situation.
localhostne peut pas être partagé avec 127.0.0.1et vice versa. Mais les cookies sur le même hôte / domaine, quel que soit le port, peuvent être partagés.
Il s'agit d'une grande zone grise dans le cookie SOP (même politique d'origine).
Théoriquement, vous pouvez spécifier le numéro de port dans le domaine et le cookie ne sera pas partagé. En pratique, cela ne fonctionne pas avec plusieurs navigateurs et vous rencontrerez d'autres problèmes. Cela n'est donc possible que si vos sites ne sont pas destinés au grand public et que vous pouvez contrôler les navigateurs à utiliser.
La meilleure approche consiste à obtenir 2 noms de domaine pour la même IP et à ne pas compter sur les numéros de port pour les cookies.
Une autre façon de contourner le problème est de faire en sorte que le nom du cookie de session soit lié au port. Par exemple:
Votre code pourrait accéder à la configuration du serveur Web pour savoir quel port votre serveur utilise et nommer le cookie en conséquence.
Gardez à l'esprit que votre application recevra les deux cookies, et vous devez demander celui qui correspond à votre port.
Il n'est pas nécessaire d'avoir le numéro de port exact dans le nom du cookie, mais c'est plus pratique.
En général, le nom du cookie peut coder tout autre paramètre spécifique à l'instance de serveur que vous utilisez, il peut donc être décodé par le bon contexte.
Je rencontrais un problème similaire en exécutant (et en essayant de déboguer) deux applications Django différentes sur la même machine.
Je les exécutais avec ces commandes:
./manage.py runserver 8000
./manage.py runserver 8001
Lorsque je me suis connecté dans le premier, puis dans le second, je me suis toujours déconnecté du premier et vice-versa.
J'ai ajouté ceci sur mon / etc / hosts
127.0.0.1 app1
127.0.0.1 app2
Ensuite, j'ai démarré les deux applications avec ces commandes:
./manage.py runserver app1:8000
./manage.py runserver app2:8001
Problème résolu :)
127.0.0.1:8000pour un, localhost:8000pour une seconde, et peut-être ::1:8000(peut-être [::1]:8080) pour un troisième sans jamais avoir à toucher le fichier hosts.
::1 app1 app2 app3 app4 app5 appN
C'est facultatif.
Le port peut être spécifié afin que les cookies puissent être spécifiques au port. Ce n'est pas nécessaire, le serveur / l'application Web doit s'en occuper.
Source: article Wikipedia allemand , RFC2109 , chapitre 4.3.1
Portparamètre dans l'en-Set-Cookietête (car presque personne ne l'a réellement utilisé dans la pratique), et rend très explicite que les cookies sur le même hôte NE SONT PLUS différenciables par les ports.