Sessions in Datenbank -> bootstrap best-practices? Ideen?

[TorbenS]

Hallo!

ich möchte gerne die Sessions über eine Datenbank abwickeln ("session-set-save-handler" etc...).... dazu muss ich natürlich die session handler recht früh (vor dem @session_start() in der systems/initialize.php) belegen, damit das auch funzt... da hab ich allerdings bislang noch keinen hook entdeckt....

scheue mich nicht unbedingt, da noch einen require(meinmysqlsessionhandlercode.php) vorzusetzen, finde das aber nicht besonders hübsch, und update-sage ist's allemal nicht...

hat jemand einen tip?

Gruss!

Torben

[aw029]

Die Frage ist ja auch warum du das machen möchtest? Ausserdem verwendet TL glaub ich wrapper-Klassen für das Sessionhandling. D.h. du müsstest dann eher dort ansetzen. Ordner system/library/Session.php

Gruß
Alexander

[TorbenS]

Hi Alexander,

vielen Dank für Deine Antwort!

Es gibt da tatsächlich ein paar Gründe, warum man auf die Idee kommen kann, soetwas zu machen...
Aktuell ist's der, mehrere auf IP-Ebene loadgebalancte Knoten (IPVSADM) auf einen Session-Nenner zu bringen.

Die Idee mit der Session-Klasse ist eigentlich ganz gut, der code darin sieht auch irgendwie zunächst so aus, als könnte man da 'was machen....
Aber die Klasse Session aus system/libraries/Session.php ist irgendwie zwar schon ein wrapper, da hast Du recht, jedoch leider nur in Richtung Applikation, da sie für die Persistenz intern einfach auf das von PHP bereitgestellte $_SESSION-Array zurückgreift, also keine eigene Persistenz liefert bzw. keine "wrappt".
Sicherlich könnte man die Session.php austauschen mit etwas eigenem...

jedoch wird die tatsächliche Sitzung PHP-seitig bereits in Zeile 66 in der system/initialize.php gestartet, was noch vor dem laden jedwelcher Konfigurationen passiert, auch bevor die o.g. Sessions-Klasse geladen geschweige denn initialisiert ist... sodass hier immer das PHP-interne Session-Handling zum Tragen kommt, zumnindest was das generieren der Session ID etc angeht.

Wenn man nun jedoch irgendwo vor der ominösen Zeile 66 das PHP-Sessionhandling (oder viel mehr die Session-Persistenzschicht) auf die Datenbank umbiegen könnte (mittels session_set_save_handler und entsprechender Klasse / Funktionen), und zwar auf eine Art, die halbwegs upgrade-safe wäre, könnte man sich Applikationsseitig weiterhin auf die bestehende Sessions-Klasse verlassen und die ganze Kiste würde sehr schön und Modular skalieren (zumindest was diese Session-Skalierung angeht...)
Dafür suche ich gerade einen schönen Hook...

Any ideas?

Torben

[FloB]

Kannst du einen Handler nicht in der PHP.ini festlegen?

[TorbenS]

Hi FloB,

das wäre die optimale Lösung, dafür benötigt man jedoch ein seperates PHP-Modul, von der Art, wie das auch schon mal gebaut wurde:
hier: http://websupport.sk/~stanojr/projects/session_mysql/
oder infos hier: http://www.teamarbyte.de/mysql-session-handler.html

Da scheint der Entwicklungsstand allerdings recht veraltet. Das wäre aber tatsächlich die sauberste Lösung. Ein fertiges Debian paket hab ich nicht gefunden, leider (

Deswegen werde ich mal gucken, ob ich das Ding kompiliert bekomme.

Eine PHP-Klasse oder soetwas in der php.ini für diesen Zweck zu spezifizieren scheint nicht zu funktionieren...

Vielen Dank & liebe Grüsse,

Torben

[aw029]

Hi Torben,

habe noch etwas gefunden was dir vielleicht hilft:

http://www.mywebsolution.de/workshops/1/page_5/show_Sessions-in-PHP.html#up

Zwar musst du auch hier dann die initialize.php verändern und wärst damit nicht mehr update sicher, ich denke aber, da es sich dann "nur" um zwei Zeilen in der init-Datei handelt und letztendlich nur der Administrator updates macht, ist es ein 30 Sekunden-Job die zwei Zeilen wieder reinzumachen wenn die init-Datei mal durch ein Update ausgetauscht wird.

Gruß
Alexander

[TorbenS]

Hi Alexander,

danke für den Link. Der PHP Code, der für die MySQL-Sessionpersistenz benötigt ist, ist mir klar und ist ja zum Glück vielfach dokumentiert, sodass man das Rad an der Stelle nicht neu erfinden muss.

Meine Frage, oder vielmehr mein Wunsch, ist aber tatsächlich wie du befürchtest: wie bekomme ich meinen PHP-Sessionhandler-Code (der schon funktionsfähig und fertig ist und den ich derzeit einfach recht Holzhammer-mässig per include in die initialize.php 'reinschiesse) auf eine saubere, upgrade-sichere weise in TYPOlight untergebracht.

Einfach aus Sauberkeitsgefühl, weil's langfristig besser ist, für die Wartbarkeit, Codebasis, etc etc.. Das ist insbesondere hinsichtlich meines Kernanliegens, eine quasi endlos skalierbare Anzahl Knoten hinter das Loadbalancing hängen können zu wollen... äh... zu können wollen... äh.. naja, Du weisst schon...

Wäre halt cool, wenn's irgendeine Möglichkeit ähnlich der system/config/initconfig.php gäbe, nur vor der verflixten "@session_start();" anweisung in der initialize.php..

Ich hab aber im code auch nirgends 'was gefunden.

Ich glaube, ich mach mal ein Feature-Request...

Vielen Dank für das Mit-Brainstorming!

Torben

[lindesbs]

Schau Dir mal dies hier an : http://https://contao.org/issues/868

evt. ist die initconfig.php etwas fuer dich.

[TorbenS]

Hi,

Danke für den Tip. In etwa soetwas wie die initconfig.php hätte würde ich am liebsten verwenden, jedoch setzt das wie gesagt zu spät ein. Zum Zeitpunkt, wo die initconfig.php geladen wird (initialize.php, ca Zeile 150) wurde die Session schon gestartet (initialize.php, ca. Zeile 66).

Ich hatte vorhin schonmal n Feature-Request aufgemacht, mal gucken, was da kommt:

http://https://contao.org/issues/1882

Liebe Grüsse,

Torben

[FloB]

Ich fände es nicht schlecht, wenn die initconfig.php weiter "nach oben" verschoben wird – es gibt ja noch ein Ticket für einen Hook, der etwa bei der aktuellen Position der initconfig.php starten soll, somit hätten wir hier zwei Möglichkeiten zum Einhaken, die IMO nicht benötigt werden (wer den späteren Zeitpunkt nutzen möchte, kann den Hook verwenden, für den früheren gibt es die initconfig.php).

[andreas.schempp]

Ich dachte das Session Handling sei Aufgabe von PHP, wieso hat das etwas mit TYPOlight zu tun?
In deinem Loadbalancing-Server willst du ja wohl alle PHP-Applikationen "balancen", und nicht nur TYPOlight...?

[TorbenS]

Hi Andreas,

jo, find ich auch, dass man die Thematik lieber eine Schicht höher schieben sollte, was durch ein phpseitiges Session-Modul wie z.B. dieses hier (http://websupport.sk/~stanojr/projects/session_mysql/) zu machen wäre. Ich bekomme diese Gurke aktuell aber nicht gebuildet (mit PHP 5.2.12 mit Suhosin...).

Im konkreten Fall ist's tatsächlich "nur" TL, das auf den Nodes als Applikation läuft... aber ja, es werden quasi alle Applikationen gebalanced, da das Balancing auf IP-Ebene läuft, per IPVSADM etc., nicht auf Protokollschicht (also nicht HTTP wie z.B. mit pound oder so).

Wieso das Session-Handling etwas mit TYPOlight zu tun hat, musst Du jemanden Fragen, der das entwickelt hat
Konservativ betrachtet greift TL recht tief in's Sessionhandling ein (siehe die "ini_set"s bzgl. session.* an verschiedenen stellen im code, oder die Session-Klasse). Ich finde das aber überhaupt nicht schlimm, ist ja einer der Vorzüge von PHP, dass man derartiges machen kann..

TL mischt sich tatsächlich nicht in die Persistenzschicht des Sessionhandlings ein. Das würde ich aber gerne tun, damit ich die Möglichkeiten, die PHP mir bietet, mich in diese Ebene einzumischen, voll ausnutzen kann.

Und das würde ich am liebsten nachhaltig/Upgrade-Safe machen, hatte mich (und Euch) also gefragt, ob schonmal jemand ähnliches gemacht hat oder einen Hook/configfile kennt, in den ich meinen Code hängen kann.

Aktuell hab ich das einfach dazwischengedengelt, um das mal abschätzend zu formulieren. Ist alles zwar schön sauber und gekapselt und nach zumindest ein paar Regeln der Kunst gebaut (was mich zum Thema Unittestes des core-codes bringt, aber das ist nun wirklich eine ganz andere Baustelle) und läuft echt gut. Werde den code mal hier irgendwie einbringen, wenn das ding produktiv geht bzw. die letzten kanten rundgeschliffen sind.

Liebe Grüsse,

Torben

[andreas.schempp]

Ich habe mich nicht eingehende mit dem Thema beschäftigt, aber müsstest du die PHP-INI-Konfiguration nicht in der htaccess oder vhost-Konfiguration machen?

TYPOlight greift aus meiner Sicht überhaupt nicht ins Session-Handling ein, es macht nur folgendes:
- Deaktivieren von URL-Sessions (also nur Cookie erlauben)
- Die Session-Klasse ist zum Lesen und Schreiben von Session-Werten
- Es wird in TL ein normales session_start() gemacht...

[TorbenS]

Hi Andreas,

Meine Sicht - oder sagen wir mal lieber Interpretation - unterscheidet sich da etwas... ist aber glaube ich nicht schlimm, und ist vor allem fast esoterisch oder philosophisch:

Per Konvention greift TYPOlight schon in das Session Handling ein, da es "vorschlägt", den in der Session.php bereitgestellten Session-Singleton statt der $_SESSION für's Lesen und Schreiben von Sessionwerten zu nutzen.
Das finde ich i.d.R. prima, soetwas zu Kapseln, hätte nur gehofft, dass wenn schon eine Zwischenschicht eingezogen wird, hier auch eine Möglichkeit existiert, die Persistenzschicht zu steuern. Selbst wenn man nun die Session-Klasse durch eine eigene ersetzt (komponiert, erweitert, wie auch immer man das machen will), würde das aber fehlschlagen, da, wie Du schon sagst, TL, und zwar ausserhalb der Session-Klasse (initialize.php, Zeile 66), die Session-Persistenzschicht durch ein "normales" session_start() initialisiert..

Ist alles ja nicht schlimm, und das gute ist, dass wir ja die Möglichkeit haben, das alles gemeinsam so zu ändern, wie wir wollen!

Liebe Grüsse,

Torben

[andreas.schempp]

Die Session-Klasse liest und speichert aus dem $_SESSION array. Der einzige Unterschied: Fürs Frontend wird $_SESSION['FE_DATA'] benutzt, fürs Backend $_SESSION['BE_DATA']. Diese "Unterschlüssel" werden in der Member/User-Tabelle (im FE falls einer angemeldet ist) gespeichert und bei der nächsten Anmeldung wieder geladen, sodass sie auch über die PHP-Sessions hinweg vorhanden bleiben.

Das hat aber überhaupt keinen Einfluss auf die PHP-Session...