2009-08-08 2 views
2

J'ai un système qui génère un cookie en PHP, puis doit le supprimer de l'ASP classique. Ceci est une boîte de dev-quick-and-dirty, juste une machine XP de rechange exécutant IIS5, PHP5 et ASP3. J'ai utilisé le fichier hosts pour créer un faux nom de domaine (www.localtest.com) car d'autres parties du processus ne fonctionneraient pas avec localhost.Le cookie unkillable (ASP3, PHP5, IIS5, FF3.5, IE8)

Le fichier PHP se trouve dans un sous-répertoire de la racine du site, mais le domaine du cookie est .localtest.com et le chemin est root (/). Le nom du cookie est "authkey" et la valeur est un hashcode de 32 octets.

Le fichier ASP est dans la racine du site (pour l'instant). Il peut lire le cookie juste après que PHP l'ait créé, mais peu importe ce que j'essaie, je ne peux pas sembler changer le cookie du tout ASP - cela ne changera pas la valeur, encore moins changera l'expiration. Tous les deux Firefox 3.5 et IE 8 ignorent chaque tentative que j'ai faite (les chiffres que quand ils sont finalement d'accord sur quelque chose, ce serait ceci). J'ai essayé beaucoup, beaucoup de variations - en définissant juste l'expiration (à une grande variété de valeurs dans divers formats), en réglant tous les paramètres pour correspondre exactement au cookie excepté l'expiration, en utilisant Response.AddHeader pour émettre un Set- En-tête de cookie avec toutes ces variations, en définissant la valeur à false, puis finalement juste une tentative de changer la valeur à une autre chaîne, qui a échoué.

Que diable se passe-t-il? Est-ce un effet secondaire ASP de courir avec un "faux" domaine? J'ai développé cette façon pendant 10+ ans sans voir ASP avoir des problèmes avec un domaine spécifié par les hôtes, bien que je n'ai jamais eu l'occasion de supprimer un cookie (curieusement).

Je suis particulièrement surpris que je ne puisse même pas définir la valeur.

+1

joli titre; sonne comme un film horreur des années 80 hah –

+1

mon intuition serait que le nom ne correspond pas exactement, mais c'est difficile à dire. Je ne pense pas que ce soit un problème avec ASP et les domaines spécifiés par les hôtes. Faites-nous savoir si vous le résoudre. – Cahlroisse

Répondre

0

Bizarre.

Le problème était le premier point dans le nom de domaine. Puisque mon site n'utilise pas de sous-domaines, je n'en ai pas vraiment besoin - mais apparemment, si ce point est là, les navigateurs ne supprimeront pas ou ne changeront pas le cookie. Je me demande si c'est un nouveau comportement puisque je sais que beaucoup de systèmes s'appuient sur cela pour faire des cookies sous-domaine-neutres (tels que phpBB).

Aussi, pour supprimer le cookie, j'ai dû tout spécifier - domaine, chemin et date, mais je pense que c'est en fait par le RFC, donc je ne suis pas trop inquiet à ce sujet.

+0

La ligne de domaine devrait juste être "localtest.com" - pas de point principal. Je suppose que PHP le corrigeait pour vous - mais Fiddler vous le dira à coup sûr. –

+0

PHP ne l'enlève pas, et c'est une syntaxe valide. Un point de tête crée un cookie accessible dans tous les sous-domaines. Selon le RFC (http://www.ietf.org/rfc/rfc2109.txt), "Un domaine explicitement spécifié doit toujours commencer par un point." – McGuireV10

+0

@ MV10 - Vous avez raison - c'est ce que dit le RFC. J'ai raté ça, car aucun navigateur ne s'en soucie. http://blogs.msdn.com/ieinternals/archive/2009/08/20/WinINET-IE-Cookie-Internals-FAQ.aspx –

2

Utilisez Fiddler ou similaire pour voir le trafic HTTP réel - la technologie du serveur ne devrait pas importer, tant que les bons en-têtes HTTP sont envoyés. Vraisemblablement, ils ne le sont pas, mais vous ne le saurez pas à moins de regarder le flux HTTP.

(Normalement, je vous recommande Wireshark, mais cela ne fonctionne pas lorsque le client et le serveur sont sur la même machine.)

+0

Cool, merci, j'ai cherché quelque chose comme Fiddler. – McGuireV10

+0

Les en-têtes ont l'air complètement normaux. Fiddler montre: Set-Cookie: authkey =; expire = Sat, 01-May-1999 04:00:00 GMT; chemin =/ Cela utilise cette ligne de script dans ASP: Response.Cookies ("authkey"). Expires = #May 1, 1999 # – McGuireV10

+0

(Hmm ... pas de lignes vides dans les réponses, je suppose?) – McGuireV10