Nu i-am acordat prea multă atenție când învățam înainte, dar astăzi m-am întors și am studiat cu atenție ciclul de viață al sesiunii.
Sesiunile sunt stocate pe partea de server și, în general, pentru a preveni ca acestea să fie în memoria serverului (pentru acces de mare viteză), Sessinon creează prima dată când utilizatorul accesează serverul.Rețineți că doar accesarea JSP, Servlet și alte programe va crea o Session, iar accesarea doar a resurselor statice precum HTML și IMAGE nu va crea o Session.
Când expiră o sesiune?
1. Serverul va șterge sesiunea din memoria serverului care a fost inactivă de mult timp, iar sesiunea va fi invalidă. Timpul implicit de expirare al unei sesiuni în Tomcat este de 20 de minute.
2. Apelarea metodei de invalidare a sesiunii.
Cerințe de sesiune pentru browsere:
Deși sesiunea este stocată pe server și este transparentă pentru client, funcționarea sa normală necesită totuși suportul browserului clientului. Acest lucru se datorează faptului că Session trebuie să folosească cookie-uri ca identificator. Protocolul HTTP este fără stare, iar sesiunea nu poate fi evaluată de conexiunea HTTP pentru a determina dacă este același client, astfel că serverul trimite un cookie numit JSESSIONID către browserul client, care are valoarea ID-ului sesiunii (adică valoarea returnată a HttpSession.getId()). Session folosește cookie-ul pentru a identifica dacă este același utilizator.
Acest cookie este generat automat de server, iar atributul său maxAge este de obicei -1, ceea ce înseamnă că este valabil doar în browserul curent, nu este partajat între ferestrele browserului și nu va fi valabil când browserul este închis. Prin urmare, când două ferestre de browser pe aceeași mașină accesează serverul, se generează două sesiuni diferite. Cu excepția ferestrelor noi deschise prin linkuri, scripturi etc. din fereastra browserului (adică nu ferestrele deschise prin dublu click pe pictogramele browserului desktop etc.). Aceste ferestre copil partajează cookie-ul ferestrei părinte și, prin urmare, o sesiune.
Notă: Noile sesiuni sunt generate în ferestrele de browser nou deschise, cu excepția subferestrelor. Fereastra copil împarte sesiunea ferestrei părinte. De exemplu, când dai click dreapta pe un link și selectezi "Deschide într-o fereastră nouă" în meniul de scurtături care apare, fereastra copil poate accesa sesiunea ferestrei părinte.
Ce se întâmplă dacă browserul clientului dezactivează cookie-urile sau nu suportă cookie-uri? De exemplu, marea majoritate a browserelor mobile nu suportă cookie-uri. Java Web oferă o altă soluție: rescrierea adreselor URL.
Rescrierea adreselor URL este o soluție pentru clienții care nu suportă cookie-uri. Principiul rescrierii adreselor URL este rescrierea informațiilor de id ale sesiunii utilizatorului în adresa URL. Serverul poate analiza URL-ul rescris pentru a obține ID-ul de sesiune. Astfel, chiar dacă clientul nu suportă cookie-uri, sesiunea poate fi folosită pentru a înregistra starea utilizatorului. Clasa HttpServletResponse oferă encodeURL (URL String) pentru a implementa rescrierea adreselor URL, care determină automat dacă clientul suportă cookie-uri. Dacă clientul suportă cookie-uri, URL-ul va fi afișat așa cum este. Dacă clientul nu suportă cookie-uri, ID-ul sesiunii utilizatorului este rescris în URL.
Notă: TOMCAT determină dacă un browser client suportă cookie-uri pe baza includerii unui cookie în cerere. Deși clientul poate suporta cookie-uri, deoarece nu există cookie-uri la prima cerere (deoarece nu există cookie-uri care să poată face asta), adresa URL rescrisă va avea totuși jsessionid în adresă. Serverul a scris deja un cookie în browser la a doua vizită, astfel încât adresa URL rescrisă nu va avea jsessionid în adresă.
|
Postat pe 19.04.2015 19:44:59
|
|
|
Postat pe 18.03.2017 16:52:21