2010-04-05 14 views
9

Ho uno strano capriccio con i cookie in IE. Quando un utente accede al sito, sto generando un nuovo ID di sessione e quindi è necessario sovrascrivere il cookie. Il flusso è fondamentalmente:Cookie non si rinnova/sovrascrive in IE

  1. client va a https://secure.example.com/users/login pagina, ricevere automaticamente un ID di sessione
  2. POST client credenziali di accesso allo stesso indirizzo
  3. cliente riceve le seguenti intestazioni Set-Cookie insieme ad un reindirizzamento 302 per https://secure.example.com/users/mypage:

    CAKEPHP = cancellato; scade = Dom, 05-Apr-2009 04:50:35 GMT; percorso =/
    CAKEPHP = 98hnIO23 ...; scade = Lun, 12 Apr 2010 04:50:36 GMT; percorso = /; garantire

  4. client dovrebbe visitare https://secure.example.com/users/mypage, presentando il nuovo id di sessione.

Questo funziona in tutti i browser, ad eccezione di IE (testate in 7 & 8). IE mantiene il vecchio ID di sessione non autenticato e viene reindirizzato alla pagina di accesso. Funziona sul mio ambiente di test locale (utilizzando un certificato autofirmato allo https://localhost:8443/...), ma non sul server live.

Sto usando CakePHP e semplicemente emetto un $this->Session->renew(), che produce le intestazioni dei cookie sopra.

Qualche idea su come ottenere IE per accettare il nuovo cookie?


Ecco l'intestazione completa:

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 

Credo di aver trovato il problema: IE sta inviando due cookie di nome identico. Ecco la prossima richiesta al server:

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... 

noti che invia due biscotti, quella che ha ricevuto dopo l'accesso, ma anche quello vecchio. Ha ricevuto il vecchio nella pagina principale example.com, impostato con path=/. Lo invia anche per richieste a secure.example.com. Non viene sostituito dall'intestazione precedente, ma lo aggiunge come cookie aggiuntivo. Come posso impedirgli di farlo?

+0

Forse provare ad eliminare in modo specifico il vecchio cookie prima di crearne uno nuovo? –

+0

@David Ho pensato che è quello che sto facendo. In quale altro modo dovrei farlo nella stessa intestazione? – deceze

risposta

3

Assicurarsi che i cookie vengono emessi per il tuo dominio di base.

Questo è probabilmente il problema, poiché questo comportamento varia sicuramente nei vari browser.

non l'ho fatto in CakePHP, ma this should work

+0

Sì, quello era il problema. Ho aggiunto 'ini_set ('session.cookie_domain', '.example.com')' tramite il metodo collegato. Grazie! – deceze

+2

Il link è morto! –

4

Un problema comune è che al secondo tentativo di impostare il cookie manca un'appropriata intestazione P3P e quindi il tentativo di toccare il cookie viene ignorato.

Sarebbe utile se hai postato le intestazioni del flusso complessivo (ad esempio utilizzare Fiddler per catturare e osservare)

+0

Dopo aver giocato con Fiddler penso di aver trovato la radice del problema, per favore guarda di nuovo la domanda. – deceze

+2

Il tipico problema quando si hanno due cookie con lo stesso nome è che si imposta lo stesso cookie con due diversi attributi PATH, oppure si imposta lo stesso cookie con due diversi attributi DOMAIN. Quest'ultimo si verifica spesso quando un utente visita il tuo sito come //example.com e successivamente visita come //www.example.com. Se il tuo sito non fa attenzione a reindirizzare sempre a www.example.com senza impostare un cookie, finirai con due. A causa della natura dell'ereditarietà dei domini dei cookie, entrambi vengono inviati quando visiti www.example.com. Il modo più semplice per controllare? Visita //example.com e controlla! – EricLaw

+0

Mentre leggo la tua domanda più da vicino, mi sembra che tu sappia già che questo è il problema. Per risolvere il problema, aggiungi l'attributo DOMAIN = esempio.com a tutte le intestazioni di risposta SET-COOKIE. – EricLaw

2

Si potrebbe avere due problemi qui.Innanzitutto, dai il link in @ freddy-rios pubblicando uno scatto. Se ciò non avviene, allora si potrebbe provare l'IE "bug del cookie di reindirizzamento".

IE non sempre rispetta la modifica dei cookie durante il reindirizzamento. Se si assegna un ID sessione nel modulo di accesso e non lo si modifica, il reindirizzamento dovrebbe funzionare correttamente. Se stai modificando un cookie sul reindirizzamento, probabilmente finirai con la vecchia sessione ... il browser invierà semplicemente il vecchio cookie al nuovo URL (probabilmente, cosa dovrebbe fare ... reindirizzare la richiesta originale).

Ci sono alcuni modi per affrontare questo. Il più brutto, di gran lunga, è utilizzare un reindirizzamento di tag Javascript o META. Finché si passa un non-300 con quei cookie, il browser li accetterà quasi sempre.

Se si utilizza $this->Session->renew(), la semplice rimozione può risolvere tutti i problemi ... soprattutto se si chiama session_regenerate_id() sotto il cofano.

Suggerirei di rimuovere il reindirizzamento e vedere se è ancora un problema. Se lo è, puoi ignorare tutto ciò che ho detto. :)