[Chr!s]

Tag,
nun, ich bin gerade am Schreiben eines eigenen SessionHandlers für mein Projekt. Ziel ist es, die SessionDaten über eine Datenbank zu verwalten.
Dabei bin ich auf folgenden Hinweis gestoßen:

Write and Close handlers are called after destructing objects since PHP 5.0.5. Thus destructors can use sessions but session handler can't use objects. In prior versions, they were called in the opposite order. It is possible to call session_write_close() from the destructor to solve this chicken and egg problem.

Nun, damit das nicht alles seperat gemacht wird, steht dsa hier zu Verfügung:

PHP-Code:

<?php
register_shutdown_function('session_write_close');
?>

Nur steht da jetzt ja, dass ich keine Objekte mehr zu Verfügung habe, also auch nicht mein Model Objekt, geschweige denn mein Konfigurationsobjekt. Nun fehlt mir irgendein Ansatz, wie ich die Sessions dann dennoch in die Datenbank befördern könnte (-> write).

Mit reinen mysql_* Befehlen? Das wäre allerdings auch nicht ohneweiteres Möglich, denn das Konfigurationsobjekt besteht dann nicht mehr. Einzige Möglichkeit wär dann z.B. die MysqlDaten in Konstanten zu speichern, was allerdings wohl nicht sehr elegant wäre..

Jemand eine Idee?

[niklasboelter]

session_write_close() als letzte script zeile aufrufen?
und vll statt exit; eine benutzerdefinierte funktion zum beenden des programms benutzen:

PHP-Code:

function shutdown($msg)
{
    session_write_close();
    exit($msg);
} 


edit: hab mal auf php.net geguckt und register_shutdown_function() wird auch _VOR_ den dtoren aufgerufen. also kein problem mit objekten

[Chr!s]

Ist das eine Antwort auf mein Problem? Mir gings doch drum, dass PHP Objekte zerstört und dann erst die Session Write & Close Funktionen aufruft, was vor php 5.0.5 nicht so war..

[Ben]

Du könntest ein auto_append_file angeben, allerdings erfordert das ja Zugriff auf die php.ini afaik.

[Chr!s]

allerdings erfordert das ja Zugriff auf die php.ini afaik.

Auf die werden allerdings nicht alle meiner Kunden Zugriff haben, mit Sicherheit, von daher fällt das leider weg. =/

[MrNiceGuy]

In dem Text steht doch, dass du die Destruktoren der Klasse dazu verwenden sollst, um session_write_close() auszuführen:

PHP-Code:

class cSessionHandler
{
  // ...

  function __destruct ()
  {
    session_write_close();
  }
} 


Oder habe ICH da jetzt was falsch verstanden?

[Chr!s]

Zitat von MrNiceGuy

In dem Text steht doch, dass du die Destruktoren der Klasse dazu verwenden sollst, um session_write_close() auszuführen:

PHP-Code:

class cSessionHandler
{
  // ...

  function __destruct ()
  {
    session_write_close();
  }
} 


Oder habe ICH da jetzt was falsch verstanden?

Ich hab oben vergessen anzugeben, dass auch eine gewisse PHP4 Kompatibilität existieren soll, somit fällt das __destruct() leider irgendwie weg.

Ich denke dass ich hier irgendwas missverstehe, bitte klärt mich einer mal auf, benutzt ihr keine Session-Klassen?

[Ben]

Auf jeden Fall mal keine, die PHP4-kompatibel sind, weil Klasse und PHP4-kompatibel für mich nicht machbar wäre, aber das ist ein anderes Thema.

[niklasboelter]

Zitat von Chr!s

Ist das eine Antwort auf mein Problem? Mir gings doch drum, dass PHP Objekte zerstört und dann erst die Session Write & Close Funktionen aufruft, was vor php 5.0.5 nicht so war..

Eben deshalb sollst du sie ja selsbt vorher aufrufen. Oder was willst du sonst machen?

[MrNiceGuy]

Ähm, meines Wissens nach ist es nicht machbar, eien Klasse sowohl für PHP4, als auch für PHP5 zu schreiben, da alleine schon die Definition der Variablen komplett anders ist seit PHP5. Demnach musst du so oder so 2 Versionen der Klasse erstellen, da kannst du dann den __destruct() bei der PHP4-Version weglassen, da er a) nicht funktioniert und b) auch garnicht benötigt wird und in der PHP5-Version lässt du einfach den __destruct() drin, damit es auf jedenfall in jeder PHP5-Variante funktioniert!? Notfalls noch ne Versionsunterscheidung in den __destruct () eintragen.

[Ben]

Er mein mit PHP4-kompatibel glaub ich, dass er PHP5 einfach gar nicht nutzt ..

[Chr!s]

Zitat von Ben

Er mein mit PHP4-kompatibel glaub ich, dass er PHP5 einfach gar nicht nutzt ..

Aufgrund der Zielgruppe die ich habe, muss ich leider auf PHP4 zurückgreifen. PHP5 Möglichkeiten werde ich hier nicht verwenden. Ziemlich ärgerlich, ich muss mich damit immer wieder rumschlagen, aber naja was solls.. Ich erwarte PHP6 in der Hoffnung, dass alle Hoster wenigstens auf PHP5 updaten

Das mit der PHPVersions Unterscheidung ist allerdings eine sehr gute Idee, das könnte ich innerhalb der Klasse einbauen, danke für den Tip!

[Lars]

Hallo? PHP4-Kompatibilität und trotzdem die PHP5-Sessionfunktionen benutzen? Ich ralls grade nicht, Chris

[Chr!s]

Zitat von Lars

Hallo? PHP4-Kompatibilität und trotzdem die PHP5-Sessionfunktionen benutzen? Ich ralls grade nicht, Chris

Ich brauch einfach eine Klasse für Sessions, die unter PHP4 läuft. Dabei hat sich unter PHP 5.0.5 was geändert, was genau hab ich auf der ersten Seite geschrieben, und dadurch ergibt sich mein Problem.

[Lars]

Bau ein Singleton in deine Klasse und übergib dann der Sessionfunktion einen Klasse-Callback, also so:

PHP-Code:

set_*_function(array('MyClass', 'myMethod'));
set_*_function(array($object, 'myMethod')); 


[MrNiceGuy]

Zitat von Ben

Er mein mit PHP4-kompatibel glaub ich, dass er PHP5 einfach gar nicht nutzt ..

Sollte das wirklich der Realität entsprechen, stellt sich mir die Frage, warum die Änderung in PHP 5.0.5 dann eine Relevanz haben sollte...

[Ben]

Ja so wirklich verstanden hat das hier glaub ich keiner, oder?

[Chr!s]

Nagut, hab mich wohl ein bisschen unverständlich ausgedrückt.
Dann hab ich mal eine andere Frage - hat jemand von euch ein Beispiel für mich (PHP5 > 5.0.5) mit einem funktionierenden, eigenen SessionHandler? Soll nichts großes sein, nur grob..

[dsxs]

PHP-Code:

<?php 
/**
 * TZ 2
 *
 * Type:     function dump
 * Name:    session_handler
 * Date:     November 6, 2005
 * Purpose: change the default php session handler to use mySQL DB as storage place
 * @version  1.0.1
 *
 * Change Log:
 *         - 1.0     initial release
 *        - 1.0.1    
 *                + using global $dbh_core handler, instead of creating class instance
 *          + bugfix in session timeout
**/


// iitialize db_handler

// open sessions
function sess_open($aSavaPath, $aSessionName) {
    global $dbh_core;
    
    return TRUE;
}

// close sessions
function sess_close() {

    /*global $dbh_core;
    
    $aVal = addslashes($aVal);
    $dbh_core->query("UPDATE sessions SET data = '$aVal', lastaccess = NOW() WHERE sid = '$aKey'",$dbh_core->db_link);*/
    return TRUE;
}

// read data from session, parse to array
function sess_read($aKey) {
    global $dbh_core;
    $dbh_core->query("SELECT data FROM sessions WHERE sid='$aKey'",$dbh_core->db_link);

    if($dbh_core->num_rows() == 1) {
        $r = $dbh_core->fetch();
        return $r['data'];
    } else {
        $dbh_core->query("INSERT INTO sessions (sid,  lastaccess, host,data) VALUES ('$aKey',  NOW(), '".gethostbyaddr($_SERVER['REMOTE_ADDR'])."','')",$dbh_core->db_link);
        return "";
    }
}

// write data to session
function sess_write($aKey, $aVal) {
    global $dbh_core;
    
    $aVal = addslashes($aVal);
    $dbh_core->query("UPDATE sessions SET data = '$aVal', lastaccess = NOW()&nbs