2010-04-05 11 views
9

J'ai une étrange bizarrerie avec des cookies dans IE. Lorsqu'un utilisateur se connecte au site, je génère un nouvel identifiant de session et j'ai donc besoin d'écraser le cookie. Le flux est essentiellement:Cookie ne pas renouveler/écraser dans IE

  1. client va https://secure.example.com/users/login la page, recevant automatiquement un identifiant de session
  2. POSTs client de références de connexion à même adresse
  3. Client reçoit en même temps avec une redirection 302 les en-têtes de cookie mis suivants à https://secure.example.com/users/mypage:

    CAKEPHP = supprimé; expire = dim, 05 avril 2009 04:50:35 GMT; chemin =/
    CAKEPHP = 98hnIO23 ...; expires = Lun, 12 Apr 2010 04:50:36 GMT; chemin = /;

  4. Le client est supposé visiter https://secure.example.com/users/mypage, présentant le nouvel ID de session.

Cela fonctionne dans tous les navigateurs, sauf IE (testé dans 7 & 8). IE conserve l'ancien ID de session non authentifié et est redirigé vers la page de connexion. Cela fonctionne sur mon environnement de test local (en utilisant un certificat auto-signé au https://localhost:8443/...), mais pas sur le serveur live. J'utilise CakePHP et j'émets simplement un $this->Session->renew(), qui produit les en-têtes de cookie ci-dessus.

Des idées comment obtenir IE pour accepter le nouveau cookie?


est ici l'en-tête complet:

HTTP/1.0 302 Moved Temporarily 
Date: Thu, 08 Apr 2010 02:54:30 GMT 
Server: Apache 
Expires: Mon, 26 Jul 1997 05:00:00 GMT 
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 
Pragma: no-cache 
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM" 
Set-Cookie: CAKEPHP=deleted; expires=Wed, 08-Apr-2009 02:54:30 GMT; path=/ 
Set-Cookie: CAKEPHP=d55c...; expires=Thu, 15 Apr 2010 02:54:31 GMT; path=/; secure 
Last-Modified: Thu, 08 Apr 2010 02:54:30 GMT 
Location: https://secure.example.com/users/mypage 
Vary: Accept-Encoding 
Content-Length: 0 
Connection: close 
Content-Type: text/html; charset=utf-8 

Je crois avoir trouvé le problème: IE envoie deux les cookies de nom identique. Voici la prochaine requête au serveur:

GET /users/mypage HTTP/1.1 
Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/x-silverlight, */ * 
Referer: https://secure.example.com/users/login 
Accept-Language: en-gb 
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322) 
Accept-Encoding: gzip, deflate 
Host: secure.example.com 
Connection: Keep-Alive 
Cache-Control: no-cache 
Cookie: CAKEPHP=19c6...; CAKEPHP=d55c... 

avis qu'il envoie deux cookies, celui qu'il a reçu après la connexion, mais aussi l'ancien. Il a reçu l'ancien à la page principale example.com, réglé avec path=/. Il l'envoie également pour les demandes au secure.example.com. Il n'est pas remplacé par l'en-tête ci-dessus, mais l'ajoute en tant que cookie supplémentaire. Comment puis-je l'empêcher de faire ça?

+0

Peut-être essayer de supprimer spécifiquement l'ancien cookie avant de créer le nouveau? –

+0

@David Je pensais que c'était ce que je faisais. Sinon, comment pourrais-je faire cela dans le même en-tête? – deceze

Répondre

3

Assurez-vous que les cookies sont émis pour votre domaine de base.

C'est probablement le problème, car ce comportement varie certainement selon les navigateurs.

Je ne l'ai pas fait dans CakePHP, mais this should work

+0

Oui, c'était le problème. J'ai ajouté 'ini_set ('session.cookie_domain', '.example.com')' via la méthode liée. Merci! – deceze

+2

Le lien est mort! –

4

Un problème courant est que la deuxième tentative pour définir le cookie manque d'un en-tête P3P approprié et donc la tentative de toucher le cookie est ignorée.

Il serait utile si vous les en-têtes de courant du flux global (par exemple utiliser Fiddler pour capturer et regarder)

+0

Après avoir tripoté Fiddler, je pense que j'ai trouvé la racine du problème, jetez un oeil à la question. – deceze

+2

Le problème typique lorsque vous avez deux cookies du même nom est que vous définissez le même cookie avec deux attributs PATH différents, ou que vous définissez le même cookie avec deux attributs DOMAIN différents. Ce dernier se produit souvent lorsqu'un utilisateur visite votre site sous la forme //example.com et revient ensuite sur //www.example.com. Si votre site ne prend pas soin de toujours rediriger vers www.example.com sans définir de cookie, vous en finissez avec deux. En raison de la nature de l'héritage des cookies, les deux sont envoyés lorsque vous visitez www.example.com. Le moyen le plus simple de vérifier? Visitez //example.com et vérifiez! – EricLaw

+0

En lisant votre question de plus près, il me semble que vous savez déjà que c'est le problème. Pour résoudre ce problème, ajoutez l'attribut DOMAIN = example.com à tous vos en-têtes de réponse SET-COOKIE. – EricLaw

2

Vous pourriez avoir deux problèmes ici.Tout d'abord, donnez le lien @ freddy-rios en train de poster un coup de feu. Si cela ne fonctionne pas, vous risquez de rencontrer l'erreur "cookie de redirection IE".

IE n'honore pas toujours les modifications apportées aux cookies lors de la redirection. Si vous affectez un ID de session sur le formulaire de connexion et que vous ne le modifiez pas, la redirection devrait fonctionner correctement. Si vous modifiez un cookie en redirection, alors vous finirez probablement avec l'ancienne session ... le navigateur soumettra simplement l'ancien cookie à la nouvelle URL (sans doute, ce qu'il est censé faire ... rediriger la requête d'origine).

Il existe une poignée de façons de gérer cela. Le plus laid, de loin, est d'utiliser une redirection de balises Javascript ou META. Tant que vous passez un non-300 avec ces cookies, le navigateur les acceptera presque toujours. Si vous utilisez $this->Session->renew(), il vous suffit de le supprimer pour résoudre tous vos problèmes ... surtout s'il appelle session_regenerate_id() sous le capot.

Je suggère de supprimer la redirection et voir si c'est toujours un problème. Si c'est le cas, alors vous pouvez ignorer tout ce que j'ai dit. :)