12. MVC-Webanwendung [person] – Version 7
12.1. Einführung
In dieser Version gehen wir davon aus, dass es Client-Browser geben kann, bei denen Folgendes deaktiviert ist:
- das Senden von Cookies vom Server
- die Ausführung von JavaScript-Code, der in die angezeigten HTML-Seiten eingebettet ist
Dennoch möchten wir, dass diese Art von Browsern unsere Anwendung nutzen kann. Punkt 2 führt uns zurück zu Version 2 unserer Anwendung, da JavaScript erst ab Version 3 eingeführt wurde. In Version 2 lief die Anwendung ohne JavaScript, sodass Punkt 2 damit gelöst ist.
Punkt 1 kann schwierig zu handhaben sein oder auch nicht. Version 6 unserer Anwendung funktionierte ohne Cookies. Durch die Zusammenführung der Versionen 2 und 6 erreichen wir das gewünschte Ergebnis. Wir fügen eine zusätzliche Einschränkung hinzu: Die Anwendung muss eine Sitzung verwalten. Dies ist keine bedeutungslose Einschränkung. In einer Anwendung, in der sich Benutzer authentifizieren müssen, muss der Server den Benutzernamen und das Passwort des Benutzers speichern, um zu verhindern, dass sie sich auf jeder angeforderten Seite neu authentifizieren müssen.
Bisher haben wir drei Lösungen verwendet, um Informationen während des Client-Server-Austauschs zu speichern:
- die Sitzung
- Cookies
- versteckte Felder.
Lösung 2 kann ausgeschlossen werden, da der Browser des Clients Cookies möglicherweise deaktiviert hat.
Lösung 3 ist die aus Version 6, die wir zuvor untersucht haben. Sie kann aus Sicherheitsgründen nicht verwendet werden. Wenn das Login-Passwort-Paar in jede an den Browser gesendete Seite eingebettet ist, bedeutet dies, dass es bei jedem Client-Server-Austausch über das Netzwerk übertragen wird. Dies ist für die Sicherheit der Anwendung nicht gut. Wir könnten dann die Verwendung des HTTPS-Protokolls in Betracht ziehen, das den Austausch zwischen Client und Server verschlüsselt. Die Verwendung für jede Seite der Anwendung erhöht jedoch die Serverlast.
Möglicherweise möchten Sie Lösung 1 ausschließen, da sie ebenfalls auf Cookies basiert. Beim ersten Client-Server-Austausch sendet der Server dem Client ein Session-Token, das der Client dann bei jeder neuen Anfrage an den Server zurücksendet. Dank dieses Tokens kann der Server den Client erkennen und ihm Informationen bereitstellen, die er bei einem früheren Austausch gespeichert hatte. Das Session-Token wird vom Server in einem Cookie gesendet. Ein Browser, der Cookies nicht deaktiviert hat, kann dieses Cookie bei nachfolgenden Anfragen an den Server zurücksenden. Sind Cookies deaktiviert, gibt es eine andere Lösung: Der Browser kann das Session-Token in die angeforderte URL einfügen. Genau das sehen wir nun, wenn wir uns die Datei [index.jsp] aus Version 4 noch einmal ansehen:
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<%@ taglib uri="/WEB-INF/c.tld" prefix="c" %>
<c:redirect url="/main"/>
Zur Erinnerung: Die obige Zeile 5 leitet den Client an die URL [/personne4/main?jsessionid=XX] weiter, wobei XX das Sitzungstoken ist, wie im folgenden Screenshot zu sehen ist, der nach dem Aufruf der URL [http://localhost:8080/personne4] erstellt wurde:
Schauen wir uns einmal genauer an, wie das <c:redirect>-Tag in Bezug auf das Session-Token funktioniert. Verwenden wir dazu einen Browser, der Cookies akzeptiert. Im Folgenden konfigurieren wir den Firefox-Browser:
In [1] aktivieren wir Cookies, und in [2] löschen wir alle vorhandenen, um von einem bekannten Zustand auszugehen. Dann rufen wir die URL [http://localhost:8080/personne4] auf. Wir erhalten die folgende Antwort:
Die ursprüngliche HTTP-Anfrage des Clients lautete wie folgt:
Beachten Sie, dass der Client kein Sitzungscookie sendet. Die vom Server gesendete HTTP-Antwort lautet wie folgt:
- Zeile 1: Der Server fordert den Client auf, umzuleiten
- Zeile 3: Der Server sendet ein Sitzungstoken, das mit dem Attribut [JSESSIONID] verknüpft ist
- Zeile 4: Die Weiterleitungs-URL enthält das Sitzungstoken. Das <c:redirect>-Tag hat es dort platziert, da der Client kein Sitzungscookie gesendet hatte.
Der Browser, der zur Weiterleitung aufgefordert wurde, stellte daraufhin die folgende Anfrage:
- Zeile 1: Es wird die Weiterleitungs-URL angefordert, einschließlich des Sitzungstokens. Deshalb zeigt der Browser diese URL im Screenshot an.
- Zeile 10: Der Browser sendet das Sitzungstoken zurück, das der Server ihm im vorherigen Austausch gesendet hat. So funktionieren Cookies normalerweise, wenn sie im Browser des Clients aktiviert sind. Sind sie nicht aktiviert, werden die empfangenen Cookies nicht zurückgesendet.
Der Server antwortete auf diese zweite Anfrage mit Folgendem:
Die angeforderte Seite wurde gefunden und wird gesendet. Beachten Sie, dass das Session-Token nicht mehr gesendet wird. So funktionieren Session-Token normalerweise: Der Server sendet es einmal in Form eines Cookies an den Browser, und der Browser sendet es dann bei jeder Anfrage zurück, um erkannt zu werden.
Rufen wir nun mit demselben Browser die URL [http://localhost:8080/personne4] erneut auf, indem wir sie manuell eingeben. Wir erhalten dann die folgende Seite:
Wir sehen, dass die vom Browser angezeigte URL das Session-Token nicht mehr enthält. Schauen wir uns den ersten Client-Server-Austausch an:
Der Browser hat die folgende Anfrage gestellt:
Dies ist genau dieselbe Anfrage wie die vorherige, mit einem Unterschied: In Zeile 10 sendet der Browser das Sitzungstoken zurück, das er beim allerersten Austausch erhalten hat. Auch dies ist ein normales Verhalten, wenn die Cookies des Browsers aktiviert sind.
Der Server hat die folgende Antwort gesendet:
Es weist den Client an, die Weiterleitung durchzuführen. Da es ein Sitzungstoken vom Client erhalten hat, setzt es die Sitzung fort und sendet kein neues Sitzungstoken. Aus demselben Grund enthält das <c:redirect>-Tag dieses Sitzungstoken nicht in der Weiterleitungs-URL. Deshalb enthält die im obigen Screenshot gezeigte URL kein Sitzungstoken.
Die wichtigste Erkenntnis aus all dem ist die folgende Regel: Das <c:redirect>-Tag fügt das Sitzungstoken nur dann in die Weiterleitungs-URL ein, wenn der Client den HTTP-Header nicht gesendet hat:
Diese Regel gilt auch für das <c:url>-Tag, auf das wir später noch eingehen werden.
Was passiert mit einem Browser, in dem Cookies deaktiviert wurden? Probieren wir es aus. Zunächst setzen wir den Browser zurück:
In [1] deaktivieren wir Cookies, und in [2] löschen wir alle vorhandenen, um von einem bekannten Zustand auszugehen. Dann rufen wir die URL [http://localhost:8080/personne4] auf. Wir erhalten folgende Antwort:
Wir erhalten das gleiche Ergebnis wie zuvor. Die HTTP-Kommunikation ist jedoch nicht genau dieselbe:
- Zeilen 1–9: Die erste Anfrage des Browsers. Es wird kein Session-Cookie gesendet.
- Zeilen 11–17: Die Antwort des Servers, die den Browser anweist, zu einer anderen URL umzuleiten. Er sendet ein Sitzungscookie. Zeile 13: Das <c:redirect>-Tag hat das Token in die Umleitungs-URL in Zeile 14 aufgenommen.
- Zeilen 19–27: Die zweite Anfrage des Browsers. Er sendet das soeben vom Server gesendete Sitzungscookie nicht zurück, da seine Cookies deaktiviert sind.
- Zeilen 29–33: Die Antwort des Servers. Wir sehen, dass der Server, obwohl der Browser kein Sitzungscookie gesendet hat, nicht wie erwartet eine neue Sitzung startet. Dies geht daraus hervor, dass er den HTTP-Header [Set-Cookie] nicht wie in Zeile 13 sendet. Das bedeutet, dass er die vorherige Sitzung fortsetzt. Er konnte diese Sitzung dank des Sitzungstokens abrufen, das in der vom Browser in Zeile 19 angeforderten URL enthalten war.
Beachten Sie, dass der Server eine Sitzung nachverfolgt, indem er das vom Client gesendete Sitzungstoken auf zwei mögliche Arten abruft:
- im vom Client gesendeten [Set-Cookie]-HTTP-Header
- in der vom Client angeforderten URL
Rufen wir nun mit demselben Browser die URL [http://localhost:8080/personne4] erneut auf, indem wir sie manuell eingeben, genau wie wir es getan haben, als Cookies aktiviert waren. Wir erhalten dann die folgende Seite:
Das Ergebnis unterscheidet sich von dem, was wir gesehen haben, als Cookies zugelassen waren: Das Sitzungstoken befindet sich in der vom Browser angezeigten URL. Lassen Sie uns dieses Ergebnis erklären, ohne die stattgefundenen HTTP-Austausche zu untersuchen:
[Cookies aktiviert]
- Bei der zweiten Anfrage für die URL [http://localhost:8080/personne4] hat der Client-Browser das Sitzungs-Cookie zurückgesendet, das er bei der ersten Anfrage für dieselbe URL vom Server erhalten hatte. Das <c:redirect>-Tag hat daher das Sitzungstoken nicht in die Weiterleitungsadresse aufgenommen.
[Cookies deaktiviert]
- Bei der zweiten Anfrage für die URL [http://localhost:8080/personne4] sendet der Client-Browser das Sitzungs-Cookie, das er bei der ersten Anfrage für dieselbe URL vom Server erhalten hat, nicht mit, da seine Cookies deaktiviert sind. Das <c:redirect>-Tag fügt daher das Sitzungs-Token in die Weiterleitungs-URL ein. Aus diesem Grund ist es im obigen Screenshot zu sehen.
Mit den Tags <c:redirect> und <c:url> können Sie das Session-Token in URLs einfügen. Dies ist die hier vorgeschlagene Lösung.
12.2. Das Eclipse-Projekt
Um das Eclipse-Projekt [mvc-personne-07] für die Webanwendung [/personne7] zu erstellen, duplizieren Sie das Projekt [mvc-personne-06], indem Sie die in Abschnitt 6.2 beschriebene Vorgehensweise befolgen.
 |  |
12.3. Konfigurieren der Webanwendung [personne7]
Die Datei web.xml für die Anwendung /personne7 sieht wie folgt aus:
<?xml version="1.0" encoding="UTF-8"?>
...
<display-name>mvc-personne-07</display-name>
...
Diese Datei ist identisch mit der in der vorherigen Version, mit Ausnahme von Zeile 3, wo sich der Anzeigename der Webanwendung in [mvc-personne-07] geändert hat. Die Startseite [index.jsp] bleibt unverändert.
...
<c:redirect url="/do/formulaire"/>
12.4. Der View-Code
Die Ansichten [Formular, Antwort, Fehler] kehren zu ihrem Zustand in Version 2 zurück, d. h. ohne JavaScript. Sie behalten jedoch die JSTL-Tags aus den neuesten Versionen bei.
12.4.1. Die [form]-Ansicht
Die mit JavaScript-Code verknüpften Schaltflächen wurden entfernt.
[form.jsp]:
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<%@ taglib uri="/WEB-INF/c.tld" prefix="c" %>
<html>
<head>
<title>Personne - formulaire</title>
</head>
<body>
<center>
<h2>Personne - formulaire</h2>
<hr>
<form name="frmPersonne" action="<c:url value="validationFormulaire"/>" method="post">
<table>
<tr>
<td>Nom</td>
<td><input name="txtNom" value="${nom}" type="text" size="20"></td>
</tr>
<tr>
<td>Age</td>
<td><input name="txtAge" value="${age}" type="text" size="3"></td>
</tr>
<tr>
</table>
<table>
<tr>
<td><input type="submit" name="bouton" value="Envoyer"></td>
<td><input type="reset" value="Rétablir"></td>
<td><input type="submit" name="bouton" value="Effacer"></td>
</tr>
</table>
</form>
</center>
</body>
</html>
- Zeile 14: Die POST-Ziel-URL wird mit dem <c:url>-Tag geschrieben, damit das Session-Token enthalten ist, falls der Client ein Browser ist, der den [Cookie]-HTTP-Header nicht sendet.
- Das Formular verfügt über zwei [submit]-Schaltflächen: [Submit] (Zeile 28) und [Clear] (Zeile 30). Beide Schaltflächen haben denselben Namen: button. Wenn der POST-Befehl ausgelöst wird, sendet der Browser den Parameter:
- button=Submit, wenn der POST-Befehl durch die Schaltfläche [Submit] ausgelöst wurde
- button=Clear, wenn der POST-Befehl durch die Schaltfläche [Clear] ausgelöst wurde
Dieser Parameter hilft uns dabei, die genaue Aktion zu bestimmen, da die URL [/do/validationFormulaire] nun zwei unterschiedlichen Aktionen entspricht.
12.4.2. Die Ansicht [response]
[response.jsp]:
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<%@ taglib uri="/WEB-INF/c.tld" prefix="c" %>
<html>
<head>
<title>Personne</title>
</head>
<body>
<h2>Personne - réponse</h2>
<hr>
<table>
<tr>
<td>Nom</td>
<td>${nom}</td>
</tr>
<tr>
<td>Age</td>
<td>${age}</td>
</tr>
</table>
<br>
<a href="<c:url value="retourFormulaire"/>">${lienRetourFormulaire}</a>
</body>
</html>
- Zeile 24: Die Ziel-URL des HREF-Tags wird mithilfe des <c:url>-Tags geschrieben, damit das Session-Token enthalten ist, falls es sich bei dem Client um einen Browser handelt, der den [Cookie]-HTTP-Header nicht sendet.
12.4.3. Die Ansicht [errors]
[errors.jsp]:
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<%@ taglib uri="/WEB-INF/c.tld" prefix="c" %>
<html>
<head>
<title>Personne</title>
</head>
<body>
<h2>Les erreurs suivantes se sont produites</h2>
<ul>
<c:forEach var="erreur" items="${erreurs}">
<li>${erreur}</li>
</c:forEach>
</ul>
<br>
<a href="<c:url value="retourFormulaire"/>">${lienRetourFormulaire}</a>
</body>
</html>
- Zeile 18: Die HREF-Ziel-URL wird mithilfe des <c:url>-Tags geschrieben, damit das Session-Token enthalten ist, falls der Client ein Browser ist, der den [Cookie]-HTTP-Header nicht sendet.
Leser sind eingeladen, diese neuen Ansichten mit dem gleichen Ansatz wie in früheren Versionen zu testen.
12.5. Der [ServletPersonne]-Controller
Der [ServletPersonne]-Controller für die Webanwendung [/personne7] sieht wie folgt aus:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 | |
- Zeile 35: Die Aktion [/retourFormulaire] wird über eine GET-Anfrage ausgeführt und nicht wie in der vorherigen Version über eine POST-Anfrage.
- Zeilen 70–87: Die Aktion [/validationFormulaire] wird durch eine POST-Anfrage ausgelöst, die durch das Klicken auf eine der Schaltflächen [Envoyer] oder [Effacer] in der Ansicht [form] verursacht wird. Die Methode [doValidationFormulaire] behandelt diese beiden Fälle mit zwei unterschiedlichen Methoden.
- Zeilen 90–103: Die Methode [doEnvoyer] entspricht der Methode [doValidationFormulaire] aus der vorherigen Version. Die eingegebenen Daten werden in der Sitzung gespeichert (Zeilen 96–98), während sie in der vorherigen Version in der Anfrage abgelegt wurden.
- Zeilen 58–67: Die neue Methode [doEffacer] muss ein leeres Formular anzeigen. Wir könnten die Methode [doInit] aufrufen, die diese Aufgabe bereits übernimmt. Hier nutzen wir die Gelegenheit, auch die Elemente [name, age] aus der Sitzung zu löschen, damit diese weiterhin den aktuellen Zustand des Formulars widerspiegelt.
- Zeilen 50–55: Fordern die Anzeige der Ansicht [form] an, ohne dass das Modell der Ansicht offensichtlich initialisiert wird. Dieses Modell setzt sich tatsächlich aus den Elementen [name, age] zusammen, die sich bereits in der Sitzung befinden. Es sind keine weiteren Maßnahmen erforderlich.
12.6. Tests
Starten oder starten Sie Tomcat neu, nachdem Sie das Eclipse-Projekt [personne-mvc-07] darin integriert haben, und rufen Sie dann die URL [http://localhost:8080/personne7] mit einem Browser auf, bei dem Cookies deaktiviert und vorhandene Cookies gelöscht sind. Sie erhalten folgende Antwort:
Der vom Browser empfangene Quellcode lautet wie folgt:
Zeile 1: Das Session-Token befindet sich in der POST-Ziel-URL.
Füllen wir das Formular aus und senden wir es ab:
Der vom Browser empfangene Quellcode lautet wie folgt:
Zeile 3: Das Sitzungstoken befindet sich in der Ziel-URL des Links.