J'ai deux services HTTP exécutés sur une seule machine. Je veux juste savoir s'ils partagent leurs cookies ou si le navigateur fait la distinction entre les deux sockets serveur.
355
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.
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.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:3000ethttp://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:3000ethttp://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.
la source
localhostne peut pas être partagé avec127.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.
la source
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.
la source
Dans IE 8, les cookies (vérifiés uniquement par rapport à localhost) sont partagés entre les ports. En FF 10, ils ne le sont pas.
J'ai publié cette réponse afin que les lecteurs aient au moins une option concrète pour tester chaque scénario.
la source
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:
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
Ensuite, j'ai démarré les deux applications avec ces commandes:
Problème résolu :)
la source
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 appNC'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
la source