CORSO DI JSP
|
CORSO DI JSP |
|
Il problema delle sessioni è molto semplice appena si pensi che il protocollo http non ha memoria, è stateless. Un client inoltra la richiesta e il server la serve all'inteno di un'unica sessione TCP/IP per la trasmissione dei pacchetti. Una volta conclusa la transazione il web server si dimentica di chi è stato a chiedere l'informazione e non ha modo di sapere, al suo livello di applicazione, se il prossimo utente a fare una richiesta è quello di prima o è un altro.
La metafora client/server del ristorante è sempre molto eloquente. Di fatto in un ristorante il client è colui che sta seduto al tavolo e chiede un piatto, il web server è il cuoco che prepara il piatto e lo manda fuori dalla cucina. Per tenere conto di quali pietanze si servono e a chi, è necessario che il cameriere annoti in un foglietto l'associazione tra piatti e cliente, marcando tutte queste associazioni con un numero univoco nel foglietto (di solito il numero del tavolo). Questo numero identifica la sessione. Le pietanze scelte sono le variabili di sessione.
Così, ci deve essere una strategia aggiuntiva, che di solito esegue l'application server, che serve per dare uno stato alla connessione http.
Una strategia spesso adottata è quella dei cookies, che in qualche modo fanno le veci del foglietto: un cookie è un file di testo che contiene informazioni sul server che lo emette, un identificativo univoco - di solito una stringa generata casualmente, di molti caratteri per minimizzare la probabilità di generarne due di uguali in tempi ravvicinati -, una data di scadenza.
Le fasi di "palleggio" per stabilire lo stato della connessione sono i seguenti:
L'applicazione multiutente ha così modo di distinguere ambienti creati per ciascun utente: questa distinzione è basilare, ad esempio, per una applicazione di tipo e-commerce, nella quale è fondamentale che ciascun utente abbia un proprio carrello distinto con i propri prodotti e con un proprio importo. Prodotti e importi possono essere salvati in variabili di sessione che possono essere realizzate nella RAM del server, oppure nel file system del server, oppure in un database al quale l'application server sia connesso, oppure ancora in un oggetto (nell'istanza di una classe).
In JSP esiste un oggetto implicito (che non occorre cioè importare, analogo all'oggetto request) denominato session riferimento della classe javax.servlet.http.HttpSession. Quando la sessione non esiste (ad esempio mi devo autenticare), Tomcat stesso si preoccupa di aggiungere all'inizio una chiamata ad un metodo che serve per creare l'oggetto e per fare in modo che ci si possa riferire ad esso durante il ciclo di vita della pagina. La creazione della sessione coincide con la spedizione di un cookie al browser.
Tutto quello che dobbiamo fare è semplicemente USARE l'oggetto session. Per vedere quali siano le proprietà e i metodi di javax.servlet.http.HttpSession, consultare le API di Java2. In particolare useremo due metodi:
L'uso della sessione ci sgrava dal doverci trascinare avanti e indietro nelle form tutte le informazioni a cui dobbiamo fare riferimento nella sessione, come ad esempio il nome e cognome dell'utente registrato.
Di default Tomcat invia sempre un cookie (è una preimpostazione di default). Lo si può vedere in una servlet generata da Tomcat a partire da una qualsiasi pagina che scriviate.
Useremo solo i cookies di sessione (per noi sufficienti) ma si possono anche generare dei cookies custom.
