Cookies sur localhost avec Domaine explicite
je dois manquer quelque chose à propos des cookies. Sur localhost, lorsque je mets un cookie côté serveur et , spécifiez le domaine explicitement comme localhost (or .localhost). le cookie ne semble pas être acceptée par certains navigateurs.
Firefox 3.5: j'ai vérifié la requête HTTP dans Firebug. Ce que je vois c'est:
Set-Cookie:
name=value;
domain=localhost;
expires=Thu, 16-Jul-2009 21:25:05 GMT;
path=/
ou (lorsque j'ai mis le domaine .localhost):
Set-Cookie:
name=value;
domain=.localhost;
expires=Thu, 16-Jul-2009 21:25:05 GMT;
path=/
Dans les deux cas, le cookie n'est pas stocké.
IE8: Je n'ai pas utilisé d'outil supplémentaire, mais le cookie ne semble pas être stocké aussi bien, parce qu'il n'est pas envoyé dans des requêtes ultérieures.
Opera 9.64: les Deux localhost et .localhost fonctionne , mais quand je vérifie la liste des cookies dans les préférences, le domaine est défini à localhost.locaux, même s'il est répertorié sous localhost (dans le groupe de liste).
Safari 4: les deux localhost et .localhost travailler , mais ils sont toujours répertoriés sous .localhost dans Préférences. D'un autre côté, un cookie Sans domaine explicite, il est affiché comme localhost (pas de point).
Quel est le problème avec localhost? En raison d'un tel nombre d'incohérences, il doit y avoir des règles spéciales impliquant localhost. Aussi, il n'est pas complètement clair pour moi pourquoi domaines doivent être préfixés par un point? La RFC 2109 stipule explicitement que:
, La valeur de l'attribut de Domaine contient pas intégré de points ou de ne pas commencer par un point.
pourquoi? Le document indique qu'il doit faire quelque chose avec la sécurité. Je dois admettre que je n'ai pas lu toute la spécification (peut-être plus tard), mais cela semble un peu étrange. Basé sur ceci, le réglage des cookies sur localhost serait impossible.
15 réponses
de par leur conception, les noms de domaine doivent comporter au moins deux points; dans le cas contraire, le navigateur les considérera comme invalides. (Voir référence sur http://curl.haxx.se/rfc/cookie_spec.html )
lorsque vous travaillez sur localhost , le domaine des cookies doit être entièrement omis. Il ne suffit pas de régler "" ou NULL ou FALSE au lieu de "localhost" .
pour PHP, voir les commentaires sur http://php.net/manual/en/function.setcookie.php#73107 .
si vous travaillez avec L'API Java Servlet, n'appelez pas du tout la méthode cookie.setDomain("...") .
je suis largement d'accord avec @Ralph Buchfelder, Mais voici une certaine amplification de ceci, par expérience en essayant de répliquer un système avec plusieurs sous-domaines (tels que example.com, fr.example.com, de.example.com) sur ma machine locale (OS X / Apache|Chrome / Firefox).
j'ai édité / etc / hosts pour pointer quelques sous-domaines imaginaires à 127.0.0.1:
127.0.0.1 localexample.com
127.0.0.1 fr.localexample.com
127.0.0.1 de.localexample.com
Si je suis en train de travailler sur fr.localexample.com et je laisse le paramètre de domaine, l' cookie est stocké correctement pour fr.localexample.com mais n'est pas visible dans les autres sous-domaines.
Si j'utilise un domaine ".localexample.com", le cookie est stocké correctement pour fr.localexample.com et est visible dans d'autres sous-domaines.
Si j'utilise un domaine "localexample.com" ou quand j'ai essayé un domaine de "localexample" ou "localhost", le cookie n'est pas être stocké.
si j'utilise un domaine de "fr.localexample.com " ou".fr.localexample.com", le cookie est stocké correctement pour fr.localexample.com et est (correctement) invisible dans d'autres sous-domaines.
donc l'exigence que vous ayez besoin d'au moins deux points dans le domaine semble correcte, même si Je ne vois pas pourquoi cela devrait l'être.
Si quelqu'un veut essayer, voici quelques code:
<html>
<head>
<title>
Testing cookies
</title>
</head>
<body>
<?php
header('HTTP/1.0 200');
$domain = 'fr.localexample.com'; // Change this to the domain you want to test.
if (!empty($_GET['v'])) {
$val = $_GET['v'];
print "Setting cookie to $val<br/>";
setcookie("mycookie", $val, time() + 48 * 3600, '/', $domain);
}
print "<pre>";
print "Cookie:<br/>";
var_dump($_COOKIE);
print "Server:<br/>";
var_dump($_SERVER);
print "</pre>";
?>
</body>
</html>
localhost: Vous pouvez utiliser: domain: ".app.localhost" et cela fonctionnera. Le paramètre "domaine" nécessite un ou plusieurs points dans le nom de domaine pour configurer les cookies. Ensuite, vous pouvez avoir des sessions de travail à travers les sous-domaines localhost tels que: api.app.localhost:3000 .
Lorsqu'un cookie est installé avec un domaine explicite de "localhost" comme suit...
Set-Cookie: nom=valeur; domain=localhost ; expires= Thu, 16-Jul-2009 21:25: 05 GMT; path = /
...puis les navigateurs l'ignorent car il ne comprend pas au moins deux périodes et n'est pas l'un des sept domaines de premier niveau spécialement manipulés .
...domaines doivent avoir au moins deux (2) ou trois (3) périodes de empêcher les domaines de la forme:".com", ".edu", et " va.nous". N'importe quel domaine qui échoue dans l'un des sept domaines spéciaux de premier niveau énumérés ci-dessous ne nécessitent que deux périodes. Tout autre domaine nécessite au moins trois. Les sept domaines spéciaux de premier niveau sont: "COM", "EDU", " NET", "ORG", "GOV", "MIL", et "INT".
noter que le nombre de périodes ci-dessus suppose probablement qu'un dirigeant la période est nécessaire. Cette période est cependant ignoré dans les navigateurs modernes et il devrait probablement lire...
au moins un (1) ou deux (2) périodes
notez que la valeur par défaut pour l'attribut de domaine est le nom d'hôte du serveur qui a généré la réponse de cookie .
So une solution de contournement pour les cookies pas être défini pour localhost est tout simplement de ne pas spécifier un attribut de domaine et de laisser le navigateur utiliser la valeur par défaut - cela ne semble pas avoir les mêmes contraintes qu'une valeur explicite dans l'attribut de domaine.
a passé beaucoup de temps à résoudre ce problème moi-même.
en utilisant PHP, et rien sur cette page n'a fonctionné pour moi. J'ai finalement réalisé dans mon code que le paramètre' secure ' de de PHP, session_set_cookie_params() était toujours défini à TRUE.
comme je ne visitais pas localhost avec https, mon navigateur n'accepterait jamais le cookie. Donc, j'ai modifié cette partie de mon code pour définir conditionnellement le "Sécurisé" param basé sur $_SERVER['HTTP_HOST'] étant 'localhost' ou non. Fonctionne bien maintenant.
j'espère que cela aidera quelqu'un.
j'ai eu beaucoup plus de chance de tester localement en utilisant 127.0.0.1 comme domaine. Je ne sais pas pourquoi, mais j'ai eu des résultats mitigés avec localhost et .localhost, etc.
aucun des correctifs suggérés n'a fonctionné pour moi - le paramétrage à nul, faux, ajout de deux points, etc-n'a pas fonctionné.
à la fin, je viens de supprimer le domaine du cookie si c'est localhost et qui fonctionne maintenant pour moi dans Chrome 38 .
code précédent (n'a pas fonctionné):
document.cookie = encodeURI(key) + '=' + encodeURI(value) + ';domain=.' + document.domain + ';path=/;';
nouveau code (maintenant actif):
if(document.domain === 'localhost') {
document.cookie = encodeURI(key) + '=' + encodeURI(value) + ';path=/;' ;
} else {
document.cookie = encodeURI(key) + '=' + encodeURI(value) + ';domain=.' + document.domain + ';path=/;';
}
document.cookie = valuename + "=" + valeur + "; " + expire + ";domain=;path=/";
ce "domaine=;path=/"; prendra de domaine dynamique que son cookie de travail en sous-domaine. si vous voulez tester en localhost il fonctionnera
aucune des réponses ici n'a fonctionné pour moi. Je l'ai corrigé en mettant mon PHP comme la toute première chose dans la page.
comme les autres en-têtes, les cookies doivent être envoyés avant toute sortie de votre script (ceci est une restriction de protocole). Cela vous impose d'appeler cette fonction avant toute sortie, y compris et les balises ainsi que n'importe quel espace.
il y a un problème sur Chromium open depuis 2011 , que si vous définissez explicitement le domaine comme" localhost", vous devriez le Définir comme false ou undefined .
je jouais un peu.
Set-Cookie: _xsrf=2|f1313120|17df429d33515874d3e571d1c5ee2677|1485812120; Domain=localhost; Path=/
fonctionne dans Firefox et Chrome à partir d'aujourd'hui. Cependant, je n'ai pas trouver un moyen de le faire fonctionner avec curl. J'ai essayé Host-Header et --resolve, pas de chance, toute aide appréciée.
cependant, il fonctionne en boucle, si je mets à
Set-Cookie: _xsrf=2|f1313120|17df429d33515874d3e571d1c5ee2677|1485812120; Domain=127.0.0.1; Path=/
à la place. (Qui ne fonctionne pas avec Firefox.)
autre détail important, le expires= devrait utiliser le format date time suivant: Wdy, JJ-Lun-YYY HH:MM:SS GMT ( RFC6265 - Section 4.1.1 ).
Set-Cookie:
name=value;
domain=localhost;
expires=Thu, 16-07-2019 21:25:05 GMT;
path=/
j'ai eu le même problème et je l'ai corrigé en mettant 2 points dans le nom du cookie lui-même sans spécifier de domaine.
set-cookie: name.s1.s2=value; path=/; expires=Sun, 12 Aug 2018 14:28:43 GMT; HttpOnly
Il semble y avoir un problème lorsque vous utilisez https://<local-domain> puis http://<local-domain> . Le site http:// n'envoie pas de cookies avec des requêtes après que le site https:// les ait paramétrées. Recharger de Force et vider la cache n'aide pas. Seul le nettoyage manuel des cookies fonctionne. Aussi, si je les efface sur la page https:// , alors la page http:// recommence à fonctionner.
semble lié à"cookies strictement sécurisés". Bonne explication ici . Il a été publié dans Chrome 58 le 2017-04-19.
il semble que Chrome enregistre en fait à la fois les cookies sécurisés et les cookies non sécurisés car il affichera les cookies corrects en fonction du protocole de la page en cliquant sur l'icône de barre d'adresse.
mais Developer tools > Application > Cookies n'affichera pas de cookie non sécurisé lorsqu'il y a un cookie sécurisé du même nom pour le même domaine, ni n'enverra le cookie non sécurisé avec aucune demande. Ce semble comme un bug Chrome, ou si ce comportement est prévu, il devrait y avoir un moyen de voir les cookies sécurisés lorsque sur une page http et une indication qu'ils sont dépassés.
solution est d'utiliser des cookies nommés différents selon qu'ils sont pour un site http ou un site https, et de les nommer spécifiques à votre application. Un préfixe __Secure- indique que le cookie doit être strictement sécurisé, et est également une bonne pratique car sécurisé et non sécurisé ne sera pas collision. Il y a autres prestations aussi préfixer.
utiliser des domaines différents /etc/hosts pour l'accès https vs. l'accès http fonctionnerait aussi, mais une visite accidentelle https://localhost empêchera les cookies des mêmes noms de fonctionner sur les sites http://localhost - ce n'est donc pas une bonne solution.
j'ai déposé un rapport de bogue Chrome .