Eigenes Session-Handling : Speicheraufräumroutine

[basi]

Hi,

ich schreibe gerade an einem eigenen Session-Handling, das auf DB-Basis arbeitet.

Die Funktionen dafür habe ich geschrieben (open, write, etc.). Dafür muss man ja auch die 'Speicheraufräumroutine' schreiben, die alte Sessions entfernt (also z.B. function sess_gc($lifetime){...}).
Meine Frage ist nun, wann die gestartet wird. In allen Quellen, die ich durchforstet habe, steht, dass die automatisch gestartet wird, PHP anhand eines Verhältniswertes entscheidet, wann die laufen soll.
Damit kann aber nicht die Zeitspanne $lifetime gemeint sein, anhand der alte Sessions erkannt werden. Was ist das für ein Verhältniswert?
Grüße, basi

[Lude]

Hi,

Die Funktionen dafür habe ich geschrieben (open, write, etc.). Dafür muss man ja auch die 'Speicheraufräumroutine' schreiben, die alte Sessions entfernt (also z.B. function sess_gc($lifetime){...}).
Meine Frage ist nun, wann die gestartet wird.

ich mache es so:

• bei jeder Anforderung des Browserclients pruefe ich ob die Differenz zwischen Sitzungsbeginn und aktueller Zeit nicht groesser als das definierte Sitzungs-Timeout ist und gewaehre dann Datenzugriff oder nicht
• ein Job raeumt einmal am Tag "alte" Sitzungen weg

Das scheint mir einfacher, als die von Dir erwaehnten Mechanismen zu implementieren.

Gruss,
Lude

[basi]

Hi,

• bei jeder Anforderung des Browserclients pruefe ich ob die Differenz zwischen Sitzungsbeginn und aktueller Zeit nicht groesser als das definierte Sitzungs-Timeout ist und gewaehre dann Datenzugriff oder nicht

Ja, aber nach Ablauf des Timeouts muss dann ja immer ne neue Session gestartet werden. Ich checke bei Anforderung in der open()-Funktion, ob die Session schon da ist - wenn ja, setze ich das Feld lastaccess auf die aktuelle Zeit. Das Timeout ist auf 10 Minuten gesetzt. Wenn der User in dieser Zeit nix macht, soll die Session beendet werden. Das soll dann diese Aufräumroutine erledigen. Ist ja eigentlich auch nicht komplizierter. Deswegen will ich eben wissen, wann die Routine startet (und checkt, welche Session länger als zehn Minuten nicht gemacht hat).

Danke schon mal.

Gruß, basi

[Lude]

Hi,

Ja, aber nach Ablauf des Timeouts muss dann ja immer ne neue Session gestartet werden.

Nein. Du kannst a) Deine Sitzungen bei jedem Datenzugriff verlaengern oder b) das Sitzungstimeout so hoch setzen, dass es praktisch nicht zum Ereignis Timeout kommt.

Ich checke bei Anforderung in der open()-Funktion, ob die Session schon da ist - wenn ja, setze ich das Feld lastaccess auf die aktuelle Zeit.

Also Variante a).

Das Timeout ist auf 10 Minuten gesetzt. Wenn der User in dieser Zeit nix macht, soll die Session beendet werden. Das soll dann diese Aufräumroutine erledigen.

Du kasst beim Datenzugriff pruefen. Dann musst Du den Sitzungsdatensatz keineswegs sofort wegraeumen.

Ist ja eigentlich auch nicht komplizierter. Deswegen will ich eben wissen, wann die Routine startet (und checkt, welche Session länger als zehn Minuten nicht gemacht hat).

Die Routine sollte m.E. bei jedem Datenzugriff pruefen. Ist doch einfach oder? Wegraeumen hat erst einmal nichts mit dem Sitzungskonzept zu tun; das ist eigentlich Datenadministration.

Gruss,
Lude

[basi]

Du kasst beim Datenzugriff pruefen. Dann musst Du den Sitzungsdatensatz keineswegs sofort wegraeumen.

Jo, das stimmt. Ich dachte, so werden es nicht zuviel Datensätze in der Tabelle. Aber die Anzahl ist wahrscheinlich kein gravierendes Problem.

Die Routine sollte m.E. bei jedem Datenzugriff pruefen. Ist doch einfach oder? Wegraeumen hat erst einmal nichts mit dem Sitzungskonzept zu tun; das ist eigentlich Datenadministration.

Das Konzept läuft auch so, wie ich es mir gedacht habe. Dann mache ich es erst mal so, dass der DS stehen bleibt.

Danke Dir.

Gruß, basi

[Christian Gerner]

Hallo,

welche Vorteile hat ein eigenes Session-Handling?

Gruß,
Christian

[Lude]

Hi,

welche Vorteile hat ein eigenes Session-Handling?

bessere Skalierbarkeit. Ausserdem entsteht noch "paedagogischer Nutzen".

Gruss,
Lude

[basi]

welche Vorteile hat ein eigenes Session-Handling?

Dazu zitiere ich mal aus dem Buch, mit dem ich arbeite (PHP4 von Jörg Krause):

"[...]Dafür werden alle sicher in einer Tabelle gespeichert, was mehrere Vorteile hat: Keine Manipulation von außen möglich, Keine Cookies erforderlich, Abruf der Anzahl der aktiven Sessions einfach möglich [...] Insgesamt ist diese Sessionverwaltung extrem sicher gegenüber Angriffen von Hackern, robust und über die DB sehr gut skalierbar.[...]"
Dazu hat er noch was von Lastverteilung geschrieben, weil keine lokal gespeicherten Daten vorhanden sind und PHP auf mehrere Rechner verteilt werden kann. Da hab ich aber noch nicht weiter drüber nachgedacht... ;)

[Sven Rautenberg]

Moin!

welche Vorteile hat ein eigenes Session-Handling?

Dazu zitiere ich mal aus dem Buch, mit dem ich arbeite (PHP4 von Jörg Krause):

"[...]Dafür werden alle sicher in einer Tabelle gespeichert,

Sind die gewöhnlichen Session-Textdateien nicht sicher?

was mehrere Vorteile hat: Keine Manipulation von außen möglich,

Wer seinem Hosting-Rechner nicht vertraut, hat natürlich verloren. Auch bei Datenbankspeicherung.

Keine Cookies erforderlich,

Das hat mit dem alternativen Session-Handling auf PHP-Seite nichts zu tun.

Abruf der Anzahl der aktiven Sessions einfach möglich [...]

Stimmt. Wenn man die Datenbank entsprechend strickt. TIMESTAMP-Feld sollte reichen.

Insgesamt ist diese Sessionverwaltung extrem sicher gegenüber Angriffen von Hackern,

Nein, nicht besser, als sonst auch.

robust und über die DB sehr gut skalierbar.

Ob die Robustheit steigt, will ich nicht beurteilen. Die Skalierbarkeit steigt aber tatsächlich aufgrund der Datenbank.

Dazu hat er noch was von Lastverteilung geschrieben, weil keine lokal gespeicherten Daten vorhanden sind und PHP auf mehrere Rechner verteilt werden kann. Da hab ich aber noch nicht weiter drüber nachgedacht... ;)

Stimmt, das ist ein netter Vorteil. Man kann Lastverteilung betreiben, indem PHP auf mehreren Servern läuft, aber zentral auf die Session-Datenbank zugreift.

Allerdings: _Wenn_ man sowas macht, dann hat man in der Regel auch volle Kontrolle über seine Server. Und dann muß man seine Session-Daten innerhalb des Servers auch nicht gegen böse andere Menschen abschotten, die auf demselben Server arbeiten.

Allerdings: Die typische Konstruktion von PHP+MySQL sieht vor, dass beides auf derselben Hardware läuft. Und da MySQL die Daten in Dateien schreibt (wie sollte man sonst etwas dauerhaft speichern?), kommt der Vorteil "Speichert nicht in Dateien", der ja in der Realität nicht wirklich vorhanden ist, nicht wirklich zum Tragen.

Fazit: Es hat _leichte_ Vorteile, das Sessiondaten-Speichern selbst zu programmieren, in aller Regel aber ist es für die meisten Fälle irrelevant, wie die Session-Daten gespeichert werden.

- Sven Rautenberg

[Christian Gerner]

Hallo,

Und da MySQL die Daten in Dateien schreibt (wie sollte man sonst etwas dauerhaft speichern?), kommt der Vorteil "Speichert nicht in Dateien", der ja in der Realität nicht wirklich vorhanden ist, nicht wirklich zum Tragen.

Genau deshalb habe ich gefragt. Das mit der Lastverteilung auf verschiedenen Rechnern kann ich nicht beurteilen. Jede Session-ID ist eindeutig und von einem Benutzer erfolgt i.d.R. immer nur ein Zugriff. Es besteht also nicht die Gefahr, dass mehrere Änderung an der Datei gleichzeitig gemacht werden (sollen). Insofern könnte man die Session-Dateien ja auch in einem Verzeichnis speichern, das auf allen Servern gemountet ist (z.B. mit NFS) und somit könnte man auch in diesem Fall mySQL vermeiden. Wie das mit den Zugriffszeiten ist weiß ich nicht, aber normalerweise speichert man ja auch keine größeren Datensätze in einer Session.
Oder übersehe ich da jetzt etwas?

Fazit: Es hat _leichte_ Vorteile, das Sessiondaten-Speichern selbst zu programmieren, in aller Regel aber ist es für die meisten Fälle irrelevant, wie die Session-Daten gespeichert werden.

Ich denke in den meisten Fällen lohnt sich ein eigenes Session-Handling einfach nicht. Man erfindet das Rad neu und ist darauf angewiesen, evtl. Sicherheitslücken selbst zu finden. Die "normalen" PHP-Sessions werden auf hunderten Servern verwendet.

Gruß,
Christian

[Sven Rautenberg]

Moin!

Insofern könnte man die Session-Dateien ja auch in einem Verzeichnis speichern, das auf allen Servern gemountet ist (z.B. mit NFS) und somit könnte man auch in diesem Fall mySQL vermeiden. Wie das mit den Zugriffszeiten ist weiß ich nicht, aber normalerweise speichert man ja auch keine größeren Datensätze in einer Session.
Oder übersehe ich da jetzt etwas?

Vielleicht ja. Datenbanken bieten immerhin die Möglichkeiten, gewisse Caching-Mechanismen einzusetzen. Wenn die Session-DB beispielsweise komplett im RAM gehalten wird, ist das sehr performant. Mit NFS hingegen geht sowas nur eingeschränkt, würde ich behaupten.

Außerdem besteht mit Dateispeicherung eben weiterhin der Nachteil, dass man in einem Skript keinen leichten Überblick über alle Sessions erhalten kann. Eine Datenbank macht das sehr einfach, Dateisysteme machen das komplizierter.

Ich denke in den meisten Fällen lohnt sich ein eigenes Session-Handling einfach nicht. Man erfindet das Rad neu und ist darauf angewiesen, evtl. Sicherheitslücken selbst zu finden. Die "normalen" PHP-Sessions werden auf hunderten Servern verwendet.

Nein, "das Ras neu erfinden" tut man damit nicht. PHP stellt ja extra Ansatzpunkte zur Verfügung, damit man eigene Speicher-, Wiederherstell- und Aufräumfunktionen für Sessions benutzen kann, um beispielsweise in eine Datenbank zu speichern. Was dabei in jedem Fall bleibt, ist die Art und Weise, wie PHP die Session-ID auswürfelt, an den Client übermittelt und von diesem wieder empfängt.

Es werden also exakt die "normalen" PHP-Sessions verwendet - nur die Sicherung der Session-Daten wird für den Einzelfall angepaßt.

- Sven Rautenberg