Logout!
sroto
- programmiertechnik
Hi
Ich schreibe ein Loginsystem (mit sessions). Nachdem sich der User ausgeloggt hat, ist seine session zwar gelöscht, aber wenn er den "zurück"-botton" betätigt, kommt er trotzdem auf die geschütze Seite zurück, da der Browser die Seite aus dem Cache lädt. Wie kann man das verhindern?
Danke und Grüsse
sroto
Hallo,
Ich schreibe ein Loginsystem (mit sessions). Nachdem sich der User ausgeloggt hat, ist seine session zwar gelöscht, aber wenn er den "zurück"-botton" betätigt, kommt er trotzdem auf die geschütze Seite zurück, da der Browser die Seite aus dem Cache lädt. Wie kann man das verhindern?
Warum willst du das verhindern?
Wenn die Session weg ist, kann er ja nichts mehr "anrichten",
und gelesen hat er sie ja eh schon, ist doch egal, ob er sie nochmal
aus dem Cache lädt, oder?
Gruß
Alexander Brock
Hallo!
Warum willst du das verhindern?
Wenn die Session weg ist, kann er ja nichts mehr "anrichten",
und gelesen hat er sie ja eh schon, ist doch egal, ob er sie nochmal
aus dem Cache lädt, oder?
Das dachte ich zuerst auch, aber mal angenommen, es ist so ein User, den sich kein Admin wünscht, der seine Session beendet, aber das Fenster nicht schließt, und das ganze auch noch an einem Rechner, der theoretisch für Unbefugte zugänglich ist. Wenn die dann auf die Idee kommen auf Zurück zu klicken, und unser User als letztes gerade die hochgeheime Preisliste oder was auch immer zu sehen hatte, dann gibt's ein Problem.
Alles recht unwahrscheinlich, aber man muß ja alle Fälle in Betracht ziehen und ggf. ausschließen.
Gruß
Matthias
Hallo,
Wenn die dann auf die Idee kommen auf Zurück zu klicken, und unser User als letztes gerade die hochgeheime Preisliste oder was auch immer zu sehen hatte, dann gibt's ein Problem.
Da hast du selbstverständlich Recht, und deshalb schlage ich folgenden Code Schnipsel
von http://de3.php.net/manual/de/function.header.php vor:
<?php
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // Datum aus Vergangenheit
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
// immer geändert
header("Cache-Control: no-store, no-cache, must-revalidate"); // HTTP/1.1
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache"); // HTTP/1.0
?>
Hilft das irgendwie weiter?
Gruß
Alexander Brock
Hi,
Wenn die dann auf die Idee kommen auf Zurück zu klicken, und unser User als letztes gerade die hochgeheime Preisliste oder was auch immer zu sehen hatte, dann gibt's ein Problem.
Hilft das irgendwie weiter?
ich wuerde mal sagen, dass Deine in Deinem ersten Beitrag gemachten Aussagen richtig sind.
Die Gegenargumentation ist esoterisch, ja laienhaft.
Wer sich nicht abmeldet und den Rechner "abschliesst", ist selbst schuld. (Wenn die Gegenargumentation richtig waere, waere uebrigens noch das Problem zu loesen, dass der Erstbenutzer die Seite ausgedruckt hat und den Ausdruck auf seinem Schreibtisch vergessen hat.)
Wie heisst es doch so schoen: IT ist nicht dafuer da soziale Probleme zu loesen.
Gruss,
Ludger
Hallo Ludger,
Wer sich nicht abmeldet und den Rechner "abschliesst", ist selbst schuld.
Es ging um PCs, die "theoretisch für Unbefugte zugänglich" sind,
wie zum Beispiel in Bibliotheken oder Internet Cafes. Wenn ein
normaler[tm] User einen geschützten Bereich betritt, irgendwas tut,
ihn wieder verlässt und dann noch schnell irgendwas ergoogelt (ö.ä.),
warum sollte er danach den Browser schließen? Oder Cache+Verlauf
löschen? Das Problem kennen nur "wir" und wir müssen solche
Fälle leider auch in Betracht ziehen.
Gruß
Alexander Brock
Hi,
Wer sich nicht abmeldet und den Rechner "abschliesst", ist selbst schuld.
Es ging um PCs, die "theoretisch für Unbefugte zugänglich" sind,
wie zum Beispiel in Bibliotheken oder Internet Cafes. Wenn ein
normaler[tm] User einen geschützten Bereich betritt, irgendwas tut,
ihn wieder verlässt und dann noch schnell irgendwas ergoogelt (ö.ä.),
warum sollte er danach den Browser schließen? Oder Cache+Verlauf
löschen? Das Problem kennen nur "wir" und wir müssen solche
Fälle leider auch in Betracht ziehen.
dann sollte allerdings offen von semiprofessioneller Software gesprochen werden. Bei der dann allerdings Sicherheit (oder aehnliches) hoch priorisiert wird. Jedenfalls, so hoch wie moeglich. ;-)
Welche Abnehmer fordern denn sowas an?
Gruss,
Ludgr
Hallo!
Welche Abnehmer fordern denn sowas an?
Ich bezeichne mich bei weitem nicht als IT-Professional, aber genau das, was du als "laienhaft" bezeichnet hast, kommt mir gerade in meinem Laden in allen nur erdenklichen Varianten unter.
Es muß IMMER an den DAU und den GAU gedacht werden, egal wie realistisch das nun erscheint oder nicht. Als Programmierer würde ich das auch nur liebend gern als Laienhaft bezeichnen und somit verwerfen, aber bestimmte Daten müssen nun einmal (aus gesetzlichen, wettbewerblichen, politischen oder hinrissigen Gründen) auf's Äußerste gesichert werden. Kann ich nix für, is' aber meist so.
Gruß
Matthias
Hi,
Ich bezeichne mich bei weitem nicht als IT-Professional, aber genau das, was du als "laienhaft" bezeichnet hast, kommt mir gerade in meinem Laden in allen nur erdenklichen Varianten unter.
bekommst Du hinreichend Geld fuer Deine Arbeit? Wenn, ja dann bist Du ein IT-Prof, es sei denn Du machst waehrend Deiner Arbeitszeit oft etwas anderes (zum Beispiel verkaufen ;-).
Es muß IMMER an den DAU und den GAU gedacht werden, egal wie realistisch das nun erscheint oder nicht. [...]
Noeeh, eben nicht. Den Aufwand fuer den DAU investiert man besser in Weiterbildungsmassnahmen oder in wichtige Software-Features.
BTW - es wird ja in diesem Thread nun immer wieder gemunkelt, wie wichtige Sachen der DAU so macht und dass die geschuetzt werden muessen. Welche wichtigen Sachen macht der DAU denn so am Rechner und mit dem Internet verbunden vor dem Weggehen ohne sich auszuloggen?
Gruss,
Ludger
Hallo Ludger!
Noeeh, eben nicht. Den Aufwand fuer den DAU investiert man besser in Weiterbildungsmassnahmen oder in wichtige Software-Features.
Die sind meist nach kurzer Zeit bzw. wenig Anwendung schnell wieder vergessen oder gar veraltet, und ab einer bestimmten Mitarbeiterzahl lohnen sich vielleicht doch eher 100 Zeilen Programmcode (=Software-Features).
BTW - es wird ja in diesem Thread nun immer wieder gemunkelt, wie wichtige Sachen der DAU so macht und dass die geschuetzt werden muessen. Welche wichtigen Sachen macht der DAU denn so am Rechner und mit dem Internet verbunden vor dem Weggehen ohne sich auszuloggen?
Leider Gottes doch so ziemlich alles. Du kannst mir nicht erzählen, daß DAU keinen Zugang zu sensiblen Daten bekommen. Das läuft immer noch eher über die Position als über die informationstechnische Qualifikation.
Vor allem istder DAU doch auch dazu da, die Dinge zu machen, die man sich als erfahrener Nutzer nie im Leben erträumen könnte.
Gruß
Matthias
Hi
Die Gegenargumentation ist esoterisch, ja laienhaft.
Wer sich nicht abmeldet und den Rechner "abschliesst", ist selbst schuld. (Wenn die Gegenargumentation richtig waere, waere uebrigens noch das Problem zu loesen, dass der Erstbenutzer die Seite ausgedruckt hat und den Ausdruck auf seinem Schreibtisch vergessen hat.)
da werde ich mich wohl auch noch zu wort melden müssen.
an einem öffentlichen computer kann es durchaus passieren, dass jemand sich ausloggt, aber das browserfenster nicht schliesst. der nächste user kann, indem er zurück drückt, die Daten seines Vorgängers anschauen. Und der Vorgänger rechnet nicht damit, da er sich ja ausgeloggt hat. bei einigen emaildiensten kann man beispielsweise nicht mehr zurück, nachdem man sich ausgeloggt hat. Bei anderen geht es. Mich würde interessieren, wie man ersteres realisiert.
bleiben wir doch bei der Sache. es kann euch ja doch egal sein, ob es jetzt sinnvoll ist oder nicht.
grüsse
sroto
Hi,
an einem öffentlichen computer kann es durchaus passieren, dass jemand sich ausloggt, aber das browserfenster nicht schliesst. der nächste user kann, indem er zurück drückt, die Daten seines Vorgängers anschauen.
die "Loesung" wird immer suboptimal bleiben, mehr wollte ich ja gar nicht anmerken.
bei einigen emaildiensten kann man beispielsweise nicht mehr zurück, nachdem man sich ausgeloggt hat. Bei anderen geht es. Mich würde interessieren, wie man ersteres realisiert.
Vielleicht haben es die genannten tatsaechlich so realisiert, wie beschrieben.
Aber
"IT ist nicht dafuer da soziale Probleme zu loesen."
hoert sich doch gut an, oder?
bleiben wir doch bei der Sache. es kann euch ja doch egal sein, ob es jetzt sinnvoll ist oder nicht.
In diesem Fall blieb ich bei der Sache.
Gruss,
Ludger
hi alexander
Da hast du selbstverständlich Recht, und deshalb schlage ich folgenden Code Schnipsel
von http://de3.php.net/manual/de/function.header.php vor:<?php
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // Datum aus Vergangenheit
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
// immer geändert
header("Cache-Control: no-store, no-cache, must-revalidate"); // HTTP/1.1
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache"); // HTTP/1.0
?>Hilft das irgendwie weiter?
Ja! Danke vielmals! Genau das suchte ich. Funktioniert tadellos. Nur in Opera nicht. Aber immerhin im IE und Netscape.
Viele Grüsse
sroto
Hi,
Ja! Danke vielmals! Genau das suchte ich. Funktioniert tadellos. Nur in Opera nicht. Aber immerhin im IE und Netscape.
das ist ja gerade der Wurm: funktioniert super ... aber nicht immer.
Ich vermute eben, dass das benannte Problem ein Problem der Realitaet ist und nicht mit den Mitteln der IT effizient bearbeitet werden kann.
Gruss,
Ludger
Hi,
Ja! Danke vielmals! Genau das suchte ich. Funktioniert tadellos. Nur in Opera nicht. Aber immerhin im IE und Netscape.
Weil in DEINEN Exemplaren des IE und des Netscape zufällig günstige Einstellungen bezüglich des Caching gegeben sind.
Was das Caching angeht, hast Du wenig Einfluß.
Caching muß ja auch nicht nur im Browser stattfinden, es kann ja auch auf einem Proxy zwischen dem Browser und dem Server stattfinden ...
cu,
Andreas
Hi,
Das dachte ich zuerst auch, aber mal angenommen, es ist so ein User, den sich kein Admin wünscht, der seine Session beendet, aber das Fenster nicht schließt, und das ganze auch noch an einem Rechner, der theoretisch für Unbefugte zugänglich ist. Wenn die dann auf die Idee kommen auf Zurück zu klicken, und unser User als letztes gerade die hochgeheime Preisliste oder was auch immer zu sehen hatte, dann gibt's ein Problem.
Naja, die Preisliste (oder was auch immer) hätte der User aber auch ausdrucken können oder lokal speichern können.
cu,
Andreas
schau dir die php methoden:
session_destroy
und
session_unset
an! ;)
Hallo joah!
schau dir die php methoden:
session_destroy
und
session_unsetan! ;)
Das hat sroto doch wohl auch gemacht, die helfen auch bei gecachten Seiten nicht weiter.
Gruß
Matthias
Hello,
Ich schreibe ein Loginsystem (mit sessions). Nachdem sich der User ausgeloggt hat, ist seine session zwar gelöscht, aber wenn er den "zurück"-botton" betätigt, kommt er trotzdem auf die geschütze Seite zurück, da der Browser die Seite aus dem Cache lädt. Wie kann man das verhindern?
Das liegt daran, dass Du Session und Login durcheinanderbringst.
Eine Session hat erstmal nichts mit einem Login zu tun.
Das Login setzt später auf der Session auf, aber nicht umgekehrt.
PHP unterstützt Sessions in der Form, dass alle Seiten, die mit Session an den Browser ausgeliefert werden, diesen auch "höflich bitten", die Seite nicht im Cache abzulegen. Ob der Browser (und/oder alle Proxies auf der Strecke) sich daran hält, ist seine Sache.
Wenn Du also ALLE Seiten, die nicht cached werden sollen, grundsätzlich mit Session beginnst, dann sollte es im allgemeinen klappen. Dazu musst Du aber Dein Loginkonzept erstmal reparieren.
Der Client behält seine Session dann solange, bis er keine Lust mehr hat.
Man muss die Session nicht killen, wenn der Client sich abmeldet. Wenn man es tut, muss man aber auch dem Client einen leeren "Session-Cookie" senden, sofern man mit Cookies arbeitet. Das übersetzt PHP dann so, dass es den Cookie beim Client löschen setzt mit der Response.
Wichtig ist nur, dass man beim relogin die Sessiondatei LEERT, damit nicht ggf. ein neuer User auf der Sessiondatei des letzten arbeitet, und so an Daten gelangt, die ihm nicht gehören.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom