nicht angemeldet
Zurück-Buttons der Browser bei dynamischen Inhalten
Hallo
Ich beschäftige mich gerade mal sozusagen mit der Logik von den Zurück-Buttons der Internetbrowser.
Dabei habe ich hier im Forum auch schon einen schönen Beitrag gefunden, der das mal sehr fein erklärt hat.
(Leider finde ich den Beitrag nicht mehr wieder)
Dort wurde geschrieben, dass man bei Klick auf den Zurück-Button im Grunde immer zum vorherigen Zustand der Seite (wenn es denn ein dynamischer Inhalt ist) kommen sollte.
Oder eben zur vorherigen Seite, wenn es sich um nicht dynamische Inhalte handelt.
Bei Formularen, sollte es demnach ja dann so sein:
Man füllt das Formular aus.
Man sendet es ab.
Mit dem Zurück-Button kommt man wieder zum ausgefüllten Formular zurück.
Habe ich das soweit richtig verstanden, dass man also sozusagen dafür sorgen sollte, dass seine Webseiten sich bei Klick auf den Zurück-Button des Browsers so verhalten wie beschrieben?
Mich würde Eure Meinung dazu sehr interessieren.
Gruß
Ingo
-
Habe ich das soweit richtig verstanden, dass man also sozusagen dafür sorgen sollte, dass seine Webseiten sich bei Klick auf den Zurück-Button des Browsers so verhalten wie beschrieben?
Meiner Meinung nach wäre das der Idealfall, aber bei einem Loginform u.s.w müsste man eine Ausnahme machen
-> Stichwort: Sicherheit etc...-
Habe ich das soweit richtig verstanden, dass man also sozusagen dafür sorgen sollte, dass seine Webseiten sich bei Klick auf den Zurück-Button des Browsers so verhalten wie beschrieben?
Meiner Meinung nach wäre das der Idealfall, aber bei einem Loginform u.s.w müsste man eine Ausnahme machen
-> Stichwort: Sicherheit etc...Der Unterschied ist der:
urls unterliegen der History, und sind deshalb mit History-Back / History-Forward Funktionen bedienbar.
Cookies sind aber (meines Wissens) nicht Gegenstand einer History.
Anhand von Cookies kann man also nur dann feststellen, ob der Request aus dem jüngsten History Eintrag erfolgte, wenn man das entsprechend einrichtet und mit einer Serverseitigen Buchhaltung vergleicht.
Verwendet man SessionIDs die über eine session statisch sich verhalten (sich nicht ändern), dann braucht man einen Zähler.
Verwendet man sogenannte OneTime-SessionIds, so ist eine Identifikation von bereits verbrauchten Requests möglich.mfg Beat
-
Hallo
Meiner Meinung nach wäre das der Idealfall, aber bei einem Loginform u.s.w müsste man eine Ausnahme machen
-> Stichwort: Sicherheit etc...Jo stimmt, ich verstehe.
Dann muss man also z.B. bei PHP-Seiten dafür sorgen, dass der Browser bei Klick auf den Zurück-Button die Seiten aus dem Cache holt, richtig?
(Z.B. mit entsprechenden Header-Angaben).Gruß
Ingo-
Meiner Meinung nach wäre das der Idealfall, aber bei einem Loginform u.s.w müsste man eine Ausnahme machen
-> Stichwort: Sicherheit etc...Jo stimmt, ich verstehe.
Dann muss man also z.B. bei PHP-Seiten dafür sorgen, dass der Browser bei Klick auf den Zurück-Button die Seiten aus dem Cache holt, richtig?
(Z.B. mit entsprechenden Header-Angaben).Worauf du nur einen endlichen Einfluss hast, weshalb du Serverseitig prüfen musst, ob zur mit Submit gesendeter SessionID ein Eintrag "is schon eingelogged" in deiner DB vorhanden ist.
mfg Beat
-
-