Sven Rautenberg: Eigenes Session-Handling : lohnt sich eigene Routine?

Beitrag lesen

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

--
"Beim Stuff für's Web gibts kein Material, was sonst das Zeugs ist, aus dem die Sachen sind."
(fastix®, 13. Oktober 2003, 02:26 Uhr -> </archiv/2003/10/60137/#m338340>)