Seite 1 von 1

das alte "Seite ist nicht mehr aktuell" Problem

Verfasst: 30.07.2007 13:39
von Xwitz
Hallo, ich vermute mal hier kennen sich einige mit Sessions aus.

Ich habe eine Art Chatbot in php geschrieben und der funktioniert mittlerweile auch einwandfrei. Nun wollte ich ihn ein wenig erweitern und dazu sessions benutzen. Das Problem ist nur, wenn man dann im IE oder FF auf zurück klickt, ist die Seite nicht mehr aktuell bzw. sollen die Formulardaten neu gesendet werden.

Nun habe ich schon drei Tutorials gelesen, in denen nicht darauf eingegangen wird. Ich habe 15 bis 20 Threads in verschiedenen Foren gelesen, in denen es heißt, das liegt an den Post-Daten. Fakt ist aber, trotz Post-Formular kann man sich problemlos durch die, durch Formulardaten generierten, Seiten vor und zurück klicken ohne die Daten neu zu senden nur wenn man Sessions verwendet geht das nicht mehr. Ich habe es auch schon mit oder ohne Cookies versucht aber das hilft nichts.

Einer hat etwas von "günstigeren Cache-Empfehlungen" geschrieben, wozu ich aber nichts weiter finden konnte.

Ich möchte nicht auf die Möglichkeit verzichten sich nachträglich durch das "Gespräch" klicken zu können. Warum funktioniert das ohne Sessions aber nicht mit? Welche Abhilfe gibt es außer einem Redirect noch?

Verfasst: 30.07.2007 16:33
von Pyramide
Du könntest doch einfach die gesamte Chathistorie auf der Seite anzeigen und nicht immer nur eine Zeile.

Verfasst: 31.07.2007 10:49
von Xwitz
Über sowas und ähnliches habe ich ausreichend nachgedacht (es ist nur so was ähnliches wie ein Chatbot), ich suche eine Lösung für das genannte Problem. Auch Ausweichmöglichkeiten, wie einen Session-Ersatz über mysql mit ID-Übergabe mittels Formular sind mir bewußt.

Wieso verhält sich der Browser mit Session und Post-Daten anders als nur mit Post-Daten? Wie kann man das Verhalten ändern? Falls das mit Cache-Empfehlung gemeint war, wie könnte man dem Browser vermitteln, er soll die Seite vom letzten Aufruf aus dem Cache nehmen (falls der User nicht gerade explizit was anderes eingestellt hat)?

EDIT: Was ich noch anmerken wollte, es werden keine sensiblen Daten gespeichert und keine besonderen Rechte eingeräumt, auf session-Sicherheit muß also keine besondere Rücksicht genommen werden.

Verfasst: 31.07.2007 17:30
von Xwitz
Ich habe es jetzt doch noch über drei Ecken gefunden.

Code: Alles auswählen

session_cache_limiter('private_no_expire');
Ich dachte das wären Einstellungen, die irgendwie irgendwas intern bewirken. Die Seiten auf die ich vorher gestoßen bin waren bei der Erklärung und Bedeutung der Parameter nicht hilfreich.

Verfasst: 31.07.2007 19:53
von Pyramide
Da es aber unzählige Browser mit eben so vielen Einstellungsmöglichkeiten gibt, kannst du nie 100% sicher gehen, wann wo welche Sicherheitsabfrage angezeigt wird. Gerade bei den Themen POST und Cache-Header kann es sein, daß 3 Browser sich beim Aufruf der selben Seite auf 4 verschiedene Arten verhalten. Der Internet Explorer zeigt z.B. in Werkseinstellung sogar eine Warnung an, wenn man eine https-Seite aufruft (sinngemäß "Warnung, sie bauen jetzt eine sichere Verbindung auf") :roll: .

Verfasst: 01.08.2007 08:19
von Xwitz
Vielleicht gibt es auch einen Browser der um Formulardaten ein Schleifchen bindet statt sie abzuschicken, ganz ohne Sessions und Cache-Header. :o Was die Einstellmöglichkeiten angeht, siehe "falls nicht explizit was anderes angegeben wird". Außerdem sollen Browser vor allem mit dem Parameter 'privat' Probleme haben, weshalb 'private_no_expire' empfolen wird, da dann kein Expire-Header gesendet wird.
http://www.php-homepage.de/manual/funct ... imiter.php

Im IE 6 und 7, FF und Opera (da ging es schon vorher) geht es jedenfalls. Falls doch noch Probleme auftauchen werde ich das hier anmerken.

EDIT: SeaMonkey auch, mehr Browser habe ich gerade nicht. Die Benutzer von Exoten wissen oft auch was sie tun und zu erwarten haben.

EDIT 2: beim safari 3 beta für PC funktioniert es nicht, der will die Daten neu senden (das will er aber auch ohne sessions).