Cronjob zur Überprüfung der Gültigkeit

[Hellraiser666]

Hi,
ich bin seit gestern nach am Überlegen wie ich das am besten anstellen kann, brauch einen Cronjob der mir meine DB durchgeht.
Ich hab ein Login welcher über Session funktioniert, gleichzeitig beim login den ich bin online wert in der db auf 1 setzt.
ebenso logge ich die letzte aktion in unixtime!
jetz möchte ich mit dem cronjob überprüfen ob der user in den letzten 3h aktiv war, wenn nicht die session löschen und den ich bin online wert auf 0 setzen.
wer weiß was?
Gruß Hellraiser

[Encoder]

Andere Frage, was weißt du daran nicht?
Liegts am SQL, an der Einrichtung des Cronjobs, am Sessionhandling, sonst wo?

[Malcolm Beck´s]

hi,

wer weiß was?

Wofür ein Cronjob? Du hast die Uhrzeit der letzten Aktion (so habe ich zumindest dein Posting verstanden); sobald sich der gleiche User (anhand Session identifizierbar) auf der Seite wieder bewegt, vergleichst du die Zeit mit der letzten Aktion und der Aktuellen Uhrzeit;
wenn
Zeit der letzten Aktion (12:35 Uhr) > als das gewünschte Limit (letzte Aktion + Limit), Session löschen.

Letzte Aktion                                      12:35
Es gibt Lebenszeichen von sich (Link geklickt) um  21:48
Du räumst es 3 St. ein, also

12:35 + 3:00 = 15:35
15:35 >=! 21:48
== Session Destroy

oder andersrum rechnen.

mfg

[Alexander (HH)]

Moin Moin!

Vor Urzeiten hatte ich bei einem Projekt mal die Beschränkung, keine brauchbare Cron-Implementation zur Verfügung zu haben. Nach etwas Nachdenken bin ich dann darauf gekommen, dass ich überhaupt keinen Cron-Job für das routinemäßige Löschen inaktiver Sessions brauche:

Nach der "letzten Zuckung" eines Users steht in der Session-Tabelle ein Session-Eintrag mit einem Zeitpunkt, ab dem die Session nicht mehr gültig ist. So lange kein neuer HTTP-Request komnmt, und sei es über Stunden, ist das vollkommen egal. Erst vor der Verarbeitung eines neu eingetroffenen HTTP-Requests muß die Session-Tabelle aufgeräumt werden.

Also habe ich sehr früh im Code, unmittelbar vor Aufruf des individuellen Request-Handlers, alle abgelaufenen Sessions aus der Datenbank gelöscht, mit einem einfachen "DELETE FROM SESSIONS WHERE EXPIRE_TIMESTAMP > NOW()".

Es gab noch die Option, Kommandozeilenutilities zu benutzen, für die waren Sessions aber unbedeutend. Ansonsten hätte ich auch in den entsprechenden Kommandozeilenutilities die Session-Lösch-Funktion aufgerufen.

Alexander

[dedlfix]

Hi!

ich bin seit gestern nach am Überlegen wie ich das am besten anstellen kann, brauch einen Cronjob der mir meine DB durchgeht.

Glaub ich nicht, es geht garantiert auch ohne und das ohne erhöhten Aufwand.

Ich hab ein Login welcher über Session funktioniert,

Du meinst das ganz normale dateibasierende Session-System von PHP, einen eigenen Session-Handler (session_set_save_handler()) oder "nur" ein System das ähnlich arbeitet, aber komplett von dir implementiert wurde?

Das dateibasierende System hat einen Garbage-Collector, ebenso kann man einen dem selbst erstellten Handler implementieren. Der GC läuft bei jedem session_start() los (zufallsgesteuert und konfigurierbar) und räumt abgelaufene Sessiondaten auf. Wenn du diesen bewährten und schon vorhandenen Mechanismus weiterverwendest, musst du nur nohc die Zeiten deinen Bedürfnissen anpassen und noch weitere wichtige Kleinigkeiten beachten, wenn du auf einem System mit mehreren PHP-Anwendern/-Anwendungen arbeitest.

gleichzeitig beim login den ich bin online wert in der db auf 1 setzt.
ebenso logge ich die letzte aktion in unixtime!

Das kannst du unabhängig von der Session setzen. Hier kannst du dir aber das Aufräumen sparen, wenn du nicht nur 1/0 verwaltest sondern nur den Zeitpunkt der letzten Aktivität. Um zu zählen, wieviele "online sind", musst du nur prüfen, wieviele last_action-Zeiten größer als "Jetzt minus $deinInterval" sind anstatt die 1-Werte zu zählen.

Die erwähnten "Kleinigkeiten" beim Mehr-Anwendungen-Betrieb: Du brauchst ein eigenes session.save_path-Verzeichnis, denn der Garbage-Collector läuft mit script-individuellen Konfigurationswerten über sämtliche Dateien im session.save_path. Wenn sich mehrere Anwendungen mit unterschiedlichen Lebenszeiten (session.gc_maxlifetime) den selben session.save_path teilen, räumen sie sich gegenseitig die Sessions zu ungeplanten Zeitpunkten weg.

Lo!