In questi giorni stavo dando una guardatina alla gestione delle Session e dell'Authentication per l'ASP.NET 2.0. Nella versione 1.* è previsto l'utilizzo delle Session anche quando i cookies sono disabilitati sul browser. E' sufficiente inserire nel web.config:
<sessionState cookieless="true" />
L'identificatore di sessione ora sarà inserito nell'URL della pagina permettendo, in questo modo, il riconoscimento dell'utente ad ogni nuova richiesta. Non mi dilungo oltre, ne ho già parlato parecchio di questo argomento.
Il problema di questa tecnica è che la scelta dev'essere fatta prima e sarà uguale per tutti. Se nella nostra webapplication la gestione delle session è indispensabile, possiamo impostare a true la sezione di configurazione prima scritta in modo che anche gli utenti con i cookies disabilitati possano utilizzare la webapplication, ma per gli utenti, lasciatemi passare il termine, normali? Anche loro navigheranno nel sito con la gestione dell'identificatore di sessione nell'URL con tutti i problemi che comporta questa tecnica. Se poi mettiamo in contro che l'autenticazione non si collega all'identificatore di sessione nell'url...
Dalla versione 2.0 finalmente è stata trovata una soluzione decente. Ora nel web.config possiamo inserire questa opzione:
<sessionState cookieless="true, false, UseUri, UseCookies, AutoDetect, UseDeviceProfile" />
Ben quattro nuove opzioni. Ma ecco la più interessante: AutoDetect. Utilizzando questa opzione la webapplication sarà in grado di capire se il browser dell'utente ha i cookie disabilitati o meno, e in caso agisce di conseguenze inserendo l'identificatore di sessione in un cookie o nell'url della pagina. Notevole.
Ma come funziona sta cosa?
Sto ancora investigango a riguardo, ma si basa su un banale gioco di invii pagina e redirect sulla stessa con tentativi di scrittura di cookie. Se il browser ha i cookie attivi tutto funziona come al solito:
GET /netbeta1/pagina.aspx - 80 - 192.168.0.1 Mozilla/5.0+ 200 0 0
Se proviamo disabilitando i cookie la tecnica inizia a diventare più chiara:
GET /netbeta1/pagina.aspx - 80 - 192.168.0.1 Mozilla/5.0+ 302 0 0
GET /netbeta1/pagina.aspx AspxAutoDetectCookieSupport=1 80 - 192.168.0.1 Mozilla/5.0+ 302 0 0
GET /netbeta1/pagina.aspx AspxAutoDetectCookieSupport=1 80 - 192.168.0.1 Mozilla/5.0+ 200 0 0
Quando viene richiamata la pagina viene viene tentata la scrittura del cookie e inviato dal Framework il codice "302" per il redirect sulla stessa pagina con l'opzione "AspxAutoDetectCookieSupport". Viene effettuato ancora un controllo e si passa alla pagina vera e propria, e questa "lunga" elaborazione solo la prima volta che viene richiamata una pagina della nostra webapplication.
Ora sto cercando di capire con i vari Reflector dove sta il codice che fa tutto questo... :)
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
- Un po' di benchmark tra Linq, Entity Framework e Nhibernate, il 12 ottobre 2008 alle 14:46
- UrlRewriting con trabocchetti vari, l'11 dicembre 2007 alle 21:00
- Windows Forms - DataGridView e validazione, il 23 settembre 2007 alle 20:08
- ControlParameter e masterpage... bug?, il 23 dicembre 2006 alle 15:58
- Se Visual Studio 2005 non accetta più la tastiera, il 16 dicembre 2006 alle 20:45
- Service Pack 1 di Visual Studio 2005, il 16 dicembre 2006 alle 20:35