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