Heim > Artikel > Web-Frontend > Einführung in den Cookie-/Sitzungsmechanismus
Einführung in den Cookie-/Sitzungsmechanismus
- 一个新手Original
- 2017-09-23 09:09:551631Durchsuche
Sitzungsverfolgung ist eine häufig verwendete Technologie in Webprogrammen, die dazu dient, die gesamte Sitzung eines Benutzers zu verfolgen. Häufig verwendete Sitzungsverfolgungstechnologien sind Cookie und Session. Cookie bestimmt die Identität des Benutzers, indem es Informationen auf der Clientseite aufzeichnet , und Session bestimmt die Identität des Benutzers, indem es Informationen auf der Serverseite aufzeichnet .
In diesem Kapitel werden die Cookie- und Sitzungsmechanismen systematisch beschrieben und verglichen und erläutert, wann Cookies nicht und wann Sitzungen nicht verwendet werden können.
1.1 Cookie-Mechanismus
Im Programm ist die Sitzungsverfolgung eine sehr wichtige Sache. Theoretisch sollten alle Anforderungsvorgänge eines Benutzers zur selben Sitzung gehören, während alle Anforderungsvorgänge eines anderen Benutzers zu einer anderen Sitzung gehören sollten, und die beiden können nicht verwechselt werden. Beispielsweise sollte jedes von Benutzer A im Supermarkt gekaufte Produkt in den Warenkorb von A gelegt werden. Unabhängig davon, wann Benutzer A es kauft, gehört es zur selben Sitzung und kann nicht in den Warenkorb von Benutzer B oder Benutzer C gelegt werden gehören nicht zur selben Sitzung.
Webanwendungen nutzen das HTTP-Protokoll zur Datenübertragung. Das HTTP-Protokoll ist ein zustandsloses Protokoll. Sobald der Datenaustausch abgeschlossen ist, wird die Verbindung zwischen Client und Server geschlossen und es muss eine neue Verbindung hergestellt werden, um erneut Daten auszutauschen. Dies bedeutet, dass der Server die Sitzung nicht über die Verbindung verfolgen kann. Das heißt, Benutzer A kauft einen Artikel und legt ihn in den Warenkorb. Wenn der Artikel erneut gekauft wird, kann der Server nicht feststellen, ob der Kauf zur Sitzung von Benutzer A oder zur Sitzung von Benutzer B gehört. Um diese Sitzung zu verfolgen, muss ein Mechanismus eingeführt werden.
Cookie ist ein solcher Mechanismus. Es kann die zustandslosen Mängel des HTTP-Protokolls ausgleichen. Bevor Session erschien, verwendeten grundsätzlich alle Websites Cookies, um Sitzungen zu verfolgen.
1.1.1 Was ist Cookie?
Cookie bedeutet „süßer Keks“, der von der W3C-Organisation vorgeschlagen und zuerst von Netscape entwickelt wurde Gemeinschaft ein Mechanismus. Derzeit sind Cookies zum Standard geworden und alle gängigen Browser wie IE, Netscape, Firefox, Opera usw. unterstützen Cookies.
Da HTTP ein zustandsloses Protokoll ist, hat der Server keine Möglichkeit, die Identität des Clients allein anhand der Netzwerkverbindung zu ermitteln. Was zu tun? Geben Sie den Kunden einfach einen Ausweis aus, einen für jede Person. Unabhängig davon, wer uns besucht, müssen sie ihren eigenen Ausweis mitbringen. Auf diese Weise kann der Server die Identität des Clients anhand des Passes bestätigen. So funktionieren Cookies.
Cookie ist eigentlich eine kurze Textinformation. Der Client fordert den Server an, den Benutzerstatus aufzuzeichnen, und sendet als Antwort ein Cookie an den Client-Browser. Der Client-Browser speichert das Cookie. Wenn der Browser die Website erneut anfordert, übermittelt der Browser die angeforderte URL zusammen mit dem Cookie an den Server. Der Server überprüft dieses Cookie, um den Status des Benutzers zu identifizieren. Der Server kann den Inhalt des Cookies auch nach Bedarf ändern.
Es ist einfach, die von einer Website ausgegebenen Cookies zu überprüfen. Geben Sie einfach javascript:alert (document. cookie) in die Adressleiste des Browsers ein (Sie benötigen eine Internetverbindung, um es anzuzeigen). Das JavaScript-Skript öffnet ein Dialogfeld mit den Inhalten aller von dieser Website ausgegebenen Cookies, wie in Abbildung 1.1 dargestellt.
Abbildung 1.1 Von der Baidu-Website ausgegebenes Cookie
Wie im Popup-Dialogfeld in gezeigt Abbildung 1.1 Cookie für die Baidu-Website. Die erste Zeile von BAIDUID zeichnet die Identität des Autors helloweenvsfei auf, Baidu verwendet jedoch eine spezielle Methode, um die Cookie-Informationen zu verschlüsseln.
Hinweis: Die Cookie-Funktion erfordert Browserunterstützung.
Wenn der Browser keine Cookies unterstützt (wie z. B. die Browser auf den meisten Mobiltelefonen) oder wenn Cookies deaktiviert sind, ist die Cookie-Funktion ungültig.
Verschiedene Browser verwenden unterschiedliche Methoden zum Speichern von Cookies.
Der IE-Browser speichert es als Textdatei im Ordner „C:Dokumente und Einstellungen – Cookies für Ihren Benutzernamen“. Jede Textdatei speichert ein Cookie.
1.1.2 Erfassen Sie die Anzahl der Benutzerbesuche
In Java ist Cookie in javax.servlet.http.Cookie gekapselt Klasse. Jedes Cookie ist ein Objekt dieser Cookie-Klasse. Der Server betreibt das Client-Cookie, indem er Cookie-Klassenobjekte bedient. Erhalten Sie alle vom Client übermittelten Cookies über request.getCookie() (zurückgegeben in Form eines Cookie[]-Arrays) und setzen Sie das Cookie über Response.addCookie(Cookiecookie) auf den Client.
Cookie-Objekte verwenden Schlüssel-Wert-Attributpaare, um den Benutzerstatus zu speichern. Ein Cookie-Objekt speichert ein Attributpaar, und eine Anfrage oder Antwort verwendet mehrere Cookies gleichzeitig. Da sich die Cookie-Klasse unter dem Paket javax.servlet.http.* befindet, besteht keine Notwendigkeit, diese Klasse in JSP zu importieren.
1.1.3 Cookies können keine Domänennamen überschreiten
Viele Websites verwenden Cookies. Beispielsweise stellt Google dem Kunden Cookies aus, und Baidu stellt dem Kunden ebenfalls Cookies aus. Wird der Browser beim Zugriff auf Google auch von Baidu ausgegebene Cookies übertragen? Oder kann Google die von Baidu ausgegebenen Cookies ändern?
Die Antwort ist nein. Cookies können keine Domänennamen überschreiten. Gemäß der Cookie-Spezifikation überträgt der Browser beim Zugriff auf Google nur die Cookies von Google, nicht jedoch die Cookies von Baidu. Google kann nur die Cookies von Google betreiben, nicht jedoch die Cookies von Baidu.
Cookies werden vom Browser auf der Clientseite verwaltet. Der Browser kann sicherstellen, dass Google nur die Cookies von Google und nicht die Cookies von Baidu betreibt, um so die Privatsphäre und Sicherheit der Nutzer zu gewährleisten. Der Browser bestimmt anhand des Domainnamens, ob eine Website das Cookie einer anderen Website bedienen kann. Die Domainnamen von Google und Baidu sind unterschiedlich, daher kann Google die Cookies von Baidu nicht betreiben.
Es ist zu beachten, dass die Website images.google.com und die Website www.google.com zwar zu Google gehören, ihre Domainnamen jedoch unterschiedlich sind und sie die Cookies des anderen nicht verwalten können.
Hinweis: Nach der Anmeldung auf der Website www.google.com wird der Benutzer feststellen, dass die Anmeldeinformationen beim Besuch von images.google.com immer noch gültig sind Mit gewöhnlichen Cookies ist dies nicht möglich. Dies liegt daran, dass Google eine spezielle Verarbeitung durchgeführt hat. Cookies werden später in diesem Kapitel ähnlich behandelt.
1.1.4 Unicode-Kodierung: Chinesisch speichern
Chinesische Zeichen unterscheiden sich von englischen Zeichen Chinesische Zeichen sind Unicode Es belegt 4 Zeichen im Speicher, während Englisch aus ASCII-Zeichen besteht und nur 2 Bytes im Speicher belegt . Bei der Verwendung von Unicode-Zeichen in Cookies müssen die Unicode-Zeichen codiert werden, da sie sonst verstümmelt werden.
Tipps: Chinesische Schriftzeichen können nur in Cookies gespeichert werden. Generell kann die UTF-8-Kodierung verwendet werden. Es wird nicht empfohlen, chinesische Kodierungen wie GBK zu verwenden, da Browser diese möglicherweise nicht unterstützen und JavaScript die GBK-Kodierung nicht unterstützt.
1.1.5 BASE64-Kodierung: Binärbilder speichern
Cookie kann nicht nur ASCII-Zeichen und Unicode-Zeichen verwenden, sondern auch Binärzeichen Daten. Beispielsweise werden in Cookies digitale Zertifikate verwendet, um die Sicherheit zu gewährleisten. Auch beim Arbeiten mit Binärdaten ist eine Kodierung erforderlich.
% Hinweis: Dieses Programm dient nur zur Demonstration, dass binäre Inhalte in Cookies gespeichert werden können und ist nicht praktikabel. Da der Browser jedes Mal, wenn er den Server anfordert, Cookies überträgt, sollte der Cookie-Inhalt nicht zu groß sein, da er sonst die Geschwindigkeit beeinträchtigt. Der Inhalt von Cookies sollte klein, aber präzise sein.
1.1.6 Alle Eigenschaften von Cookie festlegen
Zusätzlich zu Name und Wert verfügt Cookie auch über mehrere andere häufig verwendete Eigenschaften Eigentum. Jede Eigenschaft entspricht einer Getter-Methode und einer Setter-Methode. Alle Eigenschaften der Cookie-Klasse sind in Tabelle 1.1 aufgeführt.
Tabelle 1.1 Allgemeine Cookie-Attribute
Attributname |
Beschreibung |
String name |
Der Name dieses Cookies. Sobald ein Cookie erstellt wurde, kann sein Name nicht mehr geändert werden |
Objektwert |
Der Wert dieses Cookies. Wenn der Wert ein Unicode-Zeichen ist, muss das Zeichen codiert werden. Wenn es sich bei dem Wert um Binärdaten handelt, müssen Sie die BASE64-Kodierung verwenden |
int maxAge |
Die Ablaufzeit dieses Cookies in Sekunden. Wenn positiv, läuft das Cookie nach maxAge Sekunden ab. Wenn es sich um eine negative Zahl handelt, handelt es sich bei dem Cookie um ein temporäres Cookie, das beim Schließen des Browsers ungültig wird und der Browser das Cookie in keiner Form speichert. Wenn es 0 ist, bedeutet dies, dass das Cookie gelöscht wird. Standardmäßig –1 |
boolean secure |
Gibt an, ob dieses Cookie nur mithilfe sicherer Protokolle übertragen wird. Sicherheitsprotokolle. Zu den Sicherheitsprotokollen gehören HTTPS, SSL usw., die Daten verschlüsseln, bevor sie im Netzwerk übertragen werden. Der Standardwert ist false |
String path |
Der von diesem Cookie verwendete Pfad. Wenn es auf „/sessionWeb/“ gesetzt ist, können nur Programme, deren contextPath „/sessionWeb“ ist, auf das Cookie zugreifen. Wenn es auf „/“ gesetzt ist, kann über den contextPath unter diesem Domänennamen auf das Cookie zugegriffen werden. Beachten Sie, dass das letzte Zeichen „/“ sein muss |
String domain |
Der Domänenname, der auf das Cookie zugreifen kann . Wenn es auf „.google.com“ eingestellt ist, können alle Domainnamen, die mit „google.com“ enden, auf dieses Cookie zugreifen. Beachten Sie, dass das erste Zeichen „.“ sein muss. |
String-Kommentar |
Beschreibung der Verwendung dieses Cookies. Wenn der Browser Cookie-Informationen anzeigt, zeigt er diese Beschreibung an: |
int version |
Die vom Cookie verwendete Versionsnummer . 0 bedeutet, der Cookie-Spezifikation von Netscape zu folgen, 1 bedeutet, der W3C-Spezifikation RFC 2109 zu folgen |
1.1.7 Cookie-Gültigkeitsdauer
Das maxAge des Cookies bestimmt die Gültigkeitsdauer des Cookies, in Sekunden (Sekunde). In Cookie wird das Attribut maxAge über die Methoden getMaxAge() und setMaxAge(int maxAge) gelesen und geschrieben.
Wenn das maxAge-Attribut eine positive Zahl ist, bedeutet dies, dass das Cookie nach maxAge-Sekunden automatisch abläuft. Der Browser behält das Cookie mit einem positiven maxAge bei, schreibt es also in die entsprechende Cookie-Datei. Unabhängig davon, ob der Kunde den Browser oder den Computer schließt, solange maxAge Sekunden zurückliegt, ist das Cookie beim Anmelden auf der Website noch gültig. Die Cookie-Informationen im folgenden Code sind für immer gültig.
Cookie cookie = neues Cookie("username","helloweenvsfei"); // Neues Cookie
Cookie .setMaxAge(Integer.MAX_VALUE); // Setze den Lebenszyklus auf MAX_VALUE
response.addCookie(cookie); maxAge ist eine negative Zahl. Dies bedeutet, dass das Cookie nur innerhalb dieses Browserfensters und der von diesem Fenster geöffneten Unterfenster gültig ist. Das Cookie wird ungültig, nachdem das Fenster geschlossen wurde. Cookies mit einem negativen maxAge sind temporäre Cookies und werden nicht dauerhaft gespeichert oder in die Cookie-Datei geschrieben. Cookie-Informationen werden im Speicher des Browsers gespeichert, sodass das Cookie verschwindet, wenn Sie den Browser schließen. Der Standardwert für maxAge für Cookies ist -1.
Wenn maxAge 0 ist, bedeutet dies, dass das Cookie gelöscht wird. Der Cookie-Mechanismus bietet keine Methode zum Löschen von Cookies. Daher wird der Effekt des Löschens von Cookies dadurch erreicht, dass das Cookie so eingestellt wird, dass es sofort abläuft. Ungültige Cookies werden vom Browser aus der Cookie-Datei oder dem Speicher gelöscht,Hinweis: Beim Lesen des Cookies vom Client sind andere Attribute, einschließlich maxAge, nicht lesbar und werden nicht übermittelt. Wenn der Browser ein Cookie sendet, übermittelt er nur die Namens- und Wertattribute. Das maxAge-Attribut wird vom Browser nur verwendet, um festzustellen, ob das Cookie abgelaufen ist.
1.1.8 Änderung und Löschung von Cookies
Cookies ermöglichen keine Änderungs- oder Löschvorgänge. Wenn Sie ein Cookie ändern möchten, müssen Sie lediglich ein neues Cookie mit demselben Namen erstellen und es zur Antwort hinzufügen, um das ursprüngliche Cookie zu überschreiben.
Wenn Sie ein Cookie löschen möchten, müssen Sie nur ein neues Cookie mit demselben Namen erstellen, maxAge auf 0 setzen und es zur Antwort hinzufügen, um das ursprüngliche Cookie zu überschreiben. Beachten Sie, dass es 0 und keine negative Zahl ist. Negative Zahlen haben andere Bedeutungen. Im obigen Beispiel können Leser über das Programm verschiedene Attribute überprüfen und festlegen.
Hinweis: Beim Ändern oder Löschen von Cookies müssen alle Attribute des neuen Cookies außer Wert und maxAge, wie Name, Pfad, Domäne usw., vollständig identisch sein das Original-Cookie. Andernfalls behandelt der Browser sie als zwei verschiedene Cookies und überschreibt sie nicht, was dazu führt, dass Änderungen und Löschungen fehlschlagen.
1.1.9 Cookie-Domänenname
Cookies können keine Domänennamen überschreiten. Vom Domainnamen www.google.com ausgegebene Cookies werden nicht an den Domainnamen www.baidu.com übermittelt. Dies wird durch den Datenschutz-Sicherheitsmechanismus von Cookie bestimmt. Der Datenschutz-Sicherheitsmechanismus kann verhindern, dass Websites illegal Cookies von anderen Websites erhalten.
Unter normalen Umständen können zwei Domänennamen der zweiten Ebene unter demselben Domänennamen der ersten Ebene, wie z. B. www.helloweenvsfei.com und images.helloweenvsfei.com, Cookies nicht austauschbar verwenden, da die Domänennamen der beiden sind nicht unbedingt gleich. Wenn Sie möchten, dass alle Domänennamen der zweiten Ebene unter dem Namen helloweenvsfei.com dieses Cookie verwenden können, müssen Sie den Domänenparameter des Cookies festlegen, zum Beispiel:
Cookie cookie = new Cookie(" time","20080808"); // Neues Cookie
cookie.setDomain(".helloweenvsfei.com"); .setMaxAge (Integer.MAX_VALUE);
Leser können die Hosts-Datei unter C:WINDOWSsystem32driversetc auf dem lokalen Computer ändern, um mehrere temporäre Domänennamen zu konfigurieren, und dann das Programm setCookie.jsp verwenden, um das Domänenattribut für die domänenübergreifende Cookie-Überprüfung festzulegen.
Hinweis: Der Domänenparameter muss mit einem Punkt (".") beginnen. Darüber hinaus sind zwei Cookies mit demselben Namen, aber unterschiedlichen Domänen zwei verschiedene Cookies. Wenn Sie möchten, dass zwei Websites mit völlig unterschiedlichen Domänennamen Cookies gemeinsam nutzen, können Sie zwei Cookies generieren, wobei das Domänenattribut jeweils aus zwei Domänennamen besteht, und diese an den Client ausgeben.
1.1.10 Cookie-Pfad
Das Domänenattribut bestimmt den Domänennamen, der ausgeführt wird, um auf das Cookie zuzugreifen, und das Pfadattribut Bestimmt den Domänennamen, der auf den Cookie-Pfad zugreifen darf (ContextPath). Wenn Sie beispielsweise nur Programmen unter /sessionWeb/ erlauben, Cookies zu verwenden, können Sie schreiben:
Cookie cookie = new Cookie("time","20080808"); // Create a new Cookie
cookie .setPath("/session/"); // Pfad festlegen
response.addCookie(cookie); Das Pfadattribut muss mit dem Symbol „/“ enden. Zwei Cookies mit demselben Namen, aber derselben Domain sind ebenfalls zwei verschiedene Cookies.
Hinweis: Die Seite kann nur das Cookie des Pfads erhalten, zu dem sie gehört. Beispielsweise kann /session/test/a.jsp das Cookie mit dem Pfad /session/abc/ nicht abrufen. Seien Sie vorsichtig, wenn Sie es verwenden.
Das HTTP-Protokoll ist nicht nur zustandslos, sondern auch unsicher. Daten, die das HTTP-Protokoll verwenden, werden unverschlüsselt direkt im Netzwerk übertragen und können abgefangen werden. Die Verwendung des HTTP-Protokolls zur Übertragung sehr vertraulicher Inhalte birgt eine versteckte Gefahr. Wenn Sie nicht möchten, dass Cookies in unsicheren Protokollen wie HTTP übertragen werden, können Sie das sichere Attribut des Cookies auf true setzen. Browser übertragen solche Cookies nur über sichere Protokolle wie HTTPS und SSL. Der folgende Code setzt das sichere Attribut auf true:
cookie.setSecure(true);
Tipp: Das Secure-Attribut kann den Cookie-Inhalt nicht verschlüsseln und daher keine absolute Sicherheit garantieren. Wenn hohe Sicherheit erforderlich ist, muss der Cookie-Inhalt im Programm verschlüsselt und entschlüsselt werden, um ein Auslaufen zu verhindern. 1.1.12 JavaScript-Betriebs-Cookie Cookie wird auf der Browserseite gespeichert. Der Browser verfügt daher über Voraussetzungen zum Betrieb von Cookies. Browser können Skriptprogramme wie JavaScript oder VBScript verwenden, um Cookies zu betreiben. Hier nehmen wir JavaScript als Beispiel, um häufig verwendete Cookie-Vorgänge vorzustellen. Der folgende Code gibt beispielsweise alle Cookies auf dieser Seite aus. <script>document.write(document.cookie);</script> Da JavaScript Cookies beliebig lesen und schreiben kann, möchten einige gute Leute JavaScript-Programme zum Ausspionieren verwenden Benutzer-Cookies auf anderen Websites. Dies ist jedoch vergeblich. Die W3C-Organisation ist sich der Sicherheitsrisiken bewusst, die durch das Lesen und Schreiben von Cookies durch JavaScript verursacht werden. Der W3C-Standardbrowser verhindert, dass JavaScript Cookies liest und schreibt, die nicht zu ihm gehören Webseite. Mit anderen Worten: Das Lesen und Schreiben der Cookies von Website B durch das JavaScript-Programm von Website A hat keine Ergebnisse. 1.1.13 Fall: Permanente Anmeldung Wenn der Benutzer auf seinem Heimcomputer im Internet surft, kann dies der Fall sein beim Einloggen gespeichert werden. Behalten Sie seine Anmeldeinformationen bei. Sie müssen sich beim nächsten Mal nicht erneut anmelden. Sie können einfach direkt darauf zugreifen. Die Implementierungsmethode besteht darin, Anmeldeinformationen wie Kontonummer, Passwort usw. in einem Cookie zu speichern und die Gültigkeitsdauer des Cookies zu steuern. Überprüfen Sie dann die Anmeldeinformationen im Cookie beim nächsten Besuch. eine gefährlichere Wahl. Im Allgemeinen werden Passwörter und andere wichtige Informationen nicht in Cookies gespeichert . Eine Lösung besteht darin, das Passwort zu verschlüsseln und in einem Cookie zu speichern, es dann zu entschlüsseln und beim nächsten Besuch mit der Datenbank abzugleichen. Diese Lösung ist etwas sicherer. Wenn Sie das Passwort nicht speichern möchten, können Sie auch den Anmeldezeitstempel in Cookie und der Datenbank speichern und dann nur den Benutzernamen und den Anmeldezeitstempel überprüfen. In diesem Beispiel wird eine andere Lösung verwendet, die die Datenbank nur einmal beim Anmelden abfragt und die Datenbank beim Zugriff nicht mehr abfragt, um die Anmeldeinformationen in Zukunft zu überprüfen. Die Implementierungsmethode besteht darin, das Konto nach bestimmten Regeln zu verschlüsseln und zusammen mit dem Konto im Cookie zu speichern. Bei Ihrem nächsten Besuch müssen Sie lediglich feststellen, ob die Verschlüsselungsregeln des Kontos korrekt sind . In diesem Beispiel wird das Konto in einem Cookie namens „account“ gespeichert, das Konto und der Schlüssel werden mit dem MD1-Algorithmus verschlüsselt und dann in einem Cookie namens „ssid“ gespeichert. Überprüfen Sie bei der Überprüfung, ob die verschlüsselte Kontonummer und der Schlüssel im Cookie mit der SSID im Cookie übereinstimmen. Der relevante Code lautet wie folgt: <%@ page language="java"pageEncoding="UTF-8" isErrorPage="false" %> <%! private static final String KEY =":cookie@helloweenvsfei. com"; String s =. ss ==null ?"" : ss; // Wenn es null ist, leer zurückgeben 'a', 'b', 'c', ' d ',' e ',' f '}; MessageDigest.getInstance("MD 1"); // MD1 abrufen mdTemp.update(strTemp); // Daten aktualisieren byte[] md =mdTemp.digest(); Verschlüsselung * for (int i = 0; i< j; i++) { // Schleifenausgabe byte byte0 =md[i]; str[k++] =hexDigits[byte0 > ;>> 4 & 0xf]; str[k++] =hexDigits[byte0 & 0xf]; // Encryption Post string } Catch (Ausnahme e ){return null; } %> <% request.setCharacterEncoding("UTF-8"); Anforderungskodierung festlegen Response.setCharacterEncoding("UTF-8"); // Antwortkodierung festlegen String action =request.getParameter("action"); / Aktionsparameter abrufen if("login".equals(action)){ // Wenn es sich um eine Anmeldeaktion handelt String account =request.getParameter(" account"); int timeout = newInteger(request.getParameter("timeout")); // Neues Cookie erstellen accountCookie.setMaxAge (timeout); // Gültigkeitsdauer festlegen ); // Gültigkeitszeitraum festlegen Ausgabe an den Kunden currentTimeMillis()); return; } elseif("logout".equals(action)){ // Wenn ja eine Abmeldeaktion Cookie = CookieaccountCookie = neues Cookie("Konto", ""); 🎜> accountCookie.setMaxAge(0); s ' s ' s ' s ' zu ' t 's ‐ ‐ ‐ ‐ accountCookie.setMaxAge (0); Der Inhalt ist leer ssidCookie .setmaxage (0) ; Ausgabe an den Client currentTimeMillis( )); return; } boolean login = false; in String account = null; 's zu für (Cookie cookie :request.getCookies()){ // Cookies durchqueren if(cookie.getName().equals("account")) // Wenn das Cookie den Namen Account = cookie.getValue(); // Kontoinhalt speichern<🎜 trägt > } if(account != null && ssid !=null){ // Wenn weder Konto noch SSID leer sind anmelden id.equals( calcMD1(account + Key);
Verschlüsseln Sie das Konto und den Schlüssel und speichern Sie sie.
if(request.getCookies() !=null) { // Wenn Cookie nicht leer ist
account
"${ pageContext.request.requestURI }?action=logout">
"${ pageContext.request.requestURI }?action=login"method="post">
name="timeout" value="<%= 30 *24 * 60 * 60 %> ;"> 30天
内有效
"<%= Integer.MAX_VALUE %>"> 永久有效
< /form>
Dies wird erreicht, indem das Altersattribut des Cookies festgelegt und auf den Code geachtet wird. Der Laufeffekt ist in Abbildung 1.7 dargestellt.
Abbildung 1.7 Permanente Anmeldung
Zusätzlich zur Verwendung von Cookies werden Sitzungen häufig in Webanwendungen verwendet, um den Clientstatus aufzuzeichnen .
Sitzung ist ein Mechanismus, der vom Server verwendet wird, um den Status des Clients aufzuzeichnen.Er ist einfacher zu verwenden als Cookie. Außerdem erhöht der Speicherdruck des Servers.
1.2.1 Was ist Sitzung?Sitzung ist ein weiterer Mechanismus zum Aufzeichnen des Client-Status. Der Unterschied besteht darin, dass das Cookie im Client-Browser gespeichert wird wird auf dem Server gespeichert. Wenn der Client-Browser auf den Server zugreift, zeichnet der Server die Client-Informationen in irgendeiner Form auf dem Server auf. Das ist Sitzung.
Wenn der Client-Browser erneut zugreift, muss er lediglich den Status des Kunden aus der Sitzung ermitteln.
Wenn derCookie-Mechanismus die Identität des Kunden durch Überprüfung des „Reisepasses“ des Kunden ermittelt, bestätigt der Sitzungsmechanismus die Identität des Kunden durch Überprüfung der „Kundendaten“ auf dem Server. Die Sitzung entspricht einer vom Programm auf dem Server erstellten Kundendatei. Wenn ein Kunde zu Besuch kommt, muss er nur die Kundendateitabelle abfragen.
1.2.2 Benutzeranmeldung implementierenDie Klasse, die Session entspricht, ist die Klasse javax.servlet.http.HttpSession. Jeder Besucher entspricht einem Sitzungsobjekt, und alle Statusinformationen des Kunden werden in diesem Sitzungsobjekt gespeichert.
Das Sitzungsobjekt wird erstellt, wenn der Client zum ersten Mal den Server anfordert. Session ist ebenfalls ein Schlüssel-Wert-Attributpaar. Es liest und schreibt Kundenstatusinformationen über die Methoden getAttribute(Stringkey) und setAttribute(String key, Objectvalue). Rufen Sie im Servlet die Sitzung des Clients über die Methode request.getSession() ab, Zum Beispiel:
HttpSession session = request.getSession(); // Holen Sie sich das Sitzungsobjekt
session .setAttribute("loginTime", new Date()); // Attribute in Sitzung festlegen
out.println("Die Anmeldezeit ist: " +(Date)session.getAttribute("loginTime")); // Holen Sie sich das Sitzungsattribut
Anfrage kann auch getSession(boolean create) verwenden Holen Sie sich die Sitzung. Der Unterschied besteht darin, dass die Methode request.getSession() null zurückgibt, wenn die Sitzung des Kunden nicht vorhanden ist, während getSession(true) zuerst die Sitzung erstellt und dann die Sitzung zurückgibt.
Request muss in Servlet verwendet werden, um das HttpSession-Objekt programmgesteuert abzurufen. Das versteckte Sitzungsobjekt ist in JSP integriert und kann direkt verwendet werden. Wenn <%@page session="false" %> deklariert ist, ist das ausgeblendete Sitzungsobjekt nicht verfügbar. Im folgenden Beispiel wird Session zum Aufzeichnen von Kundenkontoinformationen verwendet.
Der Quellcode lautet wie folgt:
Code 1.9 session.jsp
<%@ page language="java" pageEncoding="UTF-8"%>
<%! DateFormat dateFormat = newSimpleDateFormat("yyyy-MM-dd"); // Datumsformatierer %> <% Response.setCharacterEncoding("UTF-8"); // Anfragekodierung festlegen Person[] personen = { > new Person("Liu Jinghua","password1", 34, dateFormat.parse new Person("Garfield", "garfield_pass",23, dateFormat.parse }; String message = ""; 🎜> // Grundlegende Daten durchsuchen und Kontonummer und Passwort überprüfen // Wenn der Benutzername und das Passwort korrekt sind if (Person.getName (). EqualsIgnorecase (request.getparameter ("username") && people quals (request.getParameter("password"))) } } } message = „Benutzername und Passwort stimmen nicht überein, Anmeldung fehlgeschlagen.“; %> ; // .. . Der HTML-Code ist ein FORM-Formular, der Code wird weggelassen, siehe Anmeldeschnittstelle auf der beiliegenden CD Code 1.10 Welcome.jsp <%@ page language="java" pageEncoding="UTF-8"%> ; <%! DateFormat dateFormat = newSimpleDateFormat("yyyy-MM-dd"); // Datumsformatierer %> <% Person person =(Person)session.getAttribute("person"); // Die angemeldete Person abrufen Date loginTime =(Date)session.getAttribute("loginTime"); // Anmeldezeit abrufen %> // ... Einige HTML-Codes werden weggelassen ;%=. person.getName ()% > <%=. loginTime%> Abbildung 1.8 Verwenden von Session zum Aufzeichnen von Benutzerinformationen Beachten Sie, dass Personenklassenobjekte und Date-Klassenobjekte direkt in Session im Programm gespeichert werden, was bequemer zu verwenden ist als Cookies. Wenn mehrere Clients das Programm ausführen, speichert der Server die Sitzungen mehrerer Clients. Beim Erwerb einer Sitzung muss nicht angegeben werden, wessen Sitzung erworben werden soll. Der Sitzungsmechanismus bestimmt, dass der aktuelle Client nur seine eigene Sitzung und nicht die Sitzungen anderer Personen erhält. Die Sitzungen jedes Klienten sind außerdem unabhängig voneinander und füreinander unsichtbar. Tipps: Sitzungen sind bequemer zu verwenden als Cookies, aber zu viele Sitzungen werden im Serverspeicher gespeichert, was den Server belastet . 1.2.3 Sitzungslebenszyklus Sitzung gespeichert auf der Serverseite. Um eine höhere Zugriffsgeschwindigkeit zu erreichen, speichern Server Sitzungen im Allgemeinen im Speicher. Jeder Benutzer verfügt über eine unabhängige Sitzung. Wenn der Sitzungsinhalt zu komplex ist, kann es zu einem Speicherüberlauf kommen, wenn eine große Anzahl von Clients auf den Server zugreift. Daher sollten die Informationen in der Sitzung so prägnant wie möglich sein. Sitzung wird automatisch erstellt , wenn der Benutzer zum ersten Mal auf den Server zugreift. Es ist zu beachten, dass eine Sitzung nur erstellt wird, wenn auf JSP, Servlet und andere Programme zugegriffen wird. Nur der Zugriff auf statische Ressourcen wie HTML und IMAGE führt nicht zur Erstellung einer Sitzung. Wenn noch keine Sitzung generiert wurde, können Sie auch request.getSession(true) verwenden, um die Generierung einer Sitzung zu erzwingen. SNachdem die Sitzung generiert wurde, aktualisiert der Server die letzte Zugriffszeit der Sitzung und behält die Sitzung bei, solange der Benutzer weiterhin zugreift. Jedes Mal, wenn ein Benutzer auf den Server zugreift, unabhängig davon, ob die Sitzung gelesen oder geschrieben wird, betrachtet der Server die Sitzung des Benutzers als „aktiv“. 1.2.4 Sitzungsgültigkeitsdauer Je mehr Benutzer auf den Server zugreifen, desto länger wird auch die Sitzung . Kommen Sie immer mehr. Um einen Speicherüberlauf zu verhindern, löscht der Server Sitzungen, die längere Zeit nicht aktiv waren, aus dem Speicher. Diese Zeit ist die Sitzungs-Timeout-Zeit. Wenn nach Ablauf der Zeitspanne kein Zugriff auf den Server erfolgt, läuft die Sitzung automatisch ab. Das Zeitlimit der Sitzung ist das Attribut maxInactiveInterval, das über das entsprechende getMaxInactiveInterval() abgerufen und über setMaxInactiveInterval(longinterval) geändert werden kann. Sitzungs-Timeout kann auch in web.xml geändert werden. Darüber hinaus kann die Sitzung ungültig gemacht werden, indem die Methode invalidate() der Sitzung aufgerufen wird. 1.2.5 Gängige Sitzungsmethoden Session umfasst verschiedene Methoden, die viel bequemer zu verwenden sind als Cookies. Die gängigen Sitzungsmethoden sind in Tabelle 1.2 aufgeführt. Tabelle 1.2 Gängige Methoden von HttpSession square Französischer Name 方 法 名 描 述 void setAttribute(String attribute, Object value) 设置Session属性。value参数可以为任何Java Object。通常为Java Bean。value信息不宜过大 String getAttribute(String attribute) 返回Session属性 Enumeration getAttributeNames() 返回Session中存在的属性名 void removeAttribute(String attribute) 移除Session属性 String getId() 返回Session的ID。该ID由服务器自动创建，不会重复 long getCreationTime() 返回Session的创建日期。返回类型为long，常被转化为Date类型，例如：Date createTime = new Date(session.get CreationTime()) long getLastAccessedTime() 返回Session的最后活跃时间。返回类型为long int getMaxInactiveInterval() 返回Session的超时时间。单位为秒。超过该时间没有访问，服务器认为该Session失效 void setMaxInactiveInterval(int second) 设置Session的超时时间。单位为秒 void putValue(String attribute, Object value) 不推荐的方法。已经被setAttribute(String attribute, Object Value)替代 Object getValue(String attribute) 不被推荐的方法。已经被getAttribute(String attr)替代 boolean isNew() 返回该Session是否是新创建的 void invalidate() 使该Session失效 Beschreibung void setAttribute( String Attribut, Objektwert) Sitzungsattribute festlegen. Der Wertparameter kann ein beliebiges Java-Objekt sein. Normalerweise ein Java Bean. Die Wertinformationen sollten nicht zu groß sein String getAttribute(String attribute) Enumeration getAttributeNames () Gibt den Attributnamen zurück in der Sitzung vorhanden void removeAttribute(String attribute) Sitzungsattribut entfernen String getId( ) Gibt die ID der Sitzung zurück. Die ID wird automatisch vom Server erstellt und nicht wiederholt long getCreationTime() Gibt das Erstellungsdatum der Sitzung zurück. Der Rückgabetyp ist lang und wird häufig in den Datumstyp konvertiert, zum Beispiel: Date createTime = new Date(session.get CreationTime()) long getLastAccessedTime() Gibt die letzte aktive Zeit der Sitzung zurück. Der Rückgabetyp ist long int getMaxInactiveInterval() Gibt das Sitzungszeitlimit zurück . Die Einheit ist Sekunden. Erfolgt nach dieser Zeit kein Zugriff, betrachtet der Server die Sitzung als ungültig void setMaxInactiveInterval(int second) Sitzungs-Timeout festlegen. Die Einheit ist Sekunden void putValue(String attribute, Object value) Keine empfohlene Methode. Wurde ersetzt durch setAttribute(String attribute, Object Value) Object getValue(String attribute) Nicht empfohlene Methode. Wurde ersetzt durch getAttribute(String attr) boolean isNew() Gibt zurück, ob die Sitzung neu erstellt wurde void invalidate() make this Sitzung ungültig Das standardmäßige Sitzungszeitlimit in Tomcat beträgt 20 Minuten. Ändern Sie das Timeout über setMaxInactiveInterval(int seconds). Sie können web.xml ändern, um das Standard-Timeout der Sitzung zu ändern. Ändern Sie es beispielsweise auf 60 Minuten: Hinweis: Die Einheit des Parameters 1.2.6 Sitzungsanforderungen für Browser Die Sitzung wird zwar auf dem Server gespeichert und ist für den Client transparent Der normale Betrieb erfordert weiterhin Unterstützung durch den Client-Browser. Dies liegt daran, dass Session Cookies als Identifikationsmerkmal verwenden muss. Das HTTP-Protokoll ist zustandslos und die Sitzung kann anhand der HTTP-Verbindung nicht feststellen, ob es sich um denselben Client handelt. Daher sendet der Server ein Cookie mit dem Namen JSESSIONID an den Client-Browser und sein Wert ist die ID der Sitzung (d. h. HttpSession.getId() Rückgabewert). Session verwendet dieses Cookie, um festzustellen, ob es sich um denselben Benutzer handelt. Dieses Cookie wird automatisch vom Server generiert. Sein maxAge-Attribut ist im Allgemeinen –1, was bedeutet, dass es nur innerhalb des aktuellen Browsers gültig ist und nicht zwischen Browserfenstern geteilt wird. Es wird ungültig, wenn der Browser geschlossen wird . Wenn also zwei Browserfenster auf demselben Computer auf den Server zugreifen, werden zwei verschiedene Sitzungen generiert. Ausgenommen sind jedoch neue Fenster, die durch Links, Skripte usw. innerhalb des Browserfensters geöffnet werden (d. h. Fenster, die nicht durch Doppelklicken auf das Desktop-Browsersymbol usw. geöffnet werden). Diese Art von untergeordnetem Fenster teilt das Cookie des übergeordneten Fensters und teilt daher eine Sitzung. Hinweis: Ein neues Browserfenster generiert eine neue Sitzung, außer bei untergeordneten Fenstern. Untergeordnete Fenster teilen sich die Sitzung des übergeordneten Fensters. Wenn Sie beispielsweise mit der rechten Maustaste auf einen Link klicken und im Popup-Kontextmenü „In neuem Fenster öffnen“ auswählen, kann das untergeordnete Fenster auf die Sitzung des übergeordneten Fensters zugreifen. Was passiert, wenn der Client-Browser die Cookie-Funktion deaktiviert oder keine Cookies unterstützt? Beispielsweise unterstützt die überwiegende Mehrheit der mobilen Browser keine Cookies. Java Web bietet eine weitere Lösung: Umschreiben von URL-Adressen. 1.2.7 Umschreiben von URL-Adressen Umschreiben von URL-Adressen ist eine Lösung für Clients, die keine Cookies unterstützen. Das Prinzip des Umschreibens von URL-Adressen besteht darin, die Sitzungs-ID-Informationen des Benutzers in die URL-Adresse umzuschreiben. Der Server kann die neu geschriebene URL analysieren, um die Sitzungs-ID zu erhalten. Auf diese Weise kann die Sitzung zum Aufzeichnen des Benutzerstatus verwendet werden, auch wenn der Client keine Cookies unterstützt. Die HttpServletResponse-Klasse stellt encodeURL (Stringurl) bereit, um das Umschreiben von URL-Adressen zu implementieren, zum Beispiel: TOMCAT bestimmt, ob der Client-Browser Cookies unterstützt, basierend darauf, ob die Anfrage Cookies enthält. Obwohl der Client möglicherweise Cookies unterstützt, enthält die neu geschriebene URL-Adresse weiterhin jsessionid, da bei der ersten Anfrage keine Cookies übertragen werden (da keine Cookies übertragen werden müssen). Beim zweiten Besuch hat der Server das Cookie bereits in den Browser geschrieben, sodass die URL-Adresse nach dem Umschreiben keine jsessionid enthält. 1.2.8 Die Verwendung von Cookies in Session ist verboten Da die meisten Client-Browser auf WAP keine Cookies unterstützen, ist die Verwendung von Session Ist das Cookie einfach verboten, wäre es besser, das Umschreiben von URL-Adressen einheitlich zu verwenden. Die Java-Webspezifikation unterstützt das Deaktivieren von Cookies durch Konfiguration. Hier finden Sie ein Beispiel dafür, wie Sie die Verwendung von Cookies über die Konfiguration deaktivieren können. Öffnen Sie den META-INF-Ordner im WebRoot-Verzeichnis des Projekts sessionWeb (gleiche Ebene wie der WEB-INF-Ordner, erstellen Sie ihn, falls er nicht vorhanden ist), öffnen Sie context.xml (erstellen Sie ihn, falls er nicht vorhanden ist). existieren) und bearbeiten Sie den Inhalt wie folgt: Code 1.11 /META-INF/context.xml oder Ändern Sie die globale Datei conf/context.xml von Tomcat. Die Änderungen lauten wie folgt: Code 1.12 context.xml
//Grundlegende Daten, speichern Sie die Informationen von drei Personen
neue Person("Hello Kitty","hellokitty", 23, dateFormat.parse
("1994-09-12")),
Welcome.jsp-Code lautet wie folgt: Ihr Geburtstag: t ; . Der laufende Effekt des Programms ist in Abbildung dargestellt 1.8.
Diese Methode ermittelt automatisch, ob der Client Cookies unterstützt. Wenn der Client Cookies unterstützt, wird die URL intakt ausgegeben. Wenn der Client keine Cookies unterstützt, wird die Sitzungs-ID des Benutzers in die URL umgeschrieben. Die neu geschriebene Ausgabe könnte wie folgt aussehen: Das heißt, die Zeichenfolge „;jsessionid=XXX“ wird nach dem Dateinamen und vor den URL-Parametern hinzugefügt. Wobei XXX die ID der Sitzung ist. Eine Analyse zeigt, dass die hinzugefügte jsessionid-Zeichenfolge weder Auswirkungen auf den angeforderten Dateinamen noch auf die übermittelten Adressleistenparameter hat. Wenn der Benutzer auf diesen Link klickt, wird die Sitzungs-ID über die URL an den Server übermittelt und der Server erhält die Sitzungs-ID durch Parsen der URL-Adresse. Wenn es sich um eine Seitenumleitung (Redirection) handelt, kann das Umschreiben der URL-Adresse wie folgt geschrieben werden: <% if ("administrator".equals(userName )) { Response.sendRedirect(response.encodeRedirectURL("administrator.jsp")); return; }% >Der Effekt ist derselbe wie bei Response.encodeURL(String URL): Wenn der Client Cookie unterstützt, wird die ursprüngliche URL-Adresse generiert. Wenn Cookie nicht unterstützt wird, wird die neu geschriebene Adresse mit der jsessionid generiert string wird zurückgegeben. Da die meisten mobilen Browser bei WAP-Programmen keine Cookies unterstützen, verwenden WAP-Programme das Umschreiben von URL-Adressen, um Benutzersitzungen zu verfolgen. Zum Beispiel das mobile Einkaufszentrum der UFIDA Group.