2014-09-16 11 views
5

Il mio sito utilizza ASP.Net MVC 5.2.2 e ASP.Net Identity 2.1.0. In CookieAuthenticationOptions imposto ExpireTimeSpan a 30 minuti e l'intervallo di convalida del timbro di sicurezza è impostato su 2 minuti (in modo che gli utenti vengano riavviati entro due minuti da una chiamata a UserManager.UpdateSecurityStampAsync.La firma dell'identità di ASP.NET fallisce se inattiva per un intervallo di convalida del timbro di sicurezza

Il problema è che se gli utenti rimangono inattivo per più di 2 minuti e quindi fare clic sul pulsante Disconnetti, il sito non riesce a disconnetterli. Dopo un po 'di investigazione, ho scoperto che in questi casi il server restituisce un nuovo cookie dell'applicazione (il cookie inviato al server era diverso da quello restituito) Ciò che sembra accadere è che il codice owin manca la chiamata a AuthenticationManager.SignOut e procede con la generazione di un nuovo cookie applicativo, come di solito accade nei casi in cui il vecchio è più di due minuti.

Qualcun altro ha riscontrato questo problema? Qualche suggerimento su come diagnosticare e risolvere?

Sto utilizzando VS 2013 Update 3, ma questo problema esisteva con le versioni precedenti di Identity.

UPDATE:

Come esperimento, ho creato un nuovo progetto di applicazione Web ASP.NET con i VS 2013 Update 3 modelli e ho notato lo stesso problema esatto: mi sono collegato e poi abbiamo aspettato per un importo di tempo uguale al timbro di sicurezza validateInterval (per impostazione predefinita, 30 minuti). Successivamente ho fatto clic sul collegamento Disconnessione e ho notato che, proprio come nel mio progetto, a) Non ero disconnesso, e b) mi è stato rilasciato un nuovo cookie del timbro di sicurezza. Ho dovuto fare clic sul collegamento una seconda volta per essere disconnesso. In effetti, non avevo nemmeno bisogno di stare inattivo per 30 minuti: potevo continuare a fare richieste durante quel periodo e il clic sul pulsante di disconnessione sarebbe comunque fallito, purché fosse la prima richiesta dopo l'intervallo di 30 minuti scaduto.

Questo sembra essere un bug nel codice di identità OWIN. Fondamentalmente, se la prima richiesta dopo l'intervallo di convalida è una richiesta di signout, fallisce, perché il codice che convalida ed emette un nuovo bollo di sicurezza non controlla se l'utente ha effettuato il logout come parte della stessa richiesta. Le richieste di disconnessione falliranno, a condizione che facciano parte di una richiesta che causerebbe la riemissione del timbro di sicurezza, vale a dire la prima richiesta dopo i minuti di validazione dell'Interval dall'emissione del timbro di sicurezza precedente.

Apprezzerei se qualcuno potesse confermare questo comportamento. Non devi aspettare 30 minuti e non devi creare un nuovo progetto. Basta prendere un progetto esistente che utilizza Identity, impostare temporaneamente l'intervallo di validazione su qualcosa di veramente breve (30 secondi o un minuto), accedere e assicurarsi che la prima richiesta dopo che l'intervallo scade sia un clic sul pulsante Logout. Se questo è un bug, dovresti notare che sei ancora loggato.

risposta

5

Ho anche riscontrato lo stesso problema. Ho risolto il problema cambiando il mio AuthenticationManager.SignOut per specificare un tipo di autenticazione come segue:

AuthenticationManager.SignOut(DefaultAuthenticationTypes.ApplicationCookie, DefaultAuthenticationTypes.ExternalCookie); 

Inoltre, i componenti Owin dovrebbero essere alla versione 3.0.0 (che dovrebbe essere il caso, dal momento che si sta utilizzando Identità 2.1.0)

+0

Questo è esattamente ciò che ho scoperto alcuni mesi fa. Sembra essere un bug nei componenti dell'identità. Ho pubblicato la correzione (identica a questa soluzione) sul sito Katana Codeplex (https://katanaproject.codeplex.com/workitem/356), ma ho dimenticato di aggiornare questo forum. Accettare la tua risposta – Pando

+0

Sono felice che tu abbia capito bene! Mi sono fatto graffiare la testa anche un paio di mesi fa. Ho dovuto fare un bel po 'di lettura prima che un post qui mi portasse ai tipi di autenticazione di default. Ho pensato di provarlo e ha funzionato! : P – WJK

Problemi correlati