[70-305 #5] Gestione avanzata dello Stato Sessione.

L' argomento è vasto ma ritengo più logico incorporare tutto in un solo argomento, visto che è proprio la gestione dello stato dell' utente che è complessa e articolata di suo.
Con questo oggetto gestiamo lo stato del nostro singolo utente. Anche questo oggetto viene esposto come proprietà nelle nostre pagine, come in esempio : 

Session("MySessionVar") = "abcdABCD"
MyVar = Session("MySessionVar")

La nostra applicazione crea un ID utente univoco per ogni utente, l' oggetto Session accede alle informazioni utente tramite questo ID; quindi siamo sicuri di accedere a proprietà e caratteristiche uniche per ogni utente.

Come per Application anche session espone metodi e proprietà :

  • Keys : Insieme di tutte le chiavi presenti.
  • Count : Numero di oggetti presenti.
  • SessionID : Stringa che contiene l' ID univoco dell' utente.
  • Timeout : Int32, valore che imposta la durata della Sessione.
  • Abandon : Eliminazione della Sessione.
  • Clear : Rimozione di tutti gli elementi.
  • RemoveAt : rimozione per indice.
  • ToString : restituisce il valore di Session, sempre per valori stringa.

La Sessione può essere attivata o meno a piacimento, al contrario dell' Applicazione che risulta attiva all' avvio. Per fare ciò possiamo usare le impostazioni di Web.Config o inserire una direttiva a livello di pagina : 

<%@ Page EnableSessionState="False" %>

Se la sessione era stata creata in una precedente pagina, qui non stiamo elimininando la sessione ma ne stiamo semplicemente impedendo l' accesso ... Infatti per questo motivo esiste anche la possibilità di impostare la sessione a Read-Only. Questa operazione può essere eseguita anche dal pannello Proprietà della pagina, in Visual Studio.

Info Problemi Alternativa
Impostazioni Utente Non è sempre il metodo migliore, dipende dalla frequenza Meglio usare un Db
Dataset di uso freq. Utile ma ha un costo di risorse elevato Sempre meglio il modulo di gestione cahce
Istanze a oggetti Primis Thread Safe inoltre valutate il dispendio di risorse per ogni utente Solo se necessario

Scalabilità

La scalabilità è la capacità di un' applicazione di soddisfare le richieste di un numero crescente di utenti senza ridurre le prestazioni . (a parer mio puramente teorico)
Vediamo quali possono essere gli errori principali per interferire con la scalabilità :

  • Attivazioni inutili di Stato di Sessione (Web.Config on)
  • Uso improprio di Lock su Application
  • Memorizzazione di oggetti Single Thread o Apartment, questi ogetti non consentono una corretta gestione del thread da parte di iis
  • Stati Sessione in-process ovvero non sempre lo stato della sessione consente di interagire tra più web server
  • Utilizzo eccessivo (non merita commenti ...)

Vediamo adesso con quali metodologie possiamo tener traccia dello stato della Sessione. La guida Microsoft ci propone 4 tipologie principali : In-process, Out-of-process, SQLServer e no-Cookie.

In-Process

Questa è l' impostazione di base, quella che non ci consente la condivisione diinformazioni tra più macchine. Ereditata da Asp Classic.

Out-of-process

Con questo metodo usiamo un processo dedicato esposto come servizio NT per ASP.NET. Con questo metodo possiamo caricare un altro thread delle informazioni e reperirle anche dopo una chiusura anomala dell' applicazione, ma non dopo il riavvio di un server ...
Procedere come segue :

  • Nodo SessionState del web.config
  • Mode va cambiato da InProc a StateServer
  • StateConnectionString va indicatol' indirizzo della macchina di supporto

Cosa succede? Net verrà connesso automaticamente al servizio sulla macchina indicata, se questa non presenta ilservizio attivo, verrà generato un errore.

Memorizzazione in SQL Server

Come, posso usare la tecnica Out-of-process con SQl Server? Questo meccanismo risulta più sicuro perché la sessione viene gestita da SQL e quindi memorizzata anche se avviene un improvviso riavvio. Come procedere :

  • Inanzitutto installare SQL in rete, eseguire InstallSqlState.sql che risiede nel framework
  • Modificare in Web.Config con l' attributo SQLServer
  • Indicare in StateConnectionString la macchina che ospita SQL nonchè ID e Pwd
    Nota che usando un Username e Pwd nel web.config si possono mettere a rischio le protezioni.

Sessioni senza Cookie

Un grosso problema che ci viene fornito dai browser attuali é quello di poter disabilitare l' utlizzo dei cookie. Tramite web.config possiamo impostare l' attributo <sessionstate cookieless = true.
Da adesso ad ogni richiesta all' URL verrà unito l' ID dell'utente.

Purtroppo usando questa soluzione si ha un problema, se larichiesta viene effettuata da un URL non relativo, l ID non seguirà la richiesta http e quindi ASP.NET ne creerà uno nuovo.
Per ovviare a ciò dobbiamo formattare manualmente gli url che riceviamo.

Dim myAbsoluteUrl as String = ""
myAbsoluteUrl = Response.ApplyAppPathModifier("foo.aspx")

Le Sessioni con i Cookie

Questo metodo, che funziona solamente per quegli utenti che sono in grado di accettare cookie, è semplice e non è cambiato molto dal vecchio Asp.

'Creo l' oggetto
Dim myCookie As New HttpCookie("NomeCookie")

'Assegno un valore
myCookie.Value = "abcdABCD"

'Lo aggiungo alla collection Cookie della classe Page
Response.Cookie.Add(myCookie) 

Questo cookie avrà durata fino alla chiusura del browser.

Possiamo però usare i cookie persisenti che ci consentono una durata superiore. Ovvero possiamo impostare a codice la durata del nostro cookie a giorni, settimane mesi e anni!!
Codice : 

myCookie.Expires = Now.AddDays(2)

Lascio a voi ogni considerazione sull' utilizzo di dati di questo tipo. Io personalmente lo sconsiglio e lo ritengo invadente per l' utente nonché poco sicuro (i cookie possono essere letti) e poco stabile (i cookie vengono spesso cancellati nel client).