Logout vor dem Schließen des Browsers erzwingen

[Yeti]

Hallo alle miteinander!

Ich würde gerne verhindern, dass die User einfach das Browserfenster schließen, ohne sich auszuloggen. Ein nerviges Popup beim nächsten Einloggen, dass daran erinnert sich doch bitte _immer_ über den Button "Abmelden" zuerst auszuloggen wurde mit viel Unmut quittiert und ist verschwunden.
Daher suche ich nach einer Möglichkeit, kurz bevor das Browserfenster geschlossen wird, noch schnell die Logoutseite aufzurufen, um somit den Benutzer korrekt auszuloggen.

Habe mir schon onbeforeunload angesehen, aber das feuert ja auch, wenn ich nur die Seite wechsle, also ungeeignet (nach jedem Klick auf einen Link würde der Benuzter rausgeworfen).
Onbeforeclose war mein nächster Kandidat, scheint sich aber nicht auf das Browserfenster zu beziehen...

Irgendwelche Ideen? Ich bin ratlos und Google auch.

Der Yeti

[Cheatah]

Hi,

Ich würde gerne verhindern, dass die User einfach das Browserfenster schließen, ohne sich auszuloggen.

no way.

Cheatah

[Yeti]

Hi,

no way.

That sucks! Why not??

Der Yeti

[David Tibbe]

Hallo Yeti,

That sucks! Why not??

nur ein paar Fragen: ;)
Warum willst du denn nun die Besucher mit einem solchen Popup nerven?
Woran willst du erkennen, dass der Besucher in 5 Sek. seinen Browser schließt? Wie willst du ihm das Fenster zeigen, wenn du keine Möglichkeit hast?
Und ganz einfach: Was machst du, wenn ich "Reset" drücke?

Grüße
  David

[Yeti]

Hi,

nur ein paar Fragen: ;)
Warum willst du denn nun die Besucher mit einem solchen Popup nerven?

Am liebsten sollte es gar nicht poppen, sondern heimlich still und leise aufgerufen werden im Hauptfenster und sozusagen onLoad dann das Browserfenster geschlossen werden.

Woran willst du erkennen, dass der Besucher in 5 Sek. seinen Browser schließt? Wie willst du ihm das Fenster zeigen, wenn du keine Möglichkeit hast?

Eine professionelle Hellseherin beschäftigen? Das ist genau meine Frage ... wie?

Und ganz einfach: Was machst du, wenn ich "Reset" drücke?

Das macht keiner, schließlich haben sie ja auch noch andere Programme offen. ;-)
Geschweige denn, dass die User überhaupt wissen, was ein "Reset"-Knopf ist, wie man "Riesätt" schreibt und dann auch noch, _wo_ er ist. :-)
(Bei meinem HP Vectra hier ist z.B. keiner da, nur ein Ein/Aus-Knopf, mit dem man dann brutal ausschalten kann)

Der Yeti

[Viennamade]

Hallo!

no way.

That sucks! Why not??

Weil http zustandslos ist. Du kannst nicht prüfen ob die Verbindung da ist oder nicht.

Man kann nächstens natürlich seinen Partner alle 3 Minuten anschupsen und fragen: "Bist noch wach?".

Beste Grüße
Viennamade

[Yeti]

Hi,

Weil http zustandslos ist. Du kannst nicht prüfen ob die Verbindung da ist oder nicht.

Das ist richtig, hat aber nur wenig mit meinem Lösungsansatz zu tun. Schließlich halte ich ja eine virtuelle Verbindung mithilfe von Sessions aufrecht.
Ich stelle es mir ziemlich einfach vor für einen Browserhersteller/-programmierer das Event onbeforewindowclose (o.ä.) einzubauen. Das einzige Gegenargument wäre m.E. ein Sicherheitsrisiko und wahrscheinlich ist es deswegen auch unmöglich. Es ist aus demselben Grund auch nicht möglich, das Browserfenster (was man nicht selber mit JScript geöffnet hat) zu schließen, ohne dass der User erst gefragt wird, ob er das wirklich möchte.

Fazit: No way! :-(

Der Yeti

[Cheatah]

Hi,

Weil http zustandslos ist.

und vor allem verbindungslos.

Das ist richtig, hat aber nur wenig mit meinem Lösungsansatz zu tun. Schließlich halte ich ja eine virtuelle Verbindung mithilfe von Sessions aufrecht.

Tust Du nicht. Deine Session hat nichts mit dem Client zu tun, um den es Dir aber geht.

Ich stelle es mir ziemlich einfach vor für einen Browserhersteller/-programmierer das Event onbeforewindowclose (o.ä.) einzubauen.

Sicher, oder onbeforeunload, welches es sogar (standardunkonform) in einigen Browsern gibt. Das bringt Dir aber nichts, denn es bleiben hinreichend viele unumgängliche Fälle übrig, in denen Dein Konzept scheitert.

Fazit: No way! :-(

Jau. Der Grund ist aber das Protokoll, nicht die Fähigkeit oder Unfähigkeit des oder der Browser.

Cheatah

[Yeti]

Hi,

Jau. Der Grund ist aber das Protokoll, nicht die Fähigkeit oder Unfähigkeit des oder der Browser.

Nochmal: Ich will nicht überprüfen, ob der Client noch da ist oder abgestürzt etc. Ich will lediglich das Schließen abfangen und vorher noch einen Aufruf reinmogeln, damit der Server weiß, dass der Client das Fenster geschlossen hat.

Außerdem ist HTTP sehr wohl ein verbindungsorientiertes Protokoll, da es TCP benutzt. ;-)

Der Yeti

[Axel Richter]

Hallo,

Außerdem ist HTTP sehr wohl ein verbindungsorientiertes Protokoll, da es TCP benutzt. ;-)

Ja. HTTP-GET (-POST) _verbindet_ sich über TCP und erwartet einen Response. Ist der eingegangen, wird die Verbindung beendet. Das Browserfenster bleibt aber trotzdem offen ;-)).

viele Grüße

Axel

[Yeti]

Hi,
wäre ja auch schlimm, wenn ständig weiterhin Daten übertragen würden. Traffic würde unbezahlbar. Stell dir mal vor es gibt eine Webseite mit viel Text (ein Buch auf einer Seite, ok unrealistisch aber machbar) und der Benutzer liest 2 Stunden, während weiterhin Daten übertragen werden. :-)
Der Yeti

[Sven Rautenberg]

Moin!

wäre ja auch schlimm, wenn ständig weiterhin Daten übertragen würden. Traffic würde unbezahlbar. Stell dir mal vor es gibt eine Webseite mit viel Text (ein Buch auf einer Seite, ok unrealistisch aber machbar) und der Benutzer liest 2 Stunden, während weiterhin Daten übertragen werden. :-)

SSH benutzt auch TCP, aber es ist verbindungsorientiert und kann vollkommen ohne Datenübertragung über Stunden offene Verbindungen halten, ohne dass man sich unbemerkt "ausloggen" könnte. Bzw. der Verlust des Clients wird sicher bemerkt.

- Sven Rautenberg

[Yeti]

Hi,

SSH benutzt auch TCP, aber es ist verbindungsorientiert und kann vollkommen ohne Datenübertragung über Stunden offene Verbindungen halten, ohne dass man sich unbemerkt "ausloggen" könnte. Bzw. der Verlust des Clients wird sicher bemerkt.

Hab auch nie was Gegenteiliges behauptet. Das ist aber nicht der Verdienst von SSH, sondern von TCP. TCP ist schließlich dazu da, um eine logische Verbindung über eine paketvermittelte Leitung zu halten. UDP dagegen ist die "reine" Paketvermittlung.

Wie gesagt, HTML ist auch verbindungsorientiert, nur dass eben nach jedem Abruf (HTML-Seite, Bild, etc.) die Verbindung wieder getrennt wird.

http://www.wim.uni-koeln.de/lehre/ss2004/IKT/details.htm#7

Der Yeti

[Ludger Keitlinghaus]

Hi,

Wie gesagt, HTML (LuKe - HTTP) ist auch verbindungsorientiert, nur dass eben nach jedem Abruf (HTML-Seite, Bild, etc.) die Verbindung wieder getrennt wird.

gefaellt mir die Aussage. Bei verbindungslosen Protokollen weiss man, dass man nichts weiss, was den Status des Nutzers auf der anderen Seite der Leitung ebtrifft. Bei verbindungsorientierten Protokollen weiss man, dass man etwas weiss den Status des Nutzers betreffend, allerdings nicht was.

Zu wissen, das man nichts weiss, macht das verbindungslose Protokoll hochwertiger.   ;-)

Gruss,
Ludger

[Yeti]

Hi,

Wie gesagt, HTML (LuKe - HTTP) ist auch verbindungsorientiert, nur dass eben nach jedem Abruf (HTML-Seite, Bild, etc.) die Verbindung wieder getrennt wird.

Richtig, HTTP ... wie dumm von mir!

gefaellt mir die Aussage. Bei verbindungslosen Protokollen weiss man, dass man nichts weiss, was den Status des Nutzers auf der anderen Seite der Leitung ebtrifft. Bei verbindungsorientierten Protokollen weiss man, dass man etwas weiss den Status des Nutzers betreffend, allerdings nicht was.

Bei HTTP weißt du sehr wohl etwas über den Status des Nutzers auf der anderen Seite, nämlich ob er die geschickten Daten korrekt empfangen hat.
Allerdings ist es ja nicht so, dass ständig eine Verbindung gehalten würde (wäre auch sinnlos), um auf neue Anfragen des Benutzers zu warten. Denn dieser kann/muss für jede neue Anfrage eine neue Verbindung aufbauen.
HTTP wurde schließlich für den Abruf von Hypertext-Seiten (und Bildern und dann auch alles mögliche) konzipiert und nicht für eine Onlinerecherche oder ähnliches. Was damals als Performance-Plus verbucht werden konnte, ist heute vielleicht ein Nachteil. Oder auch nicht.

Zu wissen, das man nichts weiss, macht das verbindungslose Protokoll hochwertiger.   ;-)

Ja klar. Kennst du nicht den Spruch: Einer der nichts weiß und weiß, dass er nichts weiß, weiß mehr als einer der nichts weiß und nicht weiß, dass er nichts weiß. Weißt du?

Der Yeti

[Ludger Keitlinghaus]

Hi,

Bei HTTP weißt du sehr wohl etwas über den Status des Nutzers auf der anderen Seite, nämlich ob er die geschickten Daten korrekt empfangen hat.

woher weiss man das?

Zu wissen, das man nichts weiss, macht das verbindungslose Protokoll hochwertiger.   ;-)

Ja klar. Kennst du nicht den Spruch: Einer der nichts weiß und weiß, dass er nichts weiß, weiß mehr als einer der nichts weiß und nicht weiß, dass er nichts weiß. Weißt du?

Bei verbindungshaltenden Protokollen weiss man, dass auf der anderen Seite noch eine andere Maschine die Verbindung bestaetigt. Fein, aber man programmiert oft ja nicht fuer Maschinen sondern fuer Menschen.

In diesem Kontext gibt's auch den netten Feature-Artikel: http://aktuell.de.selfhtml.org/artikel/programmiertechnik/useronline/index.htm

Gruss,
Ludger

[Ludger Keitlinghaus]

Hi,

Das ist richtig, hat aber nur wenig mit meinem Lösungsansatz zu tun. Schließlich halte ich ja eine virtuelle Verbindung mithilfe von Sessions aufrecht.

Tust Du nicht. Deine Session hat nichts mit dem Client zu tun, um den es Dir aber geht.

also, wenn diese Verbindung nicht virtuell ist.   ;-)
Der Client verfuegt doch ueber einen Zeiger auf eine Sitzungseindeutigkeit. Ich spreche da gerne von logischer Verbindung, aber viertuell hoert sich auch ganz gut an.
Und natuerlich hat die Session was mit dem Client zu tun.

Gruss,
Ludger

[Der Martin]

Hallo,

Der Client verfuegt doch ueber einen Zeiger auf eine Sitzungseindeutigkeit. Ich spreche da gerne von logischer Verbindung, aber virtuell hoert sich auch ganz gut an.
Und natuerlich hat die Session was mit dem Client zu tun.

Ja, schon. Aber es ändert nichts am ursprünglichen "Problem", dass der Server keine Kontrolle darüber hat, ob der Client "noch da" ist. Er kann nicht erkennen, ab der eingeloggte User einfach bloß eine halbe Stunde tatenlos auf seinen Bildschirm starrt oder schon längst seinen Rechner ausgeschaltet hat.

Ciao,

Martin

[Ludger Keitlinghaus]

Hi,

[...] Er kann nicht erkennen, ab der eingeloggte User einfach bloß eine halbe Stunde tatenlos auf seinen Bildschirm starrt oder schon längst seinen Rechner ausgeschaltet hat.

aber es kann erkannt werden, ob der Nutzer noch was macht, ob er noch auf Daten zugreift. Das ist doch schon eine ganze Menge. Auch bei verbindenden Protokollen weiss man ja nicht, ob der Nutzer nur vor dem rechner eingedoest ist, in einem anderen "Fenster" arbeitet oder inzwischen von der Polizei verhaftet worden ist, weil er aus dem Fenster gespuckt hat.

Gruss,
Ludger

[Yeti]

Hi,

[...]oder inzwischen von der Polizei verhaftet worden ist, weil er aus dem Fenster gespuckt hat.

Ich denke diesen Fall können wir ausschließen, da die Software wahrscheinlich nicht in Paris eingesetzt wird. Selbst wenn wir es mal an die Mutterfirma verkaufen sollten, die Zentrale sitzt in Batilly und ich glaube nicht, dass es dort auch bei Strafe verboten ist. ;-)

Der Yeti

[Cheatah]

Hi,

no way.
That sucks!

it doesn't.

Why not??

Nur ein Beispiel, beliebig viele andere darfst Du Dir selbst überlegen: Der Rechner könnte abstürzen.

Cheatah

[Yeti]

Hi,

Nur ein Beispiel, beliebig viele andere darfst Du Dir selbst überlegen: Der Rechner könnte abstürzen.

OK. Abgesehen von Stromausfällen, Resetknöpfen, Abstürzen, Browserprozesskillern, etc. ...
Why not implement an onbeforewindowclose (or whatever) event?!

Der Yeti

[Cheatah]

Hi,

Why not implement an onbeforewindowclose (or whatever) event?!

einen sehr wichtigen Grund hast Du genannt. Beachte noch, dass die Rückgabe aus einem Event-Handler die Durchführung der eigentlichen mit dem Event verknüpften Aktion verhindern kann, und Du hast mit einem solchen Event die Möglichkeit der Unbenutzbarmachung des Browsers oder sogar des Systems geschaffen.

Cheatah

[Yeti]

Hi,

einen sehr wichtigen Grund hast Du genannt. Beachte noch, dass die Rückgabe aus einem Event-Handler die Durchführung der eigentlichen mit dem Event verknüpften Aktion verhindern kann, und Du hast mit einem solchen Event die Möglichkeit der Unbenutzbarmachung des Browsers oder sogar des Systems geschaffen.

Ich kenne zwar keinen Browserquellcode persönlich, aber es sollte doch möglich sein, die Verhinderung zu umgehen. Also dass "return false;" keinen Effekt hat.
Schlichtweg "schließe das Fenster, egal was das Event zurückgibt".

Der Yeti

[at]

Hallo.

Ich kenne zwar keinen Browserquellcode persönlich,

Solltest du einen kennenlernen, grüße ihn bitte von mir.
MfG, at

[Der Martin]

Hallihallo,

Ich kenne zwar keinen Browserquellcode persönlich,

Solltest du einen kennenlernen, grüße ihn bitte von mir.

*rofl* haaahahaha!
Keuch... japs... hahaha!

Martin

[Ludger Keitlinghaus]

Hi,

Ich kenne zwar keinen Browserquellcode persönlich,

Solltest du einen kennenlernen, grüße ihn bitte von mir.

*rofl* haaahahaha!
Keuch... japs... hahaha!

ja, der at. Der ist superlustig. Ho ho ho.

Gruss,
Ludger

[Jan L.]

Hallo,

Why not implement an onbeforewindowclose (or whatever) event?!

'onbeforeunload' gibt es durchaus.

http://www.webreference.com/dhtml/diner/beforeunload/

Neuere Mozillas kennen dieses Event ebenfalls.

Gruß, Jan

[Yeti]

Hi,

'onbeforeunload' gibt es durchaus.

Ja, weiß ich. Das feuert aber leider auch beim Navigieren innerhalb der Webseite, wenn ich z.B. auf einen Link klicke oder sonstwas.
Microsoft:
"To invoke: Close the current browser window.
Navigate to another location by entering a new address or selecting a Favorite.
Click the Back, Forward, Refresh, or Home button.
Click on an a that refers the browser to another Web page.
Invoke the a click method.
Invoke the document write method.
Invoke the document open method.
Invoke the document close method.
Invoke the window close method.
Invoke the window open method, providing the possible value _self for the window name.
Invoke the window navigate or NavigateAndFind method.
Invoke the location replace method.
Invoke the location reload method.
Specify a new value for the location href property.
Submit a form to the address specified in the action attribute via the input type=submit control, or invoke the form submit method."

Ich würde mich aber gerne auf "Close the current browser window" beschränken.

Der Yeti

[Axel Richter]

Hallo,

OK. Abgesehen von Stromausfällen, Resetknöpfen, Abstürzen, Browserprozesskillern, etc. ...
Why not implement an onbeforewindowclose (or whatever) event?!

Why?
Bzw. was würde es Dir bringen? Dieses onbeforewindowclose würde nur von Scriptsprachen ausgewertet werden können. Das sind clientseitige und damit nicht vorauszusetzende Techniken. Sprich: Du kannst Dich nicht darauf verlassen.

Du schriebst, Du hältst die virtuelle Verbindung über eine Session. Diese Session lässt Du nach logout _oder_ eben nach einer bestimmten Zeit verfallen. Solange bleiben abgebrochene Sessions eben abgebrochen. Wo ist das Problem?

viele Grüße

Axel

[Yeti]

Hi,

Why?
Bzw. was würde es Dir bringen? Dieses onbeforewindowclose würde nur von Scriptsprachen ausgewertet werden können. Das sind clientseitige und damit nicht vorauszusetzende Techniken. Sprich: Du kannst Dich nicht darauf verlassen.

Doch, in meiner Umgebung schon. Dieses Ziel mit reinem HTML zu erreichen ist utopisch, das weiß ich.

Du schriebst, Du hältst die virtuelle Verbindung über eine Session. Diese Session lässt Du nach logout _oder_ eben nach einer bestimmten Zeit verfallen. Solange bleiben abgebrochene Sessions eben abgebrochen. Wo ist das Problem?

Um eben genau diese Zeit zwischen "User schließt Fenster ohne Logout" und "Session bekommt Timeout" nicht zu haben. Wenn dann nämlich jemand die Session-ID in den Fingern hält, kann er sich als derjenige Benutzer anmelden.
Da hier aber alles im Intranet passiert und ich diesen Fall daher für unwahrscheinlich halte, belasse ich es einfach dabei. Wollte nur auf "Nummer Sicher" gehen...

Der Yeti

[Andre]

Da hier aber alles im Intranet passiert und ich diesen Fall daher für unwahrscheinlich halte, belasse ich es einfach dabei. Wollte nur auf "Nummer Sicher" gehen...

Der Yeti

Dann prüfe doch zusätzlich noch die IP?!

Gruss,
Andre

[Yeti]

Hi,

Dann prüfe doch zusätzlich noch die IP?!

Guter Vorschlag.
Aber das Sicherheitsargument ist ja nicht das einzige. Die Benutzer sollen auch nach 3 Stunden Inaktivität noch arbeiten können.

Der Yeti

[Sven Rautenberg]

Moin!

Um eben genau diese Zeit zwischen "User schließt Fenster ohne Logout" und "Session bekommt Timeout" nicht zu haben. Wenn dann nämlich jemand die Session-ID in den Fingern hält, kann er sich als derjenige Benutzer anmelden.

Ja und? Das kann jemand auch - oder gerade - auch in der Zeit, in der der Benutzer real auf der Seite herumsurft. Parallel-Logins von zwei verschiedenen Rechnern sind nicht ganz trivial zu verhindern, und sie nerven in der Regel den Benutzer auch mehr, als dass sie helfen würden.

Das Sicherheitsargument kann hier nicht ziehen. Durch die Session-ID ist ein Angreifer gezwungen, aus einer Auswahl von 2^32 genau EINE passende ID zu raten. Mit dem Timeout der Session hat er dafür sogar nur begrenzt Zeit.

Das bedeutet: Entweder diese Aufgabe ist wirklich nur durch Glück zu schaffen (ein Lottogewinn wäre milliardenmal wahrscheinlicher), oder der Angreifer kann den Datenverkehr belauschen und sich somit einen Vorteil verschaffen. Dann benötigt er aber in der Regel nicht mal die Session-ID, welche ja nur existiert, nachdem sich ein Benutzer angemeldet hat, sondern kann Username und Passwort abfangen und sich damit komfortabel JEDERZEIT einloggen.

Wenn derartige Sicherheitsbedenken dein Problem sind, solltest du dir vor allem anderen erstmal um die Einführung von SSL Gedanken machen. Das erhöht die Sicherheit WIRKLICH - der nicht realisierbare "Logout beim Verlassen" ist nur Kosmetik ohne reale Verbesserung der Sicherheit.

- Sven Rautenberg

[Yeti]

Hi,

Wenn derartige Sicherheitsbedenken dein Problem sind, solltest du dir vor allem anderen erstmal um die Einführung von SSL Gedanken machen. Das erhöht die Sicherheit WIRKLICH - der nicht realisierbare "Logout beim Verlassen" ist nur Kosmetik ohne reale Verbesserung der Sicherheit.

ACK.
Das eigentliche Problem ist auch, dass die Benutzer eben nicht "rausgeschmissen" werden sollen (wie oben [1] beschrieben), sondern nur wenn sie sich ausloggen oder eben das "Anwendungsfenster" (Browser oder HTA) zumachen.

Bei den HTAs hatte ich letztens das Problem, dass der IE auf "Cookies akzeptieren" eingestellt war, die Hypertext Application aber trotzdem das Cookie _nicht_ akzeptierte.

Aber ich glaube ich werde einfach ein kleines Programm schreiben, dass nichts anderes tut als die Startseite in einem browserähnlichen Fenster zu laden, dann hab ich volle Kontrolle darüber, was beim Drücken des kleines x oben rechts passiert.

Der Yeti

[1] <./?t=89377&m=535395>

[MudGuard]

Hi,

OK. Abgesehen von Stromausfällen, Resetknöpfen, Abstürzen, Browserprozesskillern, etc. ...
Why not implement an onbeforewindowclose (or whatever) event?!

Selbst wenn es das gäbe, würde es nicht helfen.

Beispiel: Ohne das Fenster zu schließen, tippt der User www.google.de in die Adreßzeile.
Deine Seite ist weg, das event hat nicht stattgefunden.

Wenn überhaupt bräuchtest Du ein onhostchange

cu,
Andreas

[Yeti]

Hi,

Selbst wenn es das gäbe, würde es nicht helfen.

Beispiel: Ohne das Fenster zu schließen, tippt der User www.google.de in die Adreßzeile.
Deine Seite ist weg, das event hat nicht stattgefunden.

Wenn überhaupt bräuchtest Du ein onhostchange

"Granted."
Aber ich habe nachher ohnehin vor, das ganze in eine nette HTA zu packen, damit die möglichst wenig kaputt machen können und ich alles steuern kann (Fenstergröße, Steuerleisten ...).

Der Yeti

[Norbert Kölln]

Moin, moin!

Wie wäre es damit: Die Startseite baut ein Frameset auf (könnte ein einiges Frame enthalten). Im Frameset-Tag ist eine onunload-Anweisung enthalten, die mittels window.open Deine Logoutseite in einem neuen Fenster hochkommen läßt. Dieses würde dann wirklich nur erscheinen, wenn das Fenster mit dem Frameset geschlossen oder verlassen wird.

Norbert

[Yeti]

Middach,
ja, daran habe ich auch schon gedacht. Aber bisher habe ich es erfolgreich vermieden mit Frames zu arbeiten.
Ich will z.B. den Titel dynamisch halten, um dort eine Art Sitemap-Path unterzubringen. Das würde dann verloren gehen.

So schlimm ist es auch nicht. Wenn es keine andere Lösung gibt, lasse ich es halt sein.

Aber danke!

Der Yeti

[Cheatah]

Hi,

So schlimm ist es auch nicht. Wenn es keine andere Lösung gibt, lasse ich es halt sein.

ein Sessionkonzept innerhalb von HTTP _muss_ den Fall der Nichtabmeldung beachten, also kann sie ihn genauso gut als Normalfall ansehen. Von daher: Gute Wahl.

Cheatah

[Yeti]

Hi,
richtig. Tut es ja auch. Aber ich will die Session nicht nach 10 Sekunden schon killen, weil dann kein User schon den nächsten Link geklickt hat bzw. das Formular fertig ausgefüllt hat. Ich will aber auch nicht eine "tote" Session ne Stunde lang herumgeistern haben.
Der Yeti

[Andreas-Lindig]

Ich will aber auch nicht eine "tote" Session ne Stunde lang herumgeistern haben.

dann mach doch 10 Minuten.
wozu soll das Ganze überhaupt gut sein? Nur, um die Session immer sofort zu killen, wenn der User fertig ist? Also ich mach das so: bei eingeloggtem User wird ein Timestamp bei jedem Klick aktualisiert. Nach 10 Minuten ist auto-outlogg. Wenn einer 10 Minuten nicht klickt, kann er sich auch ruhig nochmal einloggen.

Gruß, Andreas

[Yeti]

Hi,

dann mach doch 10 Minuten.
wozu soll das Ganze überhaupt gut sein? Nur, um die Session immer sofort zu killen, wenn der User fertig ist? Also ich mach das so: bei eingeloggtem User wird ein Timestamp bei jedem Klick aktualisiert. Nach 10 Minuten ist auto-outlogg. Wenn einer 10 Minuten nicht klickt, kann er sich auch ruhig nochmal einloggen.

Das Problem ist, dass die Leute den ganzen Arbeitstag damit arbeiten werden und dann durchaus auch mal länger als 10 Minuten (oder auch eine Stunde) nicht damit arbeiten und dann aber wieder arbeiten wollen. Bei dem ersten Projekt hier loggt sich der Browser manchmal nach ca. 30 Minuten von alleine aus, das hat schon Empörungsstürme losgetreten.
Ideal wäre natürlich, wenn jemand bis zu 8 oder 9 Stunden eingeloggt sein könnte. Ich finde es auch immer ganz schön, wenn ich (wie z.B. heute) nach dem Wochenende den PC aus dem "Winterschlaf" (hibernating) hole und immer noch eingeloggt bin.
Leider verursacht das, wie jeder weiß, viele viele unbenutzte Sessions auf dem Server.

Das Ganze soll dazu gut sein, dass ich eben erkenne wann ein Benutzer wirklich weg ist (d.h. Browser ist zu, Benutzer abgemeldet, PC heruntergefahren) und wann er einfach nur eine lange Mittagspause macht während der Browser noch offen ist.

Der Yeti

[Andreas-Lindig]

Bei dem ersten Projekt hier loggt sich der Browser manchmal nach ca. 30 Minuten von alleine aus, das hat schon Empörungsstürme losgetreten.

Dann erklär den Leuten doch mal, wozu das Einloggen gut ist...

Ideal wäre natürlich, wenn jemand bis zu 8 oder 9 Stunden eingeloggt sein könnte...
Das Ganze soll dazu gut sein, dass ich eben erkenne wann ein Benutzer wirklich weg ist (d.h. Browser ist zu, Benutzer abgemeldet, PC heruntergefahren) und wann er einfach nur eine lange Mittagspause macht während der Browser noch offen ist.

...wenn die Sicherheit dermaßen schnuppe ist, daß der während seiner Mittagspause den Brauser eingeloggt läßt, kann man sich das Theater dann nicht ganz sparen? Außerdem: wenn man bei mir den Brauser schließt ist man auch ausgeloggt wg. http-Authentifizierung. Ich weiß nicht, ob das alle Brauser machen, aber normalerweise vergißt der dann das Passwort doch.

Gruß, Andreas

[Yeti]

Hi,

Dann erklär den Leuten doch mal, wozu das Einloggen gut ist...

Schon erledigt, nützt nichts. Argument: "Jedes andere Programm kann das auch! Bei Windows werde ich ja auch nicht alle paar Minuten rausgeschmissen und muss mich neu anmelden..."

...wenn die Sicherheit dermaßen schnuppe ist, daß der während seiner Mittagspause den Brauser eingeloggt läßt, kann man sich das Theater dann nicht ganz sparen? Außerdem: wenn man bei mir den Brauser schließt ist man auch ausgeloggt wg. http-Authentifizierung. Ich weiß nicht, ob das alle Brauser machen, aber normalerweise vergißt der dann das Passwort doch.

Von mir aus sollten die das nicht tun (zumal sie schon ihre Workstation sperren und danach ihr Passwort ohnehin noch einmal eingeben müssen).
Mit HTTP-Authentifizierung hatte ich bisher noch nicht allzuviele gute Erfahrungen, unter anderem funktioniert ein Logout nicht immer und im Gegensatz zu Formularen kann ich nicht verhindern, dass Benutzername und Passwort gespeichert werden.

Der Yeti

[Sven Rautenberg]

Moin!

Mit HTTP-Authentifizierung hatte ich bisher noch nicht allzuviele gute Erfahrungen, unter anderem funktioniert ein Logout nicht immer und im Gegensatz zu Formularen kann ich nicht verhindern, dass Benutzername und Passwort gespeichert werden.

Haha! Guter Witz. :)

Ein Logout ist bei HTTP-Authentifizierung vollkommen unmöglich, weil es auch kein "Login" gibt (aber das scheint mir genau das zu sein, was die Mitarbeiter da haben wollen).

Und was deine angebliche Kontrolle über den speicherbaren Inhalt der Formularfelder angeht... naja, du hast vielleicht noch Träume, aber die Realität sieht ganz anders aus. Dem IE kann man das Nichtspeichern vielleicht abgewöhnen, alle anderen Browser setzen den Benutzerwillen an erste Stelle.

Mal ernsthaft betrachtet: Offenbar ist Sicherheit nicht wichtig - warum versuchst du also, irgendwelche Pseudo-Maßnahmen zu ergreifen, die doch nichts bringen? Es ist für den Angreifer doch vollkommen egal, ob die Session auf dem Server drei Stunden aktiv ist, weil der Mitarbeiter Mittagspause macht, oder ob sie drei Stunden aktiv ist, weil der Logout vergessen wurde.

Bei beiden gilt: Es ist in drei Stunden unmöglich zu schaffen, eine Session-ID zu erraten, dazu braucht man Spionagewissen durch abgehörtes Netzwerk.

- Sven Rautenberg

[Yeti]

Hi,

Haha! Guter Witz. :)

Ein Logout ist bei HTTP-Authentifizierung vollkommen unmöglich, weil es auch kein "Login" gibt (aber das scheint mir genau das zu sein, was die Mitarbeiter da haben wollen).

Genau. Daher wäre HTTP-Auth auch nur ein Notnagel. Der Logout wird meistens dadurch herbeigeführt, dass trotz richtiger Credentials vom Browser der Zugriff verweigert wird. Dann kommt erneut die Auth-Anforderung, die man allerdings abbrechen kann und immer authentifiziert ist. Bzw. wenn man erneut dieselben Benutzerdaten eingibt, kommt man natürlich nicht mehr rein (man soll ja ausgeloggt werden).

Und was deine angebliche Kontrolle über den speicherbaren Inhalt der Formularfelder angeht... naja, du hast vielleicht noch Träume, aber die Realität sieht ganz anders aus. Dem IE kann man das Nichtspeichern vielleicht abgewöhnen, alle anderen Browser setzen den Benutzerwillen an erste Stelle.

Der Benutzerwillen hat zu schweigen, wenn es um erfolgskritische Daten geht, die durch gespeicherte Passwörter gefährdet sind. ;-)

Mal ernsthaft betrachtet: Offenbar ist Sicherheit nicht wichtig - warum versuchst du also, irgendwelche Pseudo-Maßnahmen zu ergreifen, die doch nichts bringen? Es ist für den Angreifer doch vollkommen egal, ob die Session auf dem Server drei Stunden aktiv ist, weil der Mitarbeiter Mittagspause macht, oder ob sie drei Stunden aktiv ist, weil der Logout vergessen wurde.

Bei beiden gilt: Es ist in drei Stunden unmöglich zu schaffen, eine Session-ID zu erraten, dazu braucht man Spionagewissen durch abgehörtes Netzwerk.

OK, lassen wir die Sicherheit außen vor. Ein Netzwerk abzuhören ist nicht schwer, wenn man sich in selbigem befindet (und auch von außerhalb nicht unmöglich).
Eigentlich habe ich nur Angst um meinen eigenen Skalp, wenn so ein Fall mal eintreten sollte und es dann auf mich zurückfällt nach dem Motto: "Sie haben das nicht hinreichend sicher programmiert! Schadensersatzforderungen ... blah, blah"

Und die toten Sessions auf dem Server lösche ich dann persönlich alle paar Tage mal (wenn die mich drauflassen ohne Antrag...).

Der Yeti

[Sven Rautenberg]

Moin!

Eigentlich habe ich nur Angst um meinen eigenen Skalp, wenn so ein Fall mal eintreten sollte und es dann auf mich zurückfällt nach dem Motto: "Sie haben das nicht hinreichend sicher programmiert! Schadensersatzforderungen ... blah, blah"

Schriftstück anfertigen, darin die möglichen Horrorszenarien skizzieren, für diese Szenarien jegliche Haftung ablehnen, wenn Bedingungen X, Y und Z betreffend die Sicherheitsanforderungen nicht erfüllt sind, und vom Chef/Auftraggeber abzeichnen lassen. Dann ist der Schwarze Peter eindeutig beim Chef. :)

- Sven Rautenberg

[Yeti]

Hi,

Schriftstück anfertigen, darin die möglichen Horrorszenarien skizzieren, für diese Szenarien jegliche Haftung ablehnen, wenn Bedingungen X, Y und Z betreffend die Sicherheitsanforderungen nicht erfüllt sind, und vom Chef/Auftraggeber abzeichnen lassen. Dann ist der Schwarze Peter eindeutig beim Chef. :)

Mein Auftraggeber hat jetzt genug Stress, weil ihm die Haupt-IT-Abteilung jetzt einen Strich durch die Rechnung machen will, da wir schließlich schon ein Programm dafür haben (was zu groß, zu schwerfällig und zu kompliziert und was deswegen keiner nutzt). Das muss sich erstmal amortisieren. Das Projekt wird jetzt wohl abgebrochen.
Ach ja, Politik ...

Der Yeti

[Detlef G.]

Hallo Yeti

Eigentlich habe ich nur Angst um meinen eigenen Skalp, wenn so ein Fall mal eintreten sollte und es dann auf mich zurückfällt nach dem Motto: "Sie haben das nicht hinreichend sicher programmiert! Schadensersatzforderungen ... blah, blah"

Dann würde ich alles genau dokumentieren.

• welche die Sichereit ehöhenden Funktionen ich eingebaut habe
• wozu diese dienen
• auf wessen Veranlassung diese wieder entfernt werden mussten
  usw.

Oder/und ich würde Sicherheitsfunktionen nur mit schriftlichem Auftrag und
unter nachweislichem Hinweis deiner Bedenken deaktivieren oder entfernen.

Und die toten Sessions auf dem Server lösche ich dann persönlich alle paar Tage mal (wenn die mich drauflassen ohne Antrag...).

Das muss doch nun wirklich nicht sein.
Du könntest doch z.B. eine ausreichend lange Zeit bis zum automatischen
Löschen lassen.

Da kommt mir noch ein Gedanke.
Wäre es nicht möglich, mittels eines Scriptes regelmäßig eine Anfrage an
den Server zu schicken.

Auf Wiederlesen
Detlef

[Yeti]

Hi,

Das muss doch nun wirklich nicht sein.
Du könntest doch z.B. eine ausreichend lange Zeit bis zum automatischen
Löschen lassen.

Ja, ich werde jetzt auch 24 Stunden einbauen. Dann kann man auch "über Nacht" eingeloggt bleiben, aber nicht übers Wochenende oder den Urlaub.

Da kommt mir noch ein Gedanke.
Wäre es nicht möglich, mittels eines Scriptes regelmäßig eine Anfrage an
den Server zu schicken.

Das hatte ich mal eingestellt, die Seite hat sich alle Viertelstunde neu geladen. Leider kam dann bei Seiten, die per POST aufgerufen wurden, die schöne Meldung "Wollen Sie die Daten erneut schicken?".
Die einzige Möglichkeit, die ich sehe, wäre ein IFRAME und das finde ich ziemlich dreckig.

Der Yeti

[Detlef G.]

Hallo Yeti,

Das hatte ich mal eingestellt, die Seite hat sich alle Viertelstunde neu geladen. Leider kam dann bei Seiten, die per POST aufgerufen wurden, die schöne Meldung "Wollen Sie die Daten erneut schicken?".
Die einzige Möglichkeit, die ich sehe, wäre ein IFRAME und das finde ich ziemlich dreckig.

Muss das sein?
Muss unbedingt die Seite neu geladen werden?
Reicht es nicht, z.B. eine Grafik-URL (kann 1x1 Pixel sein) zu ändern?
(mit neuem angehängten Parameter)

Auf Wiederlesen
Detlef

[Detlef G.]

Hallo Yeti

... Ein nerviges Popup beim nächsten Einloggen, dass daran erinnert sich doch bitte _immer_ über den Button "Abmelden" zuerst auszuloggen wurde mit viel Unmut quittiert und ist verschwunden.

Ich würde statt des nervigen Popups einen dezenten Hinweis ausgeben, damit die
Nutzer zwar daran errinert werden, ohne sich gleich genervt zu fühlen.

Auf Wiederlesen
Detlef

[Yeti]

Hi,

Ich würde statt des nervigen Popups einen dezenten Hinweis ausgeben, damit die
Nutzer zwar daran errinert werden, ohne sich gleich genervt zu fühlen.

Ich fand den Hinweis auch dezent, aber schließlich musste man noch auf "OK" klicken (alert-Fenster).
Je dezenter der Hinweise ist, desto leichter wird er leider auch überlesen und ist dann unwirksam...

Der Yeti

[Detlef G.]

Hallo Yeti,

Ich fand den Hinweis auch dezent, aber schließlich musste man noch auf "OK" klicken (alert-Fenster).

Ein alert-Fenster ist nie dezent.
Ich meinte, den Hinweis direkt auf der Seite mit auszugeben. Er kann ja
durchaus auffällig sein, sollte nur nicht eine Aktion des Nutzers erfordern.

Je dezenter der Hinweise ist, desto leichter wird er leider auch überlesen und ist dann unwirksam...

Steter Tropfen höhlt den Stein.

Auf Wiederlesen
Detlef

[Der Martin]

Hi,

das Sprichwort kannte ich noch anders:

Steter Tropfen höhlt den Stein.

Hieß es nicht "Steter Tropfen ölt die Leber"?  :))

In diesem Sinne: Pr...  *hicks* Prost!

Martin

[Yeti]

Hi,

Ein alert-Fenster ist nie dezent.

ACK.

Ich meinte, den Hinweis direkt auf der Seite mit auszugeben. Er kann ja
durchaus auffällig sein, sollte nur nicht eine Aktion des Nutzers erfordern.

Stimmt, die Aktion war vielleicht zu aufdringlich. Andererseits werden ja noch nicht mal die dezenten aber deutlichen Bedienungshinweise auf der Loginseite beachtet, die den Usern das Leben leichter machen sollen...

Steter Tropfen höhlt den Stein.

Also bei mir ist es eher so, je öfter ich einen Hinweis oder ein Fenster schon gelesen habe, desto mehr glaube ich, zu wissen was drinsteht (und dass es für mich nicht wichtig ist, ich nicht drüber nachdenken muss). So sind Sicherheitsabfragen à la "Wollen Sie 3567 Dateien löschen?" bei mir unwirksam, weil ich sowieso instinktiv auf Enter haue. ;-)

Der Yeti