Non ci avevo prestato molta attenzione quando studiavo prima, ma oggi sono tornato indietro e ho studiato attentamente il ciclo di vita della sessione.
Le sessioni sono memorizzate lato server e, generalmente, per evitare che finiscano nella memoria del server (per accesso ad alta velocità), Sessinon crea la prima volta che l'utente accede al server.Si noti che solo accedere a JSP, Servlet e altri programmi creerà una Sessione, e solo accedere a risorse statiche come HTML e IMAGE non creerà una Sessione.
Quando scade una sessione?
1. Il server cancellerà la sessione dalla memoria del server che è stata inattiva da molto tempo e la sessione sarà invalida. Il tempo di scadenza predefinito di una sessione in Tomcat è di 20 minuti.
2. Chiama il metodo di invalidazione della Sessione.
Requisiti di sessione per i browser:
Sebbene la sessione sia memorizzata sul server ed è trasparente per il client, il suo normale funzionamento richiede comunque il supporto del browser del client. Questo perché Session deve usare i cookie come identificatore. Il protocollo HTTP è senza stato e la sessione non può essere giudicata dalla connessione HTTP per determinare se si tratta dello stesso cliente, quindi il server invia un cookie chiamato JSESSIONID al browser client, che contiene il valore dell'id della sessione (cioè il valore di ritorno di HttpSession.getId()). Session utilizza il cookie per identificare se si tratta dello stesso utente.
Questo cookie viene generato automaticamente dal server e il suo attributo maxAge è solitamente -1, il che significa che è valido solo nel browser corrente, non condiviso tra le finestre del browser e non sarà valido quando il browser è chiuso. Pertanto, quando due finestre del browser sulla stessa macchina accedono al server, vengono generate due sessioni diverse. Tranne che per nuove finestre aperte da link, script, ecc. all'interno della finestra del browser (cioè non finestre aperte con doppio clic sulle icone del browser desktop, ecc.). Queste finestre figlie condividono il cookie della finestra genitore e quindi una sessione.
Nota: Le nuove sessioni vengono generate nelle nuove finestre del browser aperte, ad eccezione delle sottofinestre. La finestra figlia condivide la sessione della finestra genitore. Ad esempio, quando fai clic destro su un link e selezioni "Apri in una nuova finestra" nel menu scorciatoia che appare, la finestra figlia può accedere alla Sessione della finestra genitore.
Cosa succede se il browser client disabilita i cookie o non li supporta? Ad esempio, la stragrande maggioranza dei browser mobili non supporta i cookie. Java Web offre un'altra soluzione: la riscrittura degli indirizzi URL.
La riscrittura degli indirizzi URL è una soluzione per i client che non supportano i cookie. Il principio della riscrittura degli indirizzi URL è riscrivere le informazioni id della sessione dell'utente all'indirizzo URL. Il server può analizzare l'URL riscritto per ottenere l'ID della sessione. In questo modo, anche se il client non supporta i cookie, la sessione può essere utilizzata per registrare lo stato dell'utente. La classe HttpServletResponse fornisce encodeURL (URL stringa) per implementare la riscrittura degli indirizzi URL, che determina automaticamente se il client supporta i cookie. Se il client supporta i cookie, l'URL verrà prodotto così com'è. Se il client non supporta i cookie, l'id della sessione utente viene riscritto nell'URL.
Nota: TOMCAT determina se un browser client supporta i cookie in base all'inclusione di un cookie nella richiesta. Sebbene il client possa supportare i cookie, poiché nessun cookie viene portato nella prima richiesta (poiché non esistono cookie che possano farlo), l'indirizzo URL riscritto avrà comunque jsessionid nell'indirizzo. Il server ha già scritto un cookie nel browser alla seconda visita, quindi l'indirizzo URL riscritto non avrà jsessionid nell'indirizzo.
|
Pubblicato su 19/04/2015 19:44:59
|
|
|
Pubblicato su 18/03/2017 16:52:21