Letzt Useraktivität erkennen

[Martin_Online]

Wie könnte ich folgendes Problem lösen? Ein User loggt sich auf meiner Seite ein, es wird eine Session in die Datenbank geschrieben, erst nach einem klick auf Abmelden wird diese wieder gelöscht.

Soweit ok, aber ich habe etwas Sicherheitsbedenken vor allem wenn ein User in einem Internetcafe  ist.

Ich dachte schon ich lösch den Eintrag nach sagen wir 60 Minuten! Allerdings ich kann nicht einfach alle Einträge löschen, was ist wenn ein User sich erst gerade angemeldet hat?

Dachte schon an folgende Option, es wird geloggt wann ein User eine Seite aufruft, dann hätte ich eine Uhrzeit. Aber mir fällt keine Lösung ein, wie ich auf allen Seiten loggen könnte, wann ein User die Seite aufgerufen hat.

Wie löst ihr solche Probleme?

[Linuchs]

Dachte schon an folgende Option, es wird geloggt wann ein User eine Seite aufruft, dann hätte ich eine Uhrzeit. Aber mir fällt keine Lösung ein, wie ich auf allen Seiten loggen könnte, wann ein User die Seite aufgerufen hat.

Wenn es Seiten sind, die per PHP zusammenzustellen sind, hast du ja Zugriff.

Ansonsten eine Javascript-Datei mit Ajax machen und in alle Seiten einbinden.

Linuchs

[Martin_Online]

Wenn es Seiten sind, die per PHP zusammenzustellen sind, hast du ja Zugriff.

Das heißt ich würde ein PHP Script in jede Seite einbinden dieses ausgeführt wird, wenn ein User diese Seite aufruft. Soweit ok, aber habe ich dadurch nicht eine enorme Menge Updates was den jeweiligen Datensatz betrifft?

[Linuchs]

Das heißt ich würde ein PHP Script in jede Seite einbinden dieses ausgeführt wird, wenn ein User diese Seite aufruft. Soweit ok, aber habe ich dadurch nicht eine enorme Menge Updates was den jeweiligen Datensatz betrifft?

Ja, genau das ist doch der Zweck. Für jede neu aufgerufene Seite setzt du beim User die aktuelle Uhrzeit. User, die xx min nicht aktiv waren, werden automatisch abgemeldet.

[Linuchs]

... setzt du beim User die aktuelle Uhrzeit.

Gemeint ist natürlich, auf deinem Server im User-Stammsatz.

[Tom]

Hello,

Wenn es Seiten sind, die per PHP zusammenzustellen sind, hast du ja Zugriff.

Das heißt ich würde ein PHP Script in jede Seite einbinden dieses ausgeführt wird, wenn ein User diese Seite aufruft. Soweit ok, aber habe ich dadurch nicht eine enorme Menge Updates was den jeweiligen Datensatz betrifft?

Was verstehst Du unter "eine enorme Menge"?

An einen AJAX-Ticker würde ich es nicht anbinden. Das Thema hatten wir hier schon mal. Nur weil schlechte Lösungen oft kopiert werden, sind sie nicht automatisch "best practice".

Aber wieviele normale HTTP/s-Requests pro User und Minute meinst Du denn, dass es unter Normalumständen werden könnten? Wenn man schnell ist, kommen da vielleicht 20/min. zustande, bis man die passende Seite über diverse Menus, Links und Untermenus gefunden hat.

Da schafft eine Datenbank locker 150 gleichzeitige Besucher.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Martin_Online]

Was verstehst Du unter "eine enorme Menge"?

Auf der Seite geht es um Bilder, die Bilder können bewertet & kommentiert werden. Natürlich kann ein User auch Bilder selber hochladen, löschen, bearbeiten usw.

Jede Aktion verursacht einen Aufruf, sprich es würde ständig ein Update in der Datenbank passieren. Ich weiß ja nicht was eine Datenbank so verkraftet.

Wir reden hier von 50 – 100 User gleichzeitig auf der Seite wenn es viel sind. Im Schnitt aber eher weniger.

[Tom]

Hello,

Jede Aktion verursacht einen Aufruf, sprich es würde ständig ein Update in der Datenbank passieren. Ich weiß ja nicht was eine Datenbank so verkraftet.

Wir reden hier von 50 – 100 User gleichzeitig auf der Seite wenn es viel sind. Im Schnitt aber eher weniger.

Bau Dir ein Testscript.

Damit es richtig böse wird:

#----

50 User im Bereich Nr 1 bis 100 anlegen (also mit Lücken) (ID, Updatetime, Daten)

Startzeit messen

Schleife bis 1000
| Datenbankverbindung aufnehmen
| Usernummer auswürfeln in einem Bereich Nummer von 1 bis 100
| Updateversuch mit irgendwelchen Zufallsdaten und der aktuellen Zeit (Timestamp) vornehmen
| Vesuch auswerten, zählen und Ausgabe an Konsole, ob es geklappt hat
| Datenbankverbindung lösen

Endzeit messen

Zeit ausgeben.
Erfolgreiche Versuche
Erfolglose Versuche

#----

Im Testscript fragst Du also nicht nach Username und Passwort, sondern nur nach der ausgewürfelten ID. Sonst wird es zu kompliziert.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

Wie könnte ich folgendes Problem lösen? Ein User loggt sich auf meiner Seite ein, es wird eine Session in die Datenbank geschrieben, erst nach einem klick auf Abmelden wird diese wieder gelöscht.

In Zukunft vermutlich so:
https://forum.selfhtml.org/?t=217753&m=1496753

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

Wie löst ihr solche Probleme?

Ich nehme den in PHP eingebauten Session-Mechanismus. Gegebenenfalls optimiere ich da noch etwas an den Konfigurationswerten. Fertig.

Wenn du unbedingt die Sessiondaten in eine Datenbank schreiben musst, dann kannst du auch dafür den PHP-Mechanismus verwenden.

dedlfix.

[Tom]

Hello,

Wie löst ihr solche Probleme?

Ich nehme den in PHP eingebauten Session-Mechanismus. Gegebenenfalls optimiere ich da noch etwas an den Konfigurationswerten. Fertig.

Wenn du unbedingt die Sessiondaten in eine Datenbank schreiben musst, dann kannst du auch dafür den PHP-Mechanismus verwenden.

Der Sessionmechanismus von PHP sollte aber nur dafür benutzt werden, wofür er gedacht ist:
* Datenhaltung
* Wiedererkennung

aber nicht für Dinge, für die er nicht gedacht ist:
* logische Sessionführung, (Anmeldung/Abmeldung)
* Rechteverwaltung
* zeitliche Sessionführung

Dafür ist eine Datenbank schon der passendere Ort, weil sie
* von mehreren konkurrierenden Prozessen gleichzeitig benutzt werden kann
* sie prozessübergreifende Übersicht verschaffen kann.
* sie für jeden User individuell getrennte
** maximale Sessionzeiten
** Trennung von Session- und Aktivzeit
** direkt abfragbare letzte Aktivität

usw.
ermöglicht.

@martin_online
siehe http://forum.de.selfhtml.org/archiv/2014/1/t216393/#m1483964

Selbstverständlich benötigen die Funktionen auch ein "session_start()" möglichst am Anfang des Scriptes. Sie stehen ja nur für den Datenbankteil des erweiterten Session-Konzeptes.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Martin_Online]

Ich nehme den in PHP eingebauten Session-Mechanismus. Gegebenenfalls optimiere ich da noch etwas an den Konfigurationswerten. Fertig.

Meine Funktion für das Login sieht derzeit wie folgt aus

  
    function login($mysqli, $userMail, $pw) {  
        $stmt = $mysqli->prepare("SELECT user_id FROM web_users WHERE user_emailadresse=? AND user_passwort=? AND user_aktiv=?");  
		$ak = 1;  
        $stmt->bind_param("sss", $userMail, $pw, $ak);  
        $stmt->execute();  
        $stmt->store_result();  
  
		if($stmt->num_rows() === 1) {  
            $stmt = $mysqli->prepare("Update web_users SET user_session=?, user_login=now() WHERE user_emailadresse=? AND user_passwort=?");  
            $stmt->bind_param("ssi", session_id(), $userMail, $pw);  
            $stmt->execute();  
  
            return true;  
        } else {  
            return false;  
        }  

Ok, wenn ich den Browser schließe und neu aufrufe bin ich ausgeloggt, das ist schon einmal sehr gut. Meine Sorge ist einfach, was ist wenn der User an einem öffentlichen PC ist, den Browser nicht schleißt und ein anderer User kommt nach Stunden auf die Seite und kann sich einloggen bzw. er ist ja noch eingeloggt.

[Tom]

Hello,

Ich nehme den in PHP eingebauten Session-Mechanismus. Gegebenenfalls optimiere ich da noch etwas an den Konfigurationswerten. Fertig.

Meine Funktion für das Login sieht derzeit wie folgt aus

Die ist doppelt gemoppelt und enthält ein TOCTTOU-Problem.
Nutze die Datenbank, um die Kontrolle durchzuführen.

Sie dir die Login-Funktion unter http://forum.de.selfhtml.org/archiv/2014/1/t216393/#m1483964 an und bau sie Dir auf Prepared Statements um.

function login($mysqli, $userMail, $pw) {
        $stmt = $mysqli->prepare("SELECT user_id FROM web_users WHERE user_emailadresse=? AND user_passwort=? AND user_aktiv=?");
$ak = 1;
        $stmt->bind_param("sss", $userMail, $pw, $ak);
        $stmt->execute();
        $stmt->store_result();

  if($stmt->num_rows() === 1) {  

$stmt = $mysqli->prepare("Update web_users SET user_session=?, user_login=now() WHERE user_emailadresse=? AND user_passwort=?");
            $stmt->bind_param("ssi", session_id(), $userMail, $pw);
            $stmt->execute();

return true;
        } else {
            return false;
        }

  
  
  
  
Liebe Grüße aus dem schönen Oberharz  
  
  
Tom vom Berg  
![](http://selfhtml.bitworks.de/Virencheck.gif)  
  

-- 
 ☻\_  
/▌  
/ \ Nur selber lernen macht schlau  
[Die ultimative Seite für Selbermacher](http://getscript.de/)

[dedlfix]

Tach!

Meine Sorge ist einfach, was ist wenn der User an einem öffentlichen PC ist, den Browser nicht schleißt und ein anderer User kommt nach Stunden auf die Seite und kann sich einloggen bzw. er ist ja noch eingeloggt.

Deine Sorge sollte nicht auf lange Zeiträume begrenzt sein. Auch wenn der zeitlich unmittelbar folgende Nutzer die Session fortsetzt, hast du dieselben Folgen. Dafür wirst du keine gescheite Lösung finden, außer einem Kompromiss zwischen "zu kurz" und "mehr als ausreichend lang". Und danach muss Session abgelaufen sein. Dazu musst du eben den Zeitpunkt des letzten Zugriffs mitmeißeln.

dedlfix.

[1UnitedPower]

Meine Herren!

Soweit ok, aber ich habe etwas Sicherheitsbedenken vor allem wenn ein User in einem Internetcafe  ist.

Internetcafé-Nutzer sind einem erhöhten Sicherheitsrisiko ausgesetzt und die Café-Betreiber wissen darum und haben in der Regel spezielle Software laufen, die automatisch dafür sorgt, dass die Nutzer keine Spuren hinterlassen. Zumindest war das in den Cafés so, in denen ich bisher war. Ob es eine Auflage oder Richtlinie gibt weiß ich nicht.

Wie löst ihr solche Probleme?

Das Problem stellt sich gar nicht oder es löst sich von selbst. Eine Session wird heute üblicherweise über einen Cookie wiedererkannt. Dieser Cookie sollte eine beschränkte Lebensdauer haben. Bei jedem Seitenaufruf kannst du das Verfallsdatum des Cookies auf t + 60 Minuten Setzen. Wenn das Cookie nicht mehr gültig ist, wird es vom Browser nicht mehr übertragen und die Webseitensitzung kann nicht mehr fortgesetzt werden.

Auf dem Server liegen allerdings weiterhin die Session-Daten, die jetzt unerreichbar sind, weil niemand mehr die SessionID kennt. Diese Daten sind also Müll. AFAIK wird dieser Datenmüll von den Webservern automatisch irgendwann gelöscht oder sie lassen sich so konfigurieren, dass das passiert.

Linuchs und Tom wollten dir vermutlich einen Heartbeat empfehlen. Das ist ein regelmäßiges Signal, dass der Browser an den Server schickt, damit der Server weiß, der Benutzer hat die Seite noch geöffnet. Davon würde ich dir abraten, ich sehe nicht, wie das zur Problemlösung beiträgt, und es kann im schlimmsten Fall sogar noch Schaden anrichten. Zum Beispiel kann es bei unvorsichtiger Programmierung passieren, dass besagtes Session-Cookie nie seine Gültigkeit verliert und als Seiteneffekt wird die Sitzung künstlich am Leben gehalten.

Deine Sitzungen sind offenbar mit Benutzer-Kontos verknüpft, eine weitere Sicherheitsmaßnahme könntest du schaffen, indem du dem Benutzer die Möglichkeit gibst, die Sitzungen die mit seinem Konto assoziiert sind, selbst zu verwalten. Weil Session-IDs für einen solchen Fall wenig aussagekräftig sind, werden die Sitzungen häufig mit einem Fingerabdruck des Endgeräts und einem Zeitpunkt präsentiert. Der Nutzer kriegt dann examplarisch so etwas zu sehen:

1. iOS 6 - Safari 7.1 - letzte Aktivität: vor 7 Stunden
2. Windows - Firefox 35 - letzte Aktivität: vor 3 Wochen

Google bietet so eine Möglichkeit zum Beispiel an, siehe: https://support.google.com/mail/answer/45938

[Tom]

Hello,

Das Problem stellt sich gar nicht oder es löst sich von selbst. Eine Session wird heute üblicherweise über einen Cookie wiedererkannt. Dieser Cookie sollte eine beschränkte Lebensdauer haben. Bei jedem Seitenaufruf kannst du das Verfallsdatum des Cookies auf t + 60 Minuten Setzen. Wenn das Cookie nicht mehr gültig ist, wird es vom Browser nicht mehr übertragen und die Webseitensitzung kann nicht mehr fortgesetzt werden.

Warum ein zusätzliches Cookie einführen?
Der Sessionmechanismus von PHP liefert doch schon ein "Session-Cookie", das automatisch verfällt, wenn man die zugehörige Browser(start)instanz schließt. Anders, als beim HTTP Basic Auth kann man das Cookie beim Abmelden auch zerstören lassen (den Wunsch äußern)

Aber ich weise nochmals darauf hin, dass man zwischen

* Wiedererkennung
* Datenhaltung

und

* logischer Sessionführung
* zeitlicher Sessionführung
...

unterscheiden sollte.

Linuchs und Tom wollten dir vermutlich einen Heartbeat empfehlen.

Nein, ich hätte etwas gegen AJAX zur Aufrechterhatlung der Session und der Heartbeat aus den unteren OSI-Schichten über Websockets ist noch nicht soweit, dass ihn alle Browser unterstützen.

Um das nochmal klarzustellen: Der Heartbeat im TCP-Protokoll ist schon sehr alt (er war üblich, aber nicht unbedingt notwendig, [much more ...] ). HTTP hat ihn in einer höheren Schicht wieder wegoperiert, um ihn dann mittels AJAX in HTML wieder zu emulieren. Das schafft much Overhead!

HTTP wird immer ein Protokoll bleiben, das maximal "halboffne Verbindungen" (-> Google) kann.

AJAX wird bald für Normalentwickler (nahezu) obsolet und durch Websockets ersetzt werden.

Für Martins Anforderung reicht ein requestbasiertes Session-System vollkommen aus. Der benötigt noch keine (Nahezu-)Echtzeiterkennung.

Die Basis liefert dazu PHPs Sessionmechanismus und alle anderen Dinge regelt er über die Datenbank. Er hat das schon vollkommen richtig verstanden.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[1UnitedPower]

Meine Herren!

Warum ein zusätzliches Cookie einführen?

Ich habe nicht von einem zusätzlichen Cookie gesprochen, ich wollte mich auf DAS Session-Cookie beziehen.

[Tom]

Hello,

Warum ein zusätzliches Cookie einführen?

Ich habe nicht von einem zusätzlichen Cookie gesprochen, ich wollte mich auf DAS Session-Cookie beziehen.

Ja, ok. Machen wir das doch.
Das "Session-Cookie" hat ein Ablaufdatum, das dazu führt, dass es verfällt, wenn die dazugehörige Instanz (und ihre Kinder) verfallen.

Es muss nicht "kurz eingestellt" werden, denn es steht schon bei "0".

Die Lebensdauer der Sessiondatei sollte auch nicht die Lebensdauer der Session steuern. Sie begrenzt sie allerdings, ist also bitteschön größer, als die Session.

Wenn wir den wegoperierten bidirektionalen Dialog aus TCP in HTTP zumindest halbseitig wieder emulieren wollen, dann müssen wir auch zulassen, dass der Client nochmal Kontakt aufnimmt mit dem Server, obwohl seine Aktivitäts-Offenzeit bereits abgelaufen war. Das muss nicht zwangsläufig seine Wiedererkennbarkeit killen. Wenn er neu aufsetzt (sich nochmals autentifiziert), kann er weiterarbeiten.

Außerdem könnten andere teilnehmer bereits Hinweise darauf bekommen, dass dieser Teilnehmer schon auf "gelb" steht, noch bevor dessen Session abläuft. das lässt sich alles nur mit Hilfe der Sessiondatei nur schwer lösen.

Deshalb:

• Individuelle temporäre Daten des Users in die Sessiondatei
• für mehrere User und die Administration relevante Daten in eine gemeinsame Datenhaltung,
    also z.B. eine Datenbank

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[1UnitedPower]

Meine Herren!

Ja, ok. Machen wir das doch.
Das "Session-Cookie" hat ein Ablaufdatum, das dazu führt, dass es verfällt, wenn die dazugehörige Instanz (und ihre Kinder) verfallen.

Wessen Instanz, wessen Kinder? Das Session-Cookie verfällt, wenn sein Verfallsdatum abgelaufen ist, nicht früher nicht später. Es kann aber passieren, dass das Cookie eine Session-ID trägt, die auf dem Server nicht mehr existiert.

Es muss nicht "kurz eingestellt" werden, denn es steht schon bei "0".

"0" ist kein gültiger Wert für expires. Für max-age kann man "0" angeben, das bedeutet aber, dass das Cookie bereits ungültig ist, weil das Ablaufdatum auf einen implementationsabhängigen Zeitpunkt in der Vergangenheit verweist. Für die meisten Implementation dürfte das dann wohl der Start der UNIX-Epoche sein.

Die Lebensdauer der Sessiondatei sollte auch nicht die Lebensdauer der Session steuern. Sie begrenzt sie allerdings, ist also bitteschön größer, als die Session.

Ich habe nie von der Lebensdauer der Session-Datei gesprochen. Da hast du mich auch hier schon missverstanden. Ich habe versucht die zeitliche Abfolge zu erklären, wann eine Sitzung unerreichbar wird, weil die Session-ID nicht mehr existiert, wann die Session-Daten zu Müll verkommen und wann sie endgültig gelöscht werden.

Wenn wir den wegoperierten bidirektionalen Dialog aus TCP in HTTP zumindest halbseitig wieder emulieren wollen

Jetzt habe ich den Faden verloren, reden wir immer noch über Sessions?

Außerdem könnten andere teilnehmer bereits Hinweise darauf bekommen, dass dieser Teilnehmer schon auf "gelb" steht, noch bevor dessen Session abläuft.

Beschreibe das Szenario, das du hier für problematisch hältst bitte mal etwas genauer. Ich kann dir nicht ganz folgen.

[Tom]

Hello,

Wessen Instanz, wessen Kinder? Das Session-Cookie verfällt, wenn sein Verfallsdatum abgelaufen ist, nicht früher nicht später. Es kann aber passieren, dass das Cookie eine Session-ID trägt, die auf dem Server nicht mehr existiert.

Wo wird das Cookie denn angelegt? Dort verfällt es auch!

Es muss nicht "kurz eingestellt" werden, denn es steht schon bei "0".

"0" ist kein gültiger Wert für expires. Für max-age kann man "0" angeben, das bedeutet aber, dass das Cookie bereits ungültig ist, weil das Ablaufdatum auf einen implementationsabhängigen Zeitpunkt in der Vergangenheit verweist. Für die meisten Implementation dürfte das dann wohl der Start der UNIX-Epoche sein.

Guckst Du unter "transienter Cookie" im Gegensatz zu "persistenter Cookie". Googlen musst Du bitte mal alleine.

Hier nur ein erster Teffer: http://searchsoa.techtarget.com/definition/transient-cookie

Wenn wir den wegoperierten bidirektionalen Dialog aus TCP in HTTP zumindest halbseitig wieder emulieren wollen

Jetzt habe ich den Faden verloren, reden wir immer noch über Sessions?

Wir reden über Sessions.
Mit TCP kann man eine Session sehr leicht kontrollieren, da beide Partner jederzeit feststellen können, ob der andere noch da ist.

Eine Session stellt die etablierte zustandsorientierte Verbindung zwischen (zwei) (gleichberechtigten)  Kommunikationspartern dar. TCP ermöglicht dies. In HTTP ist diese Fähigkeit "wegoperiert"; dort gibt es dedizierte Clients und Server.

Session hat erstmal überhaupt nichts mit Berechtigungen auf hinterliegende Systeme zu tun (Datenhaltung, Programme, ...).

Außerdem könnten andere teilnehmer bereits Hinweise darauf bekommen, dass dieser Teilnehmer schon auf "gelb" steht, noch bevor dessen Session abläuft.

Beschreibe das Szenario, das du hier für problematisch hältst bitte mal etwas genauer. Ich kann dir nicht ganz folgen.

Im Archiv findest Du dazu von mir genügend Beschreibungen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[1UnitedPower]

Meine Herren!

Wessen Instanz, wessen Kinder? Das Session-Cookie verfällt, wenn sein Verfallsdatum abgelaufen ist, nicht früher nicht später. Es kann aber passieren, dass das Cookie eine Session-ID trägt, die auf dem Server nicht mehr existiert.

Wo wird das Cookie denn angelegt? Dort verfällt es auch!

Bingo. Und wenn es verfällt, gibt es keinen mehr, der die Session-ID kennt. Die Session ist damit unerreichbar. Das verfolgte Ziel des Fragestellers ist erreicht.

Es muss nicht "kurz eingestellt" werden, denn es steht schon bei "0".

"0" ist kein gültiger Wert für expires. Für max-age kann man "0" angeben, das bedeutet aber, dass das Cookie bereits ungültig ist, weil das Ablaufdatum auf einen implementationsabhängigen Zeitpunkt in der Vergangenheit verweist. Für die meisten Implementation dürfte das dann wohl der Start der UNIX-Epoche sein.

Guckst Du unter "transienter Cookie" im Gegensatz zu "persistenter Cookie". Googlen musst Du bitte mal alleine.

Können wir keinen freundlichen Ton wahren? Ich habe im RFC 6265 nachgeschlagen, du kannst es da gerne selber nachlesen. Dass du auf transiente Cookies hinaus wolltest, war mir nicht klar. Und erlaube mir zu urteilen, dass deine Beschreibung auch irreführend war.

Aber ich gebe dir Recht, mit transienten Cookies kann das Problem auch gelöst werden. Allerdings führt ein Browser-Neustart dann stets zu einem Verlust der Sitzung.

Wenn wir den wegoperierten bidirektionalen Dialog aus TCP in HTTP zumindest halbseitig wieder emulieren wollen

Jetzt habe ich den Faden verloren, reden wir immer noch über Sessions?

Wir reden über Sessions.
Mit TCP kann man eine Session sehr leicht kontrollieren, da beide Partner jederzeit feststellen können, ob der andere noch da ist.

Eine Session stellt die etablierte zustandsorientierte Verbindung zwischen (zwei) (gleichberechtigten)  Kommunikationspartern dar. TCP ermöglicht dies. In HTTP ist diese Fähigkeit "wegoperiert"; dort gibt es dedizierte Clients und Server.

Und es gibt eben Sessions, wie sie nativ in PHP implementiert sind, und die wir nicht neu implementieren müssen. Es existiert bereits eine Abstraktionsebene, um Sitzungen über mehrere HTTP-Roundturns zu simulieren, eine Diskussion über die TCP-Grundlagen empfinde ich an dieser Stelle als müßig.

Außerdem könnten andere teilnehmer bereits Hinweise darauf bekommen, dass dieser Teilnehmer schon auf "gelb" steht, noch bevor dessen Session abläuft.

Beschreibe das Szenario, das du hier für problematisch hältst bitte mal etwas genauer. Ich kann dir nicht ganz folgen.

Im Archiv findest Du dazu von mir genügend Beschreibungen.

Meine Suche nach "Tom gelb" blieb recht erfolglos. Wenn du nicht bereit bist, über diese Punkt zu diskutieren, solltest du ihn vielleicht nicht zur Sprache bringen. Nachhaken ist in diesem Forum eben üblich.

[Tom]

Hello,

Guckst Du unter "transienter Cookie" im Gegensatz zu "persistenter Cookie". Googlen musst Du bitte mal alleine.

Können wir keinen freundlichen Ton wahren?

Was gefällt Dir denn an "bitte" nicht?

Ich habe im RFC 6265 nachgeschlagen, du kannst es da gerne selber nachlesen. Dass du auf transiente Cookies hinaus wolltest, war mir nicht klar. Und erlaube mir zu urteilen, dass deine Beschreibung auch irreführend war.

Um mit PHP einen transienten Cookie zu erzeugen, setzt man die Zeit auf 0. Die Übersetzung in "keinen Expires-Header mitgeben" macht PHP. Das stand früher auch mal irgendwo. Ich kann leider gerade nicht gucken im Web-Manual. Da klemmt mal wieder die Verbindung.

Der Rest mag Dir müßig erscheinen, er ist aber Grundlage. Und da ich mich im wesentlichen an das Anliegen des OP halte, finde ich den Hinweis auf die Protokolle gar nicht überflüssig.

Der Sessionmechanismus in PHP stellt nur die Basisfunktionalität zur Verfügung, um aus dem zustandslosen HTTP wieder eines mit Fähigkeit zu halboffenen Verbindugnen zu machen. Außerdem sollte man die Lebensdauer der Sessiondatei nicht für das Timeout des "Login" missbrauchen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[1UnitedPower]

Meine Herren!

Guckst Du unter "transienter Cookie" im Gegensatz zu "persistenter Cookie". Googlen musst Du bitte mal alleine.

Können wir keinen freundlichen Ton wahren?
Was gefällt Dir denn an "bitte" nicht?

Mir gefällt nicht, dass du mich darum bittest eine Suchmaschine zu bemühen, wo es nicht angebracht ist. Mir kam es sinngemäß so vor, als solle ich dir Wünsche von den Lippen ablesen. Vielleicht war es auch anders gemeint.

Ich habe im RFC 6265 nachgeschlagen, du kannst es da gerne selber nachlesen. Dass du auf transiente Cookies hinaus wolltest, war mir nicht klar. Und erlaube mir zu urteilen, dass deine Beschreibung auch irreführend war.

Um mit PHP einen transienten Cookie zu erzeugen, setzt man die Zeit auf 0. Die Übersetzung in "keinen Expires-Header mitgeben" macht PHP. Das stand früher auch mal irgendwo. Ich kann leider gerade nicht gucken im Web-Manual. Da klemmt mal wieder die Verbindung.

Gut, das wusste ich nicht.

Der Rest mag Dir müßig erscheinen, er ist aber Grundlage. Und da ich mich im wesentlichen an das Anliegen des OP halte, finde ich den Hinweis auf die Protokolle gar nicht überflüssig.

Ich empfinde den Hinweis auf Websockets überhaupt nicht nah an der Fragestellung und deshalb ist mir der Zusammenhang wohl auch nicht gleich ins Auge gesprungen. Inzwischen habe ich eine Ahnung von deiner Intuition und kann den Hinweis nachvollziehen.

[Tom]

Hello,

Der Rest mag Dir müßig erscheinen, er ist aber Grundlage. Und da ich mich im wesentlichen an das Anliegen des OP halte, finde ich den Hinweis auf die Protokolle gar nicht überflüssig.

Ich empfinde den Hinweis auf Websockets überhaupt nicht nah an der Fragestellung und deshalb ist mir der Zusammenhang wohl auch nicht gleich ins Auge gesprungen. Inzwischen habe ich eine Ahnung von deiner Intuition und kann den Hinweis nachvollziehen.

Das freut mich. Ärgern wollte ich Dich jedenfalls nicht! Das würde ganz anders aussehen :-P

Die Nutzung von Websockets ermöglicht echte Sessions zwischen Browser und Gegenseite. Es gibt dann im Prinzip keinen Server und keinen Client mehr. Beide Seiten sind gleichberechtigt und können der anderen Meldungen schicken.

Allerdings wird man für die Praxis ahsu hier noch eine Protokollschicht aufsetzen müssen, die es ermöglicht, Logins zu ermöglichen, mehrere Domains zu bedienen (ala VirtHosts), Aufgaben zu identifizieren (RPC-Deklarationen), Daten zu typisieren und zuzuordnen (definition von "Masken" im Gegensatz zu Markup), usw.,

Anderenfalls werden die WS als Billig-Chat verhungern.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[1UnitedPower]

Meine Herren!

Auf dem Server liegen allerdings weiterhin die Session-Daten, die jetzt unerreichbar sind, weil niemand mehr die SessionID kennt. Diese Daten sind also Müll. AFAIK wird dieser Datenmüll von den Webservern automatisch irgendwann gelöscht oder sie lassen sich so konfigurieren, dass das passiert.

Ich habe gerade nochmal im PHP-Manual nachgesehen, und an dieser Stelle müssen wir etwas genauer differenzieren: Aus PHPs Perspektive verkommen die Sitzungsdaten erst zu Datenmüll, wenn die Zeitspanne abgelaufen ist, die in session.gc_maxlifetime eingestellt wurde.

[Tom]

Hello,

Auf dem Server liegen allerdings weiterhin die Session-Daten, die jetzt unerreichbar sind, weil niemand mehr die SessionID kennt. Diese Daten sind also Müll. AFAIK wird dieser Datenmüll von den Webservern automatisch irgendwann gelöscht oder sie lassen sich so konfigurieren, dass das passiert.

Ich habe gerade nochmal im PHP-Manual nachgesehen, und an dieser Stelle müssen wir etwas genauer differenzieren: Aus PHPs Perspektive verkommen die Sitzungsdaten erst zu Datenmüll, wenn die Zeitspanne abgelaufen ist, die in session.gc_maxlifetime eingestellt wurde.

Frühestens! Wenn wenig Betrieb ist, könnte die Datei auch nach Wochen noch da sein!

Es gibt aber auch Distributionen, die diesen Mechanismus nicht dem Zeit-Zufall überlassen, sondern ihn durch einen Cronjob regeln. Dann stimmt diese "Haltbarkeitsdauer nach letztem Zugriff" minutengenau.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg