nicht angemeldet
Guten Morgen!
[...]
- Das man an zwei Stellen speichert hört sich gut an, was ich aber nicht verstehe, wenn zwei Seiten geladen würden, warum man zweimal denselben Token erhält?
Ich denke, hier ist es so gemeint, dass zwei Requests, die von der selben Ursprungsseite kommen (User war zu ungeduldig und klickt nochmal oder arbeitet mit Browser Back und Forward), das selbe Token schicken. Wenn dieses Token aber schon mal verarbeitet wurde, darf eine zweite Verarbeitung nicht stattfinden. Dieses Pattern ist in meinen Augen aber nur für wenige Einzelfälle von Bedeutung. In der Mehrzahl der Fälle sollte man seine Seiten so implementieren, dass der Anwender auch mit der Browser Vor- und Zurück-Steuerung arbeiten kann.
- Diese zwei Zeilen habe ich auch nicht ganz verstanden
HttpSession session = getSession(request);
String token = getToken();
Beide Methoden müssen innerhalb der Klasse (üblicherweise Servlet) definiert sein, weil sie nicht aus dem Standard API von JSP / Servlets kommen. Häufig kapselt man das ermitteln der Session, wenn man noch zusätzliche Arbeiten an der Session oder beim Ermitteln der Session ausführen möchte, bevor sie der aufrufenden Komponente übergeben (üblicherweise Servlet) wird.
Allgemein Listener und Handler muss ich mir auch noch anschauen. In den Handlern wäre ja der Code von oben drin. Handler praktisch alle JSP-Seiten, die es im Projekt gibt?
Das zeugt von schlechtem Stil und lässt mich an dem Tutorial zweifeln. Ein Handler sollte zunächst ein Servlet (oder bei Verwendung eines entsprechenden Frameworks eine Action oder ein Controller) sein. Die JSP ist ausschließlich für die Darstellung der Informationen zuständig und sollte keinen Quellcode enthalten.
Listener reagieren automatisch oder muss man die irgendwie implementieren/aufrufen?
Die reagieren "automatisch", wobei das heißt, dass der Servlet Container die entsprechende Listener-Methode aufruft, wenn ein belauschtes Ereignis eingetreten ist. Der Servlet Container sagt also z.B. allen registrierten SessionContextListener-Implementierungen, wenn der ServletContext initialisiert oder zerstört wurde (vom Servlet Container, deshalb kann der auch Bescheid sagen, weil er es weiß).
- Als große Sicherheit bei Session ist ja immer die Rede von "Ursprungsregel". Was meint man damit genau? Wenn ein Client/Anfrager die URL des Servers aufruft und nicht über eine andere Domain aufruft? Habe ich nicht so ganz gecheckt.
Ich kenne jetzt den Begriff "Ursprungsregel" nicht, würde ihn aber sogar ein wenig weiter fassen als nur den Referrer auf eine Domain zu prüfen. In einer komplexen Webanwendung kann der Benutzer bestimmte Seiten nur ein einem definierten Kontext aufrufen (z.B. mehrseitiger Assistent bei einer Benutzerregistrierung). Wenn jetzt ein Request für die dritte Seite ankommt, und der Benutzer kommt nicht von der zweiten, ist das ein Fehler. Wobei hier eine Prüfung nur auf den Referrer nicht ausreicht (weil clientabhängig), hier muss man dann schon als Entwickler ein entsprechendes Token mitgeben.
Schöne Grüße,
Peter