2012-04-04 16 views
6

Sto perdendo ASP.NET_SessionId quando si passa da una pagina all'altra del mio sito. Il problema si verifica in Chrome/Firefox/Safari. Non succede in IE. È piuttosto strano ... ecco il mio scenario.ASP.NET_SessionId mancante

È possibile accedere al mio sito inserendo www.example.org o example.org nel browser (questa è un'informazione importante come vedrete).

Inserisco example.org. Dalla mia home page, accedo al mio sito (nota: non sto usando l'autenticazione dei form ASP.NET). Vengo inviato alla mia pagina utente predefinita (ad esempio, userpage.aspx). Da questa pagina, faccio clic su un <a> che mi invia a una pagina diversa sul mio sito. Il collegamento <a> è completo (ad es., http://www.example.org/page2.aspx). Quando vengo inviato alla nuova pagina, la mia sessione è persa!

Così, ho gestito Fiddler per cercare di scoprire il problema. Quello che ho trovato è stato interessante. Il tag dell'intestazione richiesta Il riferimento si stava perdendo tra le pagine.

Ecco i passaggi:

  1. Vai a example.org.
  2. Accedi a example.org.
  3. Sono reindirizzato a userpage.aspx. Il referente è http://example.org. ASP.NET_SessionId è impostato.
  4. Ho fatto clic su <a> (ad esempio, http://www.example.org/page2.aspx). Dopo il rendering della pagina, l'ASP.NET_SessionId viene perso.

Il perso ASP.NET_SessionId è perduto in modo coerente è Chrome/Firefox/Safari. Questo non succede in IE.

Se ripetere i passaggi precedenti sostituendo example.org con www.example.org, ASP.NET_SessionId non viene perso. Funziona, correttamente ogni volta.

Qualche idea su questo comportamento?

+0

in Fiddler è il cookie inviato in tutti i casi o no? –

+0

cosa stai cercando nel codice pagina 2 dietro? e stai usando la modalità stato sessione InProc? –

risposta

6

Aggiungi questo al vostro web.config sotto il <system.web> elemento

 
<httpCookies domain=".mysite.com" /> 

vedere se c'è qualche cambiamento nel comportamento. Sembra che i sotto-domini stiano fallendo anche se pensavo che il cookie fosse basato sul dominio radice per cominciare. questo dovrebbe forzarlo in questo modo.

+0

Penso che tu possa essere su qualcosa. Il cookie è solo un lato dell'equazione sulla gestione dello stato della sessione. C'è anche il server. Credo che dal punto di vista di IIS, www.mysite.com sia un'applicazione diversa rispetto a mysite.com. Anche se puntano agli stessi file/directory fisici, sono entità distinte e la sessione è basata su httpcontext.current, che è collegato all'ambito dell'applicazione corrente. (Spero che qualcuno più intelligente di me possa esprimerlo meglio e verificare se ho ragione su questo, probabilmente non lo sono. In realtà lo sto solo mettendo fuori e sperando di imparare.) – David

+0

@DavidStratton saranno tutti presenti nel stesso pool di app. Tutte le intestazioni host configurate puntano allo stesso pool di applicazioni. In questo caso penso che il browser non stia semplicemente inviando il cookie a causa del dominio dei cookie (quindi funziona come previsto) La cosa importante qui (non annotata nell'OP) è se il violinista mostra il cookie inviato o meno. –

+0

grazie che ha senso. – David

0

Nel mio caso il seguente era il problema:

Nel mio ambiente di Visual Studio locale, il mio file di sviluppo "web.config" accidentially conteneva la seguente:

<configuration> 
    <system.web> 
     <httpCookies requireSSL="true" /> 
    </system.web> 
</configuration> 

Poiché lo sviluppo IIS Express collega allo http://localhost:7561, che non è HTTPS, questo controllo è stato attivato per non impostare/accettare alcun cookie, incluso il cookie dell'ID di sessione.

Soluzione era semplicemente commentare la linea <httpCookies requireSSL="true" />.


altro, problema analogo potevo immaginare è che la Content-Security-Policy HTML meta tag, che anche controls how cookies are handled, potrebbe anche essere configurato per non consentire il cookie di sessione ID da impostare.