Problem beim onunload event: User wird einfach ausgeloggt!

[BloodySword]

Hallo ihr, ich habe ein dickes Problem:

Ich möchte die Session killen, sobald der Benutzer die Seite schließt.
Leider passiert dies schon nach dem ersten Login: Die erste Seite wird angezeigt aber die darauf folgende nicht, der user ist somit wieder ausgeloggt, weil ja beim VERLASSEN der letzten Seite onunload ausgelöst wird.

Wie kann ich feststellen, dass der Benutzer das Fenster auch wirklich schließt?

onclose ging leider irgendwie nicht. Kann mir jemand helfen? :(

JS-Code mit Template-Coed (SMARTY):

{if ($loggedout==false || !isset($loggedout))}{literal}<!-- Ajax-Funktionen -->  
<script type="text/javascript">  
  //<![CDATA[
~~~~~~javascript
  
    // Messageanzahl aktualisieren  
    function ajaxLogout() {  
      ajaxSendQuery("logout.php?exception=wndclose");  
    }
~~~~~~html
  
  //]]>  
</script>{/literal}{/if}

Im Body:

<body{if ($loggedout==false || !isset($loggedout))} onunload="ajaxLogout();"{/if}>

[molily]

In letzter Konsequenz kannst du das mit JavaScript nicht zuverlässig prüfen. Wenn dir jemand etwas anderes erzählt hat und meinte, du könnest mit unload oder beforeunload irgendetwas deichseln, so hat er Unrecht.

unload und beforeunload beziehen sich immer auf das »Entladen« von einzelnen HTML-Dokumenten. Es ist nicht direkt möglich zu prüfen, was das Verlassen des Dokuments ausgelöst hat und »wohin« der Benutzer die Seite verlässt - also ob es das Schließen des Fensters ist, das Eingeben einer fremden URI in die Adressleiste, das Folgen eines externen Links, das Folgen eines site-internen Links oder gar ein Reload desselben Dokuments. Und so weiter.

Man kann höchstens so vorgehen: Beim Klicken auf interne Links unload unterdrücken, andernfalls ein Logout starten. So eine Whitelist-Regelung ist natürlich ausbaubar.
</archiv/2008/7/t173923/#m1142159>

Mathias

[BloodySword]

Ok, jetzt bleibt nur die Frage, wieso wird das onclose-Event nicht gefeuert? Wenn es deshalb ist, weil die Seite bereits entladen wird/entladen wurde, dann dürfte es dieses Event ja auch folglich gar nicht erst geben, habe ich Recht? Irgendwie muss ich das onclose doch zu Nutze machen können...

[Klawischnigg]

Hi there,

Ok, jetzt bleibt nur die Frage, wieso wird das onclose-Event nicht gefeuert?

Onclose gibts nicht. Das eigentliche Problem bei Deinem Vorhaben ist die Unmöglichkeit, am Server feststellen zu können, was der User in oder mit seinem Browser so anstellt. In Deiner Vorstellung spielt sich ein normaler Ablauf mit User betritt die Seite und verlässt sie wieder, indem er woanders hinzieht oder den Browser schliesst. Was aber machst Du bzw. Dein am Server laufendes Skript, wenn zB der Rechner des Users explodiert oder weniger dramatisch, einfach der Stecker gezogen wird? Dann kannst Du alle eventHandler, die auf ein bestimmtes Ereignis warten, vergessen (ausser Du kennst einen Eventhandler, der beim zuständigen E-Werk des Verbrauchers den aktuellen Stromverbrauch bewertet...)

[Tom]

Hello,

Onclose gibts nicht.

Na, dann heißt er eben onblur().
Spielt ja für die Idee erstmal keine Geige.

Das eigentliche Problem bei Deinem Vorhaben ist die Unmöglichkeit, am Server feststellen zu können, was der User in oder mit seinem Browser so anstellt.

Dann stellen wir eben fest, was er _nicht_ anstellt.

In Deiner Vorstellung spielt sich ein normaler Ablauf mit User betritt die Seite und verlässt sie wieder, indem er woanders hinzieht oder den Browser schliesst. Was aber machst Du bzw. Dein am Server laufendes Skript, wenn zB der Rechner des Users explodiert oder weniger dramatisch, einfach der Stecker gezogen wird?

Dann ist die Verbindung unterbrochen, was der Server dann feststellen kann. Gehen wir von einem reinrassigen Zustands- und Verbindugslosen Protokoll aus, dann muss man die Zustandsorientierung eben wieder künstlich erzeugen. Ein Retrigger-Request reicht da i.d.R. aus. Da am Server aber kein kontinuierlicher Prozess läuft, der dies überwachen könnte, muss jeder Retrigger-Request selber dafür sorgen, dass das Logout stattfindet, wenn er keinen Nachfolger mehr hat. Dazu müssen sich die Zyklen nur überlappen.

R---------------|
       R------------------|
               R---------------------|
                                        R------------------|    # ist im Netz Umwege gelaufen,
                                   R----------------|           # dafür kam der Nachfolger noch
                                                                # rechtzeitig

R = reTrigger
| = Logout, wenn kein reTrigger stattgefunden hat. Der Trigger setzt einfach nur einen Zähler rauf, der in der Session steht. Jeder Request kennt seinen eigenen Zählerstand. Wenn dieser am Ende der Scriptlaufzeit (auf dem Server) immer noch den eigenen Stand hat, wird getrennt, also die Session auf ungültig geschaltet oder gelöscht, je nachdem, welche Maßnahmen vorher noch getroffen werden müssen.

Wenn der Heartbeat 3 Sec. beträgt, kann man nach >8 Sec auf jeden Fall ausloggen können. Wenn dann mal ein Request verloren geht, sollte die "Verbindung" trotzdem bestehen bleiben.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Klawischnigg]

Hi there,

Wenn der Heartbeat 3 Sec. beträgt, kann man nach >8 Sec auf jeden Fall ausloggen können. Wenn dann mal ein Request verloren geht, sollte die "Verbindung" trotzdem bestehen bleiben.

Daß es prinzipiell einigermaßen möglich ist, ist klar. Meine Replik bezog sich vor allem auf die (Un)Möglichkeit, das Vorhaben des Originalposters mit irgendeinem Eventhandler zu verwirklichen.

Deine Lösung erinnert mich an die Chatrooms, die ohne Java oder Active-X auskommen (was Wunder ;), bleibt die Frage, wieviel Verkehr auf diese Art und Weise produziert wird...

[BloodySword]

Erstmal danke für den schnellen Feedback von euch allen. Jetzt bin ich erstmal schlauer...

Wer das Gerücht in die Welt gesetzt hat, es gäbe ein Eventhandler "onclose", der gehört bestraft!

Jedenfalls werde ich mich mit dem Session-Timeout begnügen müssen.
Das Ganze funktioniert im Moment so:

Ein User loggt sich ein, PHP-Session wird in der DB mit der USERID zugeordnet und in die Tabelle sessions mit einem DATETIME-Wert der letzten Aktion gespeichert.

Solange er surft wird bei jedem Request (auch bei einem Ajax-Request, welches alle 20 sec die Anzahl der neuen Nachrichten prüft) aktualisiert.

Schließt der User das fenster, wird dieser Zeitstempel nicht aktualisiert. Bei jedem Klick eines anderen Users, wird die komplette Tabelle sessions gepürft, ob dort abgelaufene Sessions drin sind. Die Lifetime ist gleich die Lifetime wie sie im GC in der php.ini konfiguriert ist. Klickt also ein beliebiger User, so ist dieser dran Schuld, dass die abgelaufenen Sessions der User raus gehauen wurden!

Leider habe ich noch ein Bug:

Wenn der User das Fenster schließt, killt der Browser das SESSION-COOKIE. So muss er sich neu einloggen, die Session von vorher ist aber noch gültig. Egal mit welchem User er sich dann einloggt und obwohl der COOKIE tot ist bekommt der User die gleiche SESSION-ID wieder. Wenn er sich jetzt einloggt, so müsste eigentlich die USERID in der Tabelle sessions der DB für diese Session aktualisiert werden, sonst erscheint er User offline, obwohl er sich eingeloggt hat.

Ich weiß nicht wieso der User nach dem Schließen des Fensters ausgeloggt ist, obwohl ich das Javascript zum Ausloggen deaktiviert habe. Die SESSION wird aber mit der gleichen SESSION-ID wieder aufgefrischt sobald der User sich wieder einloggt - was er auch mit einem anderen Akkount tun könnte, wenn er mehrere hat!

[Gunther]

Hello Tom!

Wenn der Heartbeat 3 Sec. beträgt, kann man nach >8 Sec auf jeden Fall ausloggen können. Wenn dann mal ein Request verloren geht, sollte die "Verbindung" trotzdem bestehen bleiben.

Jetzt mal von mir nachgefragt:

• Wozu soll das gut sein?
• Wer hat was davon?

Ich würde mich vermutlich bedanken (und JS für die Seite sofort deaktivieren oder die Seite schließen), wenn alle meiner durchschnittlich 30 geöffneten Seiten das so machen würden.

Zum Thema:
Wie macht ebay das eigentlich (hat mich bisher nicht interessiert)?
Die haben doch vor einigen Monaten diesbezüglich auch mal etwas an ihren Skripten umgemodelt. Seitdem muss man innerhalb der letzten 15(?) Minuten einer Auktion nicht mehr selber auf "Aktualisieren" klicken, sondern die Restzeit und das aktulle Höchstgebot werden "automatisch" aktualisiert.

Gruß Gunther

[ChrisB]

Hi,

Wie macht ebay das eigentlich (hat mich bisher nicht interessiert)?
Die haben doch vor einigen Monaten diesbezüglich auch mal etwas an ihren Skripten umgemodelt. Seitdem muss man innerhalb der letzten 15(?) Minuten einer Auktion nicht mehr selber auf "Aktualisieren" klicken, sondern die Restzeit und das aktulle Höchstgebot werden "automatisch" aktualisiert.

Na die werden wohl auch regelmäßige Requests absetzen - entweder per AJAX, oder Meta-Refresh, wenn's "abwärtskompatibler" sein soll.

Das wäre dann nur eine schlichte, regelmäßige Nachfrage an den Server, "teile mir mal den aktuellen Stand mit".
Damit im Prinzip aber immer noch genau andersherum, als das was hier diskutiert wird - nämlich dass der Client alle paar Sekunden ein Zeichen geben soll, "ja, ich lebe noch".

MfG ChrisB

[Der Martin]

Hallo,

Damit im Prinzip aber immer noch genau andersherum, als das was hier diskutiert wird - nämlich dass der Client alle paar Sekunden ein Zeichen geben soll, "ja, ich lebe noch".

eigentlich nicht, sondern es ist genau dieses Prinzip. Nur dass der Client nicht nur regelmäßig die Hand hebt und sagt, "ich bin noch da", sondern dass er stattdessen dauernd fragt, "Was gibt's Neues?"

So long,
 Martin

[ChrisB]

Hi,

eigentlich nicht, sondern es ist genau dieses Prinzip. Nur dass der Client nicht nur regelmäßig die Hand hebt und sagt, "ich bin noch da", sondern dass er stattdessen dauernd fragt, "Was gibt's Neues?"

Ja, aber eben mit entgegengesetztem Vorzeichen: Wer hier *eigentlich* was von wem wissen will, ist genau umgekehrt - ungeachtet dessen, dass es immer der Client ist, der "fragt".

MfG ChrisB

[Tom]

Hello,

eigentlich nicht, sondern es ist genau dieses Prinzip. Nur dass der Client nicht nur regelmäßig die Hand hebt und sagt, "ich bin noch da", sondern dass er stattdessen dauernd fragt, "Was gibt's Neues?"

Ja, aber eben mit entgegengesetztem Vorzeichen: Wer hier *eigentlich* was von wem wissen will, ist genau umgekehrt - ungeachtet dessen, dass es immer der Client ist, der "fragt".

Der einzige Unterschied zur beständigen Statusabfrage des Client besthet hier in der Staffelung der Abfragen, die, wenn sie so funktioniert (wegen der evenetuellen Beschränkung von Connections des Clients zu einer URL), es ermöglicht, den Client auch "abzumelden" am Server, sowie eine Rückfrage ausgeblieben ist, und zwar ohne genrerelles aktives Stück Software am Server, dass das Vorhandensein der Heartbeats für jeden Client prüft.

Ob das "Piep-Sagen" nun alle drei Sekunden oder alle 60 sec. stattfindet, ist dem Geschmack des Programmierers überlassen. Spätestens, wenn er 1440 Sekunden wartet, wird er sowieso mit dem normalen Sessionmechanismus von PHP kollidieren, wenn dies im Einsatz ist und out-of-the-Box benutzt wird.

Es wäre mal interessant zu wissen, was denn die normale Klickrete (Requestrate) eines Surfers z.B. auf einer Kontaktseite ist, auf der ja eher wildes Suchen als ruhiges Lesen angesagt sein dürfte.
Gibt es für das SelfHTML-Forum Statistiken über die Requestrate der Besucher? Sind es eher 1Request/Minute oder noch weniger oder sind es mehr?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

wie wäre es denn, das anders herum zu machen.

Per XMLHttp-Request setzt Du einen Heartbeat ab, vielleicht alle 3 Sek. Nur ein Minimalrequest.
Dieser lässt über die zugehörige Ressource ein Flag setzen. Die Ressource auf dem Server sorgt dafür, dass nach 10 Sek ein Logout stattfindet, wenn nicht der nächste AJAX-Request das Flag wieder gelöscht hat (uns selber wieder ein neues gesetzt hat). Wurde das Flag vom nächsten Request gelöscht, gibts sofort (also nicht nach 10, sondern nach 3 Sek) als Response den Key für den übernächsten Request. usw.

Also quasi häkeln lernen.

Der Abmeldevorgang auf dem Server wird dadurch auch nur in Gang gesetzt, wenn AJAX auf dem Client funktioniert.

Allerdings weiß ich (noch) nicht, ob man parallel zu einem noch offenen AJAX-Request bereits einen nächsten absenden kann.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[BloodySword]

Wäre das nicht sehr Serverbelastend für eine sehr große (ich rede von SEHR große) Community?

Die Idee ist gut und das mit dem 2. Request müsste gehen: Einfach ein weiteres AJAX-Objekt erstellen.

[Gunther]

Hello,

wie wäre es denn, das anders herum zu machen.

und nicht vergessen auch alle 3 Sekunden den Puls des Users zu übermitteln! Wenn = 0 dann Session destroyed!

*SCNR*

Gruß Gunther

[Gunther]

Hallo!

Ich möchte die Session killen, sobald der Benutzer die Seite schließt.

Nein, möchtest du nicht. ;-)
Du möchtest die Session killen, sobald der Besucher die Site verlässt.

Leider passiert dies schon nach dem ersten Login: Die erste Seite wird angezeigt aber die darauf folgende nicht, der user ist somit wieder ausgeloggt, weil ja beim VERLASSEN der letzten Seite onunload ausgelöst wird.

Irgendwie logisch - findest du nicht?

Wie kann ich feststellen, dass der Benutzer das Fenster auch wirklich schließt?

Dazu hat Mathias dir doch schon ausgiebig geantwortet. Ich fasse nochmal kurz zusammen: Gar nicht!

onclose ging leider irgendwie nicht. Kann mir jemand helfen? :(

IMHO du dir selber, indem du dich von der Idee verabschiedest.
In solchen Fällen sollte man Aufwand - Nutzen gegenüberstellen. In deinem Fall scheint mir der Aufwand im Verhältnis zum Nutzen unverhältnismäßig (zumal das Ganze auch nur bei aktiviertem JS überhaupt funktionieren könnte).

Und überhaupt: Worin besteht eigentlich deiner Meinung nach der Nutzen einer solchen Geschichte?

Gruß Gunther

[BloodySword]

Der Nutzen der Geschichte sollte sein, dass der User sofort als offline angezeigt wird. Ansonsten würde dies nur nach 20 Minuten passieren, nachdem die Session abgelaufen ist, ein anderer User ein Klick macht würde der User erst offline gezeigt, weil die Session in der DB erst dann auch gelöscht wird.

Das Logout beim Schließen sollte dies beschleunigen, damit die User sich nicht wundern, wieso die User noch eingeloggt erscheinen obwohl sie nicht antworten/nicht mehr online sind.

[Tom]

Hello,

Der Nutzen der Geschichte sollte sein, dass der User sofort als offline angezeigt wird. Ansonsten würde dies nur nach 20 Minuten passieren, nachdem die Session abgelaufen ist, ein anderer User ein Klick macht würde der User erst offline gezeigt, weil die Session in der DB erst dann auch gelöscht wird.

Das Logout beim Schließen sollte dies beschleunigen, damit die User sich nicht wundern, wieso die User noch eingeloggt erscheinen obwohl sie nicht antworten/nicht mehr online sind.

Wenn Du nur wissen willst, ob der User ein bestimmtes Fenster geöffnet hält, dann geht das ggf. naoch anders.

In einem Frameset ein Nutzframe für die anzuzeigende Seite und ein Blindframe für einen AJAX-Request.
Dieser AJAX-Request erhält vom Server "tröpfchenweise" Antworten. Die sind ihm eigentlich auch egal, darum schmeißt er sie auch gleich in den Mülleimer.

Das Script auf dem Server (PHP) prüft aber nun auf user_abort(). Das ist nun abweichend vom Konzept der Verbindungslosigkeit ein Durchgriff auf tiefere Schichten. Wenn der User das Gesamtfenster schließt und damit auch das Blindframe, dann ist die Verbindung abgebrochen. Der Server merkt das ziemlich gleich beim nächsten Schleifendurchlauf und Prüfung auf connection_status.

http://de3.php.net/manual/en/function.connection-status.php

Ob das auch mit anderen Scriptsprachen geht, weiß ich nicht. Mit PHP habe ich es schon ausprobiert, allerdings nur mit einfachem blinden Frame, dass dann eben vollgemüllt wurde von den "Tröpfchen".

Wenn das Script einen Abort feststellt (dazu muss es selber weiterlaufen!) kann es seinerseits die erforderlichen Maßnahmen ergreifen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[BloodySword]

Klingt auch Interessant. Leider ist die Seite mit DIVs aufgebaut, aber ich kann dennoch einen blinden iFRAME nutzen.

Problem ist aber was passiert, wenn sagen wir mal utopisch gesehen den WORST CASE haben: 1 000 000 User sind online.

Kackt der Server da nicht schon nur wegen der "Bin noch da"-Überwachung ab?

[Tom]

Hello,

Klingt auch Interessant. Leider ist die Seite mit DIVs aufgebaut, aber ich kann dennoch einen blinden iFRAME nutzen.

Nein, kannst Du nicht. Ein blinder iFrame würde _in_ der Seite liegen, in der Du navigieren willst, also mit der Seite bei jedem Request neu aufgerufen werden. Schon Käse!

Ein Geschwister-Frame hingegen ist von dem Frame, in dem Du navigiern willst, unabhängig. Es bleibt bestehen, solange Du nicht das Frameset selber neu lädtst oder eben das blinde Frame gezielt anspeichst.

Problem ist aber was passiert, wenn sagen wir mal utopisch gesehen den WORST CASE haben: 1 000 000 User sind online.

Dann benötigt jeder User dauerhaft einen Port dafür. Und gelegentlich einen weiteren für seine Nutzlast.

Kackt der Server da nicht schon nur wegen der "Bin noch da"-Überwachung ab?

Na, ich will ja nicht so böse werden, wie der ..... es immer macht. Sonst würde ich jetzt sagen: wenn Du 1.000.000 User hättest oder kurzfristig haben könntest, müsstest Du hier nicht Fragen stellen und kostenlose Antworten bekommen, dann könntest du uns dafür bezahlen ;-)

Versuch doch erstmal 10 User zur gleichen Zeit.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[BloodySword]

Stimmt... Aber wenn ich das mit nem Frameset mache, kann ich mir das mit den Requests auch sparen ;). Dann kann ich doch in dem Blindframe den Javascript mit unonload auslösen lassen, der ausloggt! Dieser wird ja nicht beim Navigieren im anderen Frame ausgelöst, sondern nur, wenn man den TAB/Den browser schließt.

Es ist nicht so schlimm, dass der User nicht sofort ausgeloggt wird, wenn der Browser abstürzt, ein Stromausfall ist oder der kleine Bruder den Stecker zieht bzw. der Akku des Notebooks leer geht. Dieser Fall ist außerst selten und wenn ein User sich beim anderen beschwert, wieso er einfach offline ging können diese das selber untereinander regeln. Das ist ja nicht das Problem der Community. Wer es nicht schafft sich ordentlich auszuloggen ist selbst Schuld, dass der User noch 20 Minuten online angezeigt wird.

BTW: Bekommt der Browser ein APM-Signal, wenn der Ruhezustand ausgelöst wird und löst vorher überall onunload aus? Ich denke mal nicht...

Mit der Userzahl hast du schon Recht. Das ist eben unser Ziel/Unser Traum, den wir haben. Deswegen stecken wir (Kumpel und ich) einen Großteil der Freizeit in das geheime Projekt (Deshalb geheim, weil Firmen Ideen klauen könnten). Wir sind so überzeugt von unserem Konzept, dass wir denken, dass wir genug User bekommen werden um das Projekt zumindest eine Weile weiter laufen lassen zu können. Ob man sich damit die goldene Nase verdient kann keiner sagen... Aber wer nicht versucht, der nicht gewinnt.

[Gunther]

Hi!

Der Nutzen der Geschichte sollte sein, dass der User sofort als offline angezeigt wird. Ansonsten würde dies nur nach 20 Minuten passieren, nachdem die Session abgelaufen ist, ein anderer User ein Klick macht würde der User erst offline gezeigt, weil die Session in der DB erst dann auch gelöscht wird.

OK, aber ...
... je nachdem um was für Inhalte es sich handelt (und wie lange die durchschnittliche Verweildauer auf den Seiten ist), könnte man die 20 Minuten ja auch noch verkürzen.

Ich schließe aus deiner Aussage, dass der Userstatus immer angezeigt wird, also kein "Ghost" Modus verfügabr ist. Es soll ja auch User geben, die das gar nicht mögen. ;-)

Das Logout beim Schließen sollte dies beschleunigen, damit die User sich nicht wundern, wieso die User noch eingeloggt erscheinen obwohl sie nicht antworten/nicht mehr online sind.

Nun, es scheint mir so oder so wenig aussagekräftig/ verlässlich. Ich habe bspw. einige Forenseiten manchmal den ganzen Tag über geöffnet (werde also als "online" angezeigt), und antworte deshalb trotzdem nicht unbedingt/ zwingend sofort (oder überhaupt).

Last but not least geht sowieso jeder halbwegs erfahrene Webuser davon aus, dass eine solche On-/ Offline Anzeige mehr "Spielerei", als wirklich verlässliches Instrument ist.

Was ich damit zum Ausdruck bringen will ist, dass es aus meiner Sicht keinen Sinn macht, für solch eine Option auch nur den geringsten Mehraufwand zu betreiben, da der sich ergebende Nutzen in meinen Augen gegen Null tendiert.

Aber das ist natürlich deine Entscheidung - wollte auch nur mal eine andere Sichtweise aufzeigen.

Gruß Gunther

PS: An einer möglichen (technischen) Umsetzung/ Realisierung bin ich aber auch interessiert. Insofern würde ich mich freuen, wenn es hier noch konkretere Ansätze zu lesen geben würde.

[BloodySword]

Da die Session alle 20 Sekunden durch Ajax-aufrufe verlängert wird
reicht es session.gc_maxlifetime = 300 zu setzten, was eine Zeit von 5 Minuten
entspricht. Genau so werden auch die Sessions dann in der DB gelöscht:

$qcos="[code lang=sql]DELETE FROM `sessions`  
                        WHERE `timestamp` < (NOW() - INTERVAL 5 MINUTE)
~~~";[/code]  
  
Diese Query wird bei JEDEN Klick eines beliebigen Users ausgeführt.  
  
Was die "GHOST"-Funkiton angeht: Natürlich wird es noch eine derartige Funktion geben.  
Reicht einfach eine neue Spalte in der Tabelle ``sessions``{:.language-sql}, wo der jeweilige Status  
des Users angegeben wird. :)  
  
Du hast Recht, es ist ein viel zu großer Mehraufwand, der sich nicht lohnt.  
Bei einer Sessiondauer von 5 Minuten ist das ja wohl noch zu verkraften.  
Wenn ein User sich nicht ausloggt, so wird er dann nach 5 Minuten offline  
angezeigt. Das reicht vollkommen aus. Das Wichtigste ist ja auch, dass die  
Session-Files gekillt werden. Tote Sessions müllen den Server zu.  
  
Für alle, die sich dennoch für eine Lösung interessieren: Hier ist sie!  
  
Erstellt ein Frameset mit einem Frame wo eure Site angezeigt wird und ein  
unsichtbares Frame, wo euer AJAX im onunload-Event eingebaut ist. Wenn der  
User rum browst wird er nicht ausgeloggt, erst wenn er das Browserfenster  
oder den Tab schließt. Wer auf Sicher gehen will, kann sich den Server mit  
Requsts per AJAX zumüllen und eine "Bin noch da"-Kopplung basteln.  
  
lg