utenti costretti a ri-login a caso, prima che i valori di sessione e di timeout biglietto auth vengono raggiunti

Question

sto avendo rapporti e denunce da parte il mio utente che saranno utilizzando uno schermo e ottenere calci indietro alla schermata di login immediatamente sulla loro prossima richiesta. Non succede sempre ma a caso. Dopo aver esaminato il server Web, l'errore visualizzato nel registro eventi dell'applicazione è:

Codice evento: 4005 Messaggio evento: autenticazione moduli non riuscita per la richiesta. Motivo: il biglietto fornito è scaduto.

Tutto quello che ho letto inizia con la gente chiedendo di giardini web o il bilanciamento del carico. Non stiamo usando nessuno di questi. Siamo un unico server Windows 2003 (sistema operativo a 32 bit, hardware a 64 bit) con IIS6. Questo è l'unico sito web anche su questo server.

Questo comportamento non genera eccezioni di applicazione o problemi visibili per l'utente. Sono appena tornati alla schermata di accesso e sono costretti ad accedere. Come puoi immaginare, questo è estremamente fastidioso e controproducente per i nostri utenti.

Ecco quello che ho posto nel mio web.config per l'applicazione nella radice:

<authentication mode="Forms"> 
     <forms name=".TcaNet" 
     protection="All" 
     timeout="40" 
     loginUrl="~/Login.aspx" 
     defaultUrl="~/MyHome.aspx" 
     path="/" 
     slidingExpiration="true" 
     requireSSL="false" /> 
    </authentication> 

Ho anche letto che, se si dispone di alcune posizioni di installazione che non esistono più o sono falsi si potrebbe avere problemi . I miei attributi di percorso sono tutte le directory valide modo che non dovrebbe essere il problema:

<location path="js"> 
    <system.web> 
     <authorization> 
     <allow users="*" /> 
     </authorization> 
    </system.web> 
    </location> 
    <location path="images"> 
    <system.web> 
     <authorization> 
     <allow users="*" /> 
     </authorization> 
    </system.web> 
    </location> 
    <location path="anon"> 
    <system.web> 
     <authorization> 
     <allow users="*" /> 
     </authorization> 
    </system.web> 
    </location> 
    <location path="App_Themes"> 
    <system.web> 
     <authorization> 
     <allow users="*" /> 
     </authorization> 
    </system.web> 
    </location> 
    <location path="NonSSL"> 
    <system.web> 
     <authorization> 
     <allow users="*" /> 
     </authorization> 
    </system.web> 
    </location> 

L'unica cosa che non sono chiare su è se il mio valore di timeout nella proprietà forme per il biglietto auth deve essere la stessa come valore di timeout della sessione (definito nella configurazione dell'app in IIS). Ho letto alcune cose che dice che bisogna avere il timeout di autenticazione più corta (40) rispetto al timeout di sessione (45) per evitare possibili complicazioni. Ad ogni modo, abbiamo degli utenti che vengono calciati alla schermata di login un minuto o due dopo la loro ultima azione. Quindi la sessione sicuramente non dovrebbe scadere.

Aggiornamento 23/02/09: Da allora ho impostato il timeout della sessione e i valori di timeout del ticket di autenticazione sono entrambi 45 e il problema sembra essere ancora in corso.

L'unico altro web.config nell'applicazione è in 1 directory virtuale che ospita Server comunità. impostazioni di autenticazione che di web.config sono i seguenti:

<authentication mode="Forms"> 
      <forms name=".TcaNet" 
      protection="All" 
      timeout="40" 
      loginUrl="~/Login.aspx" 
      defaultUrl="~/MyHome.aspx" 
      path="/" 
      slidingExpiration="true" 
      requireSSL="true" /> 
     </authentication> 

E mentre io non credo che si applica a meno che non sei in un giardino web, ho entrambi i valori chiave della macchina impostati in entrambi i file web.config per essere lo stesso (rimosso per comodità):

<machineKey 
     validationKey="<MYVALIDATIONKEYHERE>" 
     decryptionKey="<MYDECRYPTIONKEYHERE>" 
     validation="SHA1" /> 

<machineKey 
     validationKey="<MYVALIDATIONKEYHERE>" 
     decryptionKey="<MYDECRYPTIONKEYHERE>" 
     validation="SHA1"/> 

Qualsiasi aiuto con questo sarebbe molto apprezzato. Questo sembra essere uno di quei problemi che produce una tonnellata di risultati di Google, nessuno dei quali sembrano essere montaggio in mia situazione finora.

Answer 1

1.) Controllare la frequenza con cui il processo iis viene riciclato. (Accendere logging e check your settings). Dopo un riciclo, utilizzando l'impostazione predefinita in store sessione proc, la sessione viene persa.

2.) La tua applicazione genera thread che possono generare un'eccezione (che non viene visualizzata all'utente)? Perché se esiste questa situazione, l'iis ricicla i processi molto più spesso.

Answer 2

Potrebbe anche essere utile verificare la proprietà dei Processi massimi del lavoro per il pool di applicazioni. Se si sta utilizzando nella sessione di memoria e si ha più di un processo di lavoro massimo, è possibile trovare problemi di sessione in quanto una richiesta utente viene gestita da un thread diverso che non è consapevole della propria sessione.

Answer 3

Poiché si è notato che si sta utilizzando un FQDN molto specifico per il proprio sito, esistono altre applicazioni .Net in esecuzione con lo stesso nome di dominio completo solo percorsi virtuali diversi? Il nome dell'autent cookie potrebbe essere lo stesso per entrambe le applicazioni, ma il token sarà diverso. Quindi, se accedo a www.domain.com e poi a www.domain.com/app2, non avrò più l'autenticazione corretta per app1.

Answer 4

Ho appena finito di affrontare questo problema preciso, esattamente come descritto nella domanda e il problema era un po 'di configurazione mancante in web.config.

Quando si utilizza formsAuthentication, è necessario interrompere l'autenticazione della sessione, poiché il cookie è ora responsabile.

Questa linea deve essere aggiunto (o aggiornato) nel vostro web di configurazione, nell'elemento "system.web"

<sessionState mode="Off"> 

sessionState e FormsAuthentication non devono essere attivi. Non capisco i dettagli di come interferiscono l'uno con l'altro, ma in questo caso, ha prodotto casellari casuali di utenti casuali in momenti casuali.

Answer 5

Il nostro sito è inciampato con lo stesso problema da anni, ma ieri abbiamo trovato una soluzione, vedere my question. Come un commentatore ha suggerito, ho provato ad aggiungere questo per web.config:

<sessionState mode="InProc" timeout="60" /> 

A quanto pare, il timeout deve essere impostato sia in sessionState e nel biglietto. Vedi anche ms docu nel https://msdn.microsoft.com/en-us/library/ms178586.aspx

Per misurare in modo più accurato il timeout effettivo, mentre in modalità debug, ho trovato a portata di mano per aggiungere Debug.WriteLine chiamate nel file di Global.asax.cs nei metodi Session_Start() e Session_End(), con il tempo millisecondo aggiunto utilizzando

string.Format("{0:HH:mm:ss.fff} - {1}", DateTime.Now, strMessage); 

in modo che sia possibile accedere, andare a pranzo, lasciare scadere la sessione e leggere i timestamp in un momento opportuno nella finestra Output di VisualStudio.