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

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

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

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

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

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 :o(

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

Hi Torben,

habe noch etwas gefunden was dir vielleicht hilft:
http://www.mywebsolution.de/workshop...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

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

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

evt. ist die initconfig.php etwas fuer dich.

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

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).

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...?

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

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...

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

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...

Hallo Andreas,

ich glaube, wir beide sagen eigentlich das selbe: die Session-Klasse tut eigentlich nix, ausser den Zugriff auf die $_SESSION zu kapseln, und wie Du richtig sagst, unter Berücksichtigung der FE/BE keys.

Und leider, wie Du richtig sagst, hat diese Klasse keinen tatsächlichen Einfluss auf das tatsächliche Session-Handling - das heisst, zumindest nicht auf die Persistenz der Sessiondaten.

Durch ihre bloße Existenz gibt diese Klasse jedoch für uns Entwickler die Konvention vor, diese Klasse für Zugriffe auf die Sitzungsdaten zu verwenden.

Ich hatte gehofft, dass dieses Session-Klasse ggf. statt direkt auf die $_SESSION globale zuzugreifen dies vielleicht über eine Interface-Implementierung tut, welche man für seinen eigenen Zweck (Persistenz über Datenbank) verwenden könnte.

Ist aber nicht, und so muss man nun die PHP-native Methode zum Einziehen einer eigenen Persistenzschicht verwenden (session_set_save_handler), was, wenn man das machen möchte, vor dem Aufruf der Funktion session_start geschehen muss.

Um dies zu tun, war ich auf der Suche nach einem geeigneten Hook oder config-file include, der vor dem session_start-Aufruf ausgeführt wird, in welchem ich meinen session_set_save_handler einfügen kann, statt im core code rumzufuhrwerken.

Habe aber keinen gefunden. Und deswegen bin ich hier. Und mein Lösungsvorschlag ist im Feature-Request Ticket (und im laufenden code auf'm Server). :o)

Macht das Sinn, was ich schreibe? Für mich ja... hoffe, es ist mir gelungen, das halbwegs verständlich zusammenzufassen.

Liebe Grüsse und sorry, wenn's etwas wirr war,

Torben

Ich denke, dass wir die inticonfig.php dort einbinden können, wo die Systemstandards festgelegt werden. Das wäre dann ca. Zeile 62 der intialize.php (direkt vor session_start()). Hier ständen Standardfunktionen (wie Error Handling) und Konstanten zur Verfügung, aber es wäre noch nicht wirklich etwas "passiert". Einen früheren Zeitpunkt halte ich für nicht sinnvoll (Funkionen und Konstanten kann man nicht überschreiben, jedoch die Handler-Einstellungen, wenn jemand z. B. die Fehlerbehandlung ändern möchte), ein späterer, in Hinsicht auf die Problematik in diesem Thread, auch nicht.

Anstelle der aktuellen Position der initconfig.php könnte ein Hook ähnlich dem Vorschlag von Xtra eingesetzt werden. Oder man verzichtet ganz auf diese Einstiegsmöglichkeit, denn in den config.php wäre ja theoretisch eine Eingriffsmöglichkeit gegeben – jedoch, wie Xtra schon sagte, im Scope der Config-Klasse.

Was meint ihr?

Zitat:

---

Zitat von FloB

[...] denn in den config.php wäre ja theoretisch eine Eingriffsmöglichkeit gegeben – jedoch, wie Xtra schon sagte, im Scope der Config-Klasse.
Was meint ihr?

---

Und genau da sehe ich eben wieder das Problem mit dem Singleton Stack.
Man darf aus dieser Position keine DB Abfragen fahren, nicht das User object abfragen usw. da ansonsten der Singleton stack durcheinander kommt.
Einen expliziten HOOK hierzu einzufyhren waere IMO das richtige. Siehe Ticket.

Wie steht es nun eigentlich mit den diversen Tickets zu diesem Thema (speziell #1650) aus? Das Umschalten des Backend-Theme im Benutzerprofil wird ja sowieso umgesetzt, daher geht es vor allem um die Frage aus #1882 bezüglich der Position der Einbindung der initconfig.php. Außerdem waren zusätzliche Hooks - leider ohne Code-Beispiel - im Gespräch und alternativ die Einführung eines init.d-Ordners. Was davon macht Sinn und wird tatsächlich benötigt? Oder kann ich diese Tickets schließen?

Also das verschieben der initconfig.php nach oben ist prinzipiell moeglich, beraubt dann jedoch alle Extensions der Moeglichkeit, die Klassen Environment, Config oder Input zu verwenden.
Ich denke hierzu(#1882) sollte man lieber eine neue Datei bootconfig nehmen.
Ich stimme dir jedoch generell zu, dass das Session handling auf Serverebene abgehandelt werden sollte und nicht im application level und somit diese bootconfig auf "wackeligen Fuessen" steht.

In Ticket #1650 ging es jedoch konkret um das Problem, dass wir die config Dateien nicht verwenden koennen, da diese aus dem Scope von Config heraus aufgerufen werden. Zu diesem Zeitpunkt ist jedoch Environment noch nicht vorhanden und obendrein auch die Input Klasse nicht.
Wenn nun ein Programmierer aus einer config.php heraus Environment oder die Datenbank instantiert (via getInstance()), so kommt der PHP stack mit den singletons durcheinander und erzeugt unschoene Exceptions welche in Datei "" auf Zeile 0 aufgetreten seien (leo.unglaub und ich haben etliche Stunden damit verbracht dies herauszufinden).

dies bringt mich nun zum naechsten Thema, der conf.d Ordner.
Wenn wir dies nun mal von Anfang an durchgehen und annehmen, wir haben einen system/config/conf.d Ordner, so stellt sich hier die Frage, wie sollen sich die Extensions dort eintragen.
Ebenfalls alphabethisch?
Dann haben wir wieder dasselbe Problem wie bei den Extensions an sich, dass wir mit endlosen zzz_blafasel.php zu tun haben werden.
Selbiges gilt auch, wenn wir pro extension neben den "normalen" config Ordnern noch einen conf.d Ordner erlauben, in welchen zusaetzliche Dateien abgelegt werden.
Bei dieser Herangehensweise denke ich an gleichlautende Namen, wie z.B. initconfig.php oder die generelle config.php.
Diese Dateien muessten dann direkt vor der jeweiligen Benutzerdefinierten-Konfiguration geladen werden.
Mockup-Code Bsp. fyr conf.d/initconfig.php:

Code:

---

/**
 * Include the module initialization files for init tasks.
 */
foreach (Config->getInstance()->getActiveModules() as $strModule)
{
        $strFile = sprintf('%s/system/modules/%s/conf.d/initconfig.php', TL_ROOT, $strModule);
        @include($strFile);
}
/**
 * Include the custom initialization file for additional init tasks.
 */
include('system/config/initconfig.php');

---

Sinn macht diese herangehensweise bislang jedoch meiner Meinung nach nur bei initconfig (lasse mich da aber gerne yberstimmen, mir faellt nur gerade kein konkretes Beispiel ein wo man andere yberschreiben wollen wyrde).

Nachteil dieser Methode ist jedoch, dass wir nochmalig durch alle aktiven extension folder gehen myssen, egal ob darin nun eine conf.d enthalten ist oder nicht.
Sollten wir obendrein noch eine bootconfig.php einfyhren wollen, so haben wir obendrein das Problem, dass zu diesem Zeitpunkt nicht bestimmt werden kann, ob eine Extension aktiv ist oder nicht (activeModules ist erst spaeter verfygbar wenn Config auch instantiiert ist, dies steht jedoch der bootconfig im Gegensatz, da selbige "vor allem" kommen soll).
Dies fyhrt dann dazu, dass wir optimistisch alle boot configs einlesen myssen.

Meine Gedanken zu diesem Thema, Diskussion willkommen.

Gruss
Chris

Hallo Allerseits,

ich bin auch nach wie vor der Meinung, dass es besser ist, wenn möglich das Session-Handling nicht in der Anwendung abzufrühstücken. Ist jedoch nicht in allen Systemen / Hostingumgebungen möglich.

Ich kann alle Einwände von xtra zu allen themen gut nachvollziehen, insbesondere das zzz_blafasel.php-Thema und die nicht besonders sparsame herangehensweise, nochmals durch alle Module zu loopen, etc.

Für mein konkretes Problem (die Sache mit den Sessions in der Datenbank) behelfe ich mir aktuell mit einem händischen reingeschebbel von

PHP-Code:

---

if(file_exists(TL_ROOT . '/system/localinit.php'))
{
    include_once(TL_ROOT . '/system/localinit.php');
} 


---

so wie ich das im Ticket als einen möglichen Weg vorgeschlagen hatte, und das funktioniert ganz gut.
Wobei ich sagen muss, dass ich den Namen "bootconfig.php" besser finde, aber das ist nur Kosmetik.

Zur Frage von Leo, ob das Ticket #1882 geschlossen werden kann: tja, weiss auch nicht. Wenn's sonst niemand ausser mir braucht/will, dann kann ich kaum mit gutem Gewissen auf "aufbleiben" plädieren und werde mir erstmal mit meinem reingehacke weiterbehelfen.

So'n Ticket lässt sich ja zur Not auch wieder öffnen, sollte irgendwann mal mehr Bedarf entstehen. ;)

Vielen Dank euch allen für alle Beiträge zu diesem Thema!

Torben

Meiner Meinung nach gibt es schon sehr viele "globale" Config Files, so dass man leicht die Übersicht verliert. Wie außerdem hier schon angemerkt wurde sind die für installationsabhängige Einstellungen ziemlich gut, aber wenn man von einer Erweiterung heraus etwas machen möchte sehr "Quer-Feld-Ein"-mäßig.

Ich finde die schönste Lösung für Erweiterungen ist es, alles über verschiedene Config Files innerhalb des config-Ordners abzuhandeln. Um den Performance-Problem entgegen zu wirken, könnte man eine Art "Compiler" schreiben, der dann von allen "aktiven" Modulen alle Konfigurationen in 2-3 Bootstrap-Skripte schreibt, die an den entsprechenden Stellen ausgeführt werden. Dieser Compiler müsste dann lediglich im Installtool, beim Installieren über das Repo und beim (de)aktivieren von Modulen automatisch ausgeführt werden. Beim manuellen Installieren von Erweiterungen könnte es in der Systemwartung eine "regenerate"-Funktion geben und für Entwickler eine "regenerate per request"-Option.

Dieser Compiler ist ja im Endeffekt das, was ich in change-6984 fyr Version 3 gemeint habe.
Momentan steht eine Umstellung auf dieses System jedoch, meiner Meinung nach, nicht zur Debatte, da es einschneidende Veraenderungen sind, die wir in diesem merge window (Angepeiltes Release 2.9 ist der 4. Juli) defintiv nicht mehr sauber unterbringen koennen und obendrein die Betaphase bereits begonnen hat. :)

Eine ad-hoc Loesung per bootconfig a.ae. waere jedoch mit marginaler Gefahr verbunden dass das System ungewynschte Nebeneffekte mit sich bringt (solange keiner in diesen files Schindluder treibt).
Einfach weil es ryckwaertskompatibel ist.
Die Frage die sich nun stellt ist, jedoch, bauen wir das nun ein und schmeissen es mit Version 3 wieder raus, wo sich sowieso etliches aendern wird, oder nicht.