nicht angemeldet
Hi,
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.
danke. genau, wenn man zurück geht hätte man ein veraltetes Token. Das ist mir klar. Nicht so ganz klar ist, wie man zwei JSP-Seiten erzeugen kann, wo man zwei "gleiche" Tokens erhält, wie in dem Tutorial beschrieben.
- 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.
Kapseln --> Erben ?
Normalerweile sollte die Zeile oben ja eher so aussehen:
HttpSession session = request.getSession(false);
und nicht
HttpSession session = getSession(request);
deshalb frage ich mich, wie man direkt eine Methode ohne xyz aufrufen kann?
xyz.getSession();
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.
Das stimmt. Auf den ersten Seiten des Tutorials wurde auch erst das MVC erklärt. Vielleicht geht es später auch in die Richtung. Hoffe ich mal, nicht, dass ich ein Dreck lerne :-)
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ß).
Oki, bevor ich mich in diesen Bereich mit Fragen vertiefe, schaue ich mir lieber den Bereich nochmal an, da ich noch keine Zeit hatte, mir nochmals das ganze mit Extends, Implements, Abstract usw. anzuschauen.
In der Antwort steht ja auch SessioContectListener-Implementierungen, wo ich evtl. meine Probleme hätte. Ich schau mir das an und stelle meine Frage dann zielgerichteter. (Wie ich was registriere)
Kann man in etwa spezifisieren, wer der Servlet-Container ist, da in vielen Tutorials die Rede von Servlet-Container ist, aber nicht wirklich erklärt wurde. Man hat ja eigene JSP's und Servlets. Ist der Container von Tomcat?
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.
Ich habe mich vertippt, das sollte "Ursprungsserver" heißen. Weiteres Zitat:
"
Sendet der Browser ein Cookie mit, so geben sowohl der Tag als auch die beiden encodeURL-Methoden die URL unverändert zurück. D.h. URL-Rewriting wird nur angewendet, wenn der Client kein Cookie sendet. Außerdem achten beide angebotenen Hilfsmittel darauf, dass URL-Rewriting nur bei Links verwendet wird, die wieder gegen den Ursprungsserver gehen. Dies ist eine wichtige Sicherheitsvorkehrung, würde man doch sonst seine Session-Kennung Links beifügen, die diese nicht nur nicht benötigen, sondern besser auch gar nicht haben sollten. Mehr zur Sicherheitsproblematik bei Sessions etwas weiter unten.
"
Evtl. habe ich das so verstanden, dass ich auf "meinem" Server auch Links auf externe Server per URL-Rewriting eine Session-ID auf einen externen/fremden Server kodieren kann. Deshalb sollte man URL-Rewriting immer nur auf den Ursprungsserver, also auf meinen Server anwenden?
Wie in etwa läuft dann Session-Hijacking.
Ein Hacker X schleust in meinen Server, bzw. in den Code (Bsp. Gästebücher) Javascript-Code, wo er von einem Benutzer/Client, der grad die Seite besucht per document.cookie die Session-ID ausliest und klaut.
Was genau hat dies aber mit dem img-tag an sich? Wenn der Hacker X ein img-tag mit einem fremdbild von seinem eigenen Server lädt, wie transportiert er hier nun die Session-ID, geschweige liest er sie vom Client aus?
Viele Grüße
Der Michi