Laden...

ASP.NET Session beenden beim schließen des Browsers

Erstellt von FranzBeckenbauer vor 10 Jahren Letzter Beitrag vor 10 Jahren 3.009 Views
F
FranzBeckenbauer Themenstarter:in
63 Beiträge seit 2011
vor 10 Jahren
ASP.NET Session beenden beim schließen des Browsers

Hallo liebe Entwickler-Gemeinde.

Ich habe eine AS.NET Webanwendung mit einem paswortgeschützten Bereich.
Darin befindet sich ein Chat-Control von http://programmingwithhardcoderz.blogspot.in/2013/03/facebookgmail-style-aspnet-jquery-ajax.html.

In diesem Chat-Control wird die Anwesenheit der anderen User mit einem Online-Icon angezeigt.

Zu meinem Problem:
Wenn ein User sich nicht sauber von der Anwendung abmeldet (Session beendet),
sind und bleiben die Online-Statuse des Chat-Controls auf "Online".

Dieser Status kann nur über eine Datenbank-Update-Befehl geändert werden.

Gibt es da eine Möglichkeit im Code-Behind einen Code bzw. einen Update-Befehl auszuführen um in der Datenbank den Status zu ändern?

Bin für jede Hilfe dankbar.

16.830 Beiträge seit 2008
vor 10 Jahren

Nein, es gibt keine 100% zuverlässige Methode, um zu erkennen, ob der Client die Seite geschlossen hat.
Das ist aber eine ständig wieder aufkommende Frage, die auch hier schon mehrfach beantwortet wurde.
HTTP ist schließlich ein verbindungsloses Protokoll (=> Grundlagen)

Wenn Du im Chat aber WebSocket verwendest, dann ist das möglich.
Bei SignalR und ASP.NET MVC kann man den Disconnect-Event im Hub abfangen.

Ein Chat ohne WebSocket ist sowieso kein echter Chat.

1.696 Beiträge seit 2006
vor 10 Jahren

Hallo,

die Lösung dafür sollte eigentlich wie ein Forumsoftware sein, d.h. du hast in deiner DB-Tabelle eine DateTime-Spalte "lastaction" für letzte Aktion. Bei jedem Request eines beliebigen Users überprüfst du alle Werte in dieser Spalte, wenn die Zeitdifferenz zum lastaction > X-Wert, dann setzst du den Status auf offline, ansonsten wird die aktuelle Uhrzeit für den aktuellen User und somit auch sein online-Status gesetzt.

Grüße

Ich bin verantwortlich für das, was ich sage, nicht für das, was du verstehst.

**:::

F
FranzBeckenbauer Themenstarter:in
63 Beiträge seit 2011
vor 10 Jahren

Hallo zusammen und danke für eure schnellen Antworten.

vbprogger, eine sehr gute Idee. Werd ich mir noch meine Gedanken darüber machen.

Abt, WebSocket kenn ich leider nicht. Kannst du das etwas verdeutlichen oder hast einen Link für mich? Natürlich kann und werde ich auch danach googeln, aber evtl hast ja nen Tipp für mich parat.

16.830 Beiträge seit 2008
vor 10 Jahren

Bei SignalR und ASP.NET MVC ...

Keine Lust auf Google? [Hinweis] Wie poste ich richtig? 1.1
Gibt unzählige Beispiele, wie WebSockets und SignalR funktioniert - auch wenn mans am Anfang vielleicht etwas kompliziert finden wird.

P
48 Beiträge seit 2005
vor 10 Jahren

Schau mal hier:
ASP.NET SignalR

--
mfG.
Marcel Eckhoff

F
FranzBeckenbauer Themenstarter:in
63 Beiträge seit 2011
vor 10 Jahren

Ok, das sollte voresrt mal reichen an Infos.

Profox, super link.

Vielen dank euch allen für die gute und schnelle Hilfe.

M
402 Beiträge seit 2005
vor 10 Jahren

Hi...

Wenn Du im Chat aber WebSocket verwendest, dann ist das möglich.
Bei SignalR und ASP.NET MVC kann man den Disconnect-Event im Hub abfangen.

Hab mich mit SignalR das ganze Wochenende rumgeärgert,
deswegen hier 2 Punkte dazu...

Bei Websockets/Signalr bzw. im Signalr-Hub kann man zwar das Disconnected-Event abfangen und verarbeiten (wie auch das Connected/Reconnected-Event).
Verwendet man Websockets mit einer "normalen" (Nicht-SinglePage-Application) wird das Disconnected-Event aber bei jedem Seitenwechsel gefeuert (in Kombination mit dem Reconnected-Event).

Zusätzlich kommt noch hinzu dass man aus einem Signalr-Hub keinen Zugriff auf Asp.net - Sessions hat. Es ist also etwas schwierig durch das Disconnected-Event die Session zu "beenden".

lg

16.830 Beiträge seit 2008
vor 10 Jahren

....was daran liegt, dass Sessions für dieses Verbindungsverfahren einfach nicht geeignet sind. Zugriffe auf Sessions würde die Kommunikation und deren Parallelitätseigenschaften stören.
Man kann aber durchaus durch die ConnectionID zB auf den User zugreifen und nicht die SessionID, sondern ZB den UserName speichern.
Auf den HttpContext und dessen Eigenschaften (wie den Authentifizierungsnamen) hat man nämlich durchaus Zugriff.

Technisch gesehen ist das Disconnect-Event beim Seitenwechsel völlig in Ordnung.
Die Seite wird eben aus Code-Sicht geschlossen und neu eröffnet. So ist HTTP halt; und das wirkt sich eben auf WebSockets aus.
Muss man sich eben Gedanken machen, ob man hier eine verzögerte Abfrage etc verwendet oder die Situation anders löst. Dafür ist man doch Entwickler.....