Mich würde interessieren was Ihr für kreative Ansätze habt abgelaufene Sessions zu löschen. Hintergrund: Eine Webanwendung mit Serverkomponenten in PHP, DB-Anbindung an MySQL. Das Sessionhandling ist PHP-Standard. Die Sessions werden in einer Memory-Tabelle in der DB gespeichert. Die Sessions haben eine Laufzeit nach deren Ablauf soll ein Zwangslogout stattfinden.
Zur Zeit habe ich folgende Möglichkeiten im Einsatz:
- Cronjob gesteuert zu bestimmten Zeiten. -> ist blöd weil die Nummer auf einem Windows Server 2003 läuft und mit der Scheduler schon des öfteren im Stich gelassen hat. Passt nicht ganz zum Zwangslogout-Gedanken.
- Immer bei Login eines beliebigen Nutzers. -> geht mir zu sehr auf die Performance und ausserdem kann man sich ja nicht darauf verlassen daß sich die User auch regelmäßig einloggen. Passt auch nicht zur Zwangslogout-Idee
- Per Eventhandler. -> Selbst erstellter Listener auf lokaler Maschine nimmt events mit Ausführungsdatum an und handelt diese dann ab. Setzt die Timout-Idee bestens um, hat aber einige Nachteile.
naja, wenn die Daten wie du sagst in einer Memory Tabelle liegen, wärs doch performancetechnisch vertretbar bei jedem Aufruf des Scripts nach abgelaufenen Sessions zu schauen, oder?
Zweiteres. Am besten unabhängig von Transaktionen innerhalb der Web-Applikation und zum individuellen Ablaufzeitpunkt.
Aber das will ich nicht, sondern ich mache es ja schon. Wollte nur mal fragen was für Ideen die Community so hat, ob es "bessere" Wege als die meinen gibt.
Ob bei Windows generell ein Problem besteht kann ich nicht sagen, aber auf meinem Server 2003 ist das so. Das PHP-Cmdline-Tool ist ja im Prinzip der von mir eingesetzte Eventhandler. Der bekommt über einen internen Socket einen Timestamp und einen Codeschnipsel und führt den zur gegebenen Zeit aus.
Welche Probleme/Nachteile hast du denn damit, die du in deiner Frage angesprochen hast? Hab mal nen Beispielcode an meinen Beitrag gehängt wie ich es meinte.
Das Script kannste dann aber jedes mal neustarten, wenn du einen Server-Reset machst. Sowas vergisst man auch gern mal :) Müßte also zusätzlich noch in irgendein Startscript eingebunden werden.
Das einbinden in eine Startscript sollte ja eigentlich auch nicht das Problem sein, auch wenn der SQL-Server, Apache und der Scheduler von Windows das von allein machen. XD
@Flyingmana: das Problem tritt auf, wenn der Prozess "wegschmiergelt" ihn a) neu zu starten und b) die queue wieder herzustellen und c) die verpassten events "vernünftig" abzuhandeln. Ist aber auch eher ein Problem wenn sehr viele events in der Queue stecken.
Ein anderes Thema sind verlorene DB-Connections unter PHP beim Multithreading.
Ich wollte ja auch nur mal abchecken, was ihr so für ideen habt...
Eine Idee könnte sein, die Session-Lifetimes bei jedem Seitenaufruf zu checken. Um die Performance dabei zu schonen werden dann nicht sämtliche Sessions, sondern nur 10 oder 100 abgefragt und ggf. gekillt. Ich weiß, ist nicht die beste Lösung, aber immerhin werden so kontinuierlich alte Sessions gekillt und die Performance geht nicht bei einzelnen Logins total in die Knie. Hängt auch ein bißchen davon ab, über wie viele Datensätze wir hier sprechen.
Hallo, das geht am besten, indem Du bei jedem korrekten Seitenaufruf ein Timestamp in einer DB aktualisierst, und sobald eine Anfrage mit der gleichen Session-ID kommt, für welche die Zeitspanne (z.B. 15 Minuten) abgelaufen ist, killst Du diese Session und der ggf. kurz eingenickte User muss sich neu einloggen oder was auch immer das Erzeugen einer neuen Session veranlassen kann. Damit werden zwar nicht automatisch alle alten Sessions gelöscht, aber das Sicherheitsrisiko, dass jemand eine Session kidnappt, wird recht deutlich verringert.
Hmm, eigentlich müßte das doch voll automatisch über den garbage collector gemacht werden. Zumindest ist genau das von PHP so vorgesehen. Dazu stellt man in der php.ini folgende Werte ein:
Das heißt nach 24 Min wird eine Session als "veraltet" deklariert. Beim nächsten Seitenaufruf werden dann die veralteten Sessions mit einer Wahrscheinlichkeit von 1/100 also 1% gelöscht. Testweise kann man gc_probability auf 100 stellen, dann werden die Dateien auf jeden Fall nach 24 min gelöscht.
Genau so ist es, man muss nicht automatisch die Session Dateien löschen, die werden gelöscht sobald die Session abgelaufen ist, mit den von Scout genannten Einstellungen!
Wenn du die Session vorzeitig beenden willst, ist das was anderes, aber du schreibst doch wie abgelaufene Sessions gelöscht werden, das passiert automatisch!
Natürlich sollte man hier auch die SessionHandler gemäß php-Handbuch in eine statische Handler-Klasse umleiten. Das DB-Modell sollte dann eine current_timestamp-Spalte haben (touchdate). Dieses kann dann alternativ zu created verwendet werden.
mach ich ja schon, es geht darum die nicht korrekt beendeten oder inaktiven Session zu löschen. Das geht ja nur Zeitgesteuert. Das "Wie kille ich die Session" ist nicht das Problem, sondern mehr das "Wie veranlasse ich das Killen"
Ich glaube er meint, wie man bei einem datenbankbasierten Sessionhandling alte Datenzeilen löscht. Nicht wie man die Inhalte der aktuellen Session zurücksetzt. Die Datenzeile bleibt dabei in der DB erhalten.
Hä? Also, wenn du einen eigenen Session Handler geschrieben hast, sollte der ja wohl einen gc()-Callback (Garbage Collection) haben. Der ist dafür zuständig, die Session aus der DB zu löschen. Der eigentliche "Zwangslogout" wird auf dem Client (ein Browser?) implementiert: Der sollte - idealer Weise mit einem Ajax-Request - regelmäßig den Server fragen, ob die session noch existiert. Wenn nicht -> Logout.
naja, wenn die Daten wie du sagst in einer Memory Tabelle liegen, wärs doch performancetechnisch vertretbar bei jedem Aufruf des Scripts nach abgelaufenen Sessions zu schauen, oder?