23. PHP4: Sessions

23.1. Wie realisiere ich Sessions mit PHP4?
23.2. Was ist eine Session-ID? Was ist PHPSESSID?
23.3. Wie stelle ich fest, ob der Client die Cookie-Annahme verweigert?
23.4. Wie übergebe ich Session-IDs ohne Cookies an eine andere Seite? Was ist Fallback?
23.5. Warning: Cannot send session cookie - headers already sent...
23.6. Wie kann ich den Namen der Session ändern, ohne in die php.ini einzugreifen?
23.7. Wie schütze ich Sessiondaten zusätzlich?
23.8. Wie groß darf die Menge an Daten sein, die ich in einer Session speichern darf?
23.9. Wie kann ich mir den Inhalt der Sessiondaten anzeigen lassen?
23.10. Wie kann ich mir den Inhalt der Cookiedaten anzeigen lassen?
23.11. Sessiondaten werden nach session_destroy() nicht gelöscht. Wie kann ich sie trotzdem löschen?
23.12. Was geschieht im Filesystem des Servers, wenn ich Sessions benutze?
23.13. Wie benutze ich die Session-Funktionen unter Windows?

23.1. Wie realisiere ich Sessions mit PHP4?

|PHP4|Session|Sessionverwaltung|Howto|Grundlagen|Information|Anwendung|

Antwort von Daniel T. Gorski

Sessiondaten sind Daten, die z.B. von einem PHP-Script auf dem Server gespeichert werden, und die meistens für die Dauer des Besuchs (Session/Sitzung) auf mehreren Pages einer Website ihre Gültigkeit behalten. Sessiondaten können z.B. dazu benutzt werden, um dem Besucher restriktiven Zugriff (z.B. nach einem Login) auf Teile einer Website zu erlauben - üblicherweise zu einem Administrationsbereich.

In der PHP4-Standardeinstellung werden diese Daten als ASCII- Dateien im /tmp-Verzeichnis (session.save_path) des Servers gespeichert. Diese Dateien enthalten das serialsierte (serialize()) Abbild der von einem Script gespeicherten Variablen. Der Name dieser Dateien setzt sich aus dem Prefix sess_ und einer 32-Zeichen langen, zufällig ausgewählten Zeichenkette (der Session-ID) zusammen.

Die Manipulation dieser Daten bleibt nur dem serverseitig ausgeführtem PHP-Script vorbehalten - der Client (Browser) weiß nicht welche Daten von dem Script gespeichert werden und er kann keinen mittelbaren Einfluß auf diese Daten nehmen. Ausnahme bildet hier die Änderung/Löschung dieser Daten durch den Administrator oder durch ein Script mit entsprechenden Rechten (siehe auch Wie schütze ich Sessiondaten zusätzlich?).

Unter diesen Voraussetzungen gelten die Sessiondaten bei einem korrekt installierten Webserver, als sicher und durch den Besucher nicht fakebar.

PHP4 stellt mehrere Funktionen zu Sessionverwaltung zu Verfügung (siehe auch die Sessionsreferenz, die grundlegenden seien hier kurz vorgestellt:

Bei Verwendung dieser Funktionen ist zu beachten, dass eine neue Session nur dann angelegt werden kann, wenn noch keine Ausgabe stattgefunden hat. Mehr Informationen dazu finden sich im Artikel Warning: Cannot send session cookie - headers already sent....

session_start()

Session(datei) auf dem Server erstellen. Wurde eine gültige Session-ID übergeben, werden die in den Sessiondaten gespeicherten Werte in dem $HTTP_SESSION_VARS-Hash wiederhergestellt und abhängig von der Einstellung der register_globals auch als Variablen reinitialisiert.

Zusätzlich werden, je nach Einstellung des session.gc_probability -Parameters, in diesem Augenblick die angehäuften und nicht mehr benötigten Sessiondateien vom Server gelöscht. Wenn das error_reporting() schärfer eingestellt ist, gibt session_start() eine entsprechende Notice aus. Da diese üblicherweise nicht erwünscht ist, empfiehlt es sich vor die session_start()-Funktion ein "@" zu schreiben, welches diese Warnung unterdrückt.

Also:


<?php
    @session_start();
?>

session_register()

Eine oder mehrere Variablen zur Speicherung in die Session(datei) vormerken. session_register() impliziert ein session_start(). Das bedeutet, daß man session_start() in diesem Fall auch weglassen könnte. Bei den Parametern der session_register() Funktion handelt es sich nicht um die Variablen selbst, sondern um ihre Namen. Diese Parameter besitzen kein führendes "$".

session_register() merkt eine Variable vor (registriert sie), die dann am Ende des Scriptes in die Session(datei) geschrieben wird, und die zwischen dem Registrieren und dem Scriptende verschiedene Werte haben kann. Es wird jeweils der letzte Wert dieser Variablen in den Sessiondaten gespeichert. D.h. Die Werte der registrierten Variablen sind frühestens, nach der Beendigung des aktuellen Scriptes und beim nächsten session_start() wieder verfügbar.

session_unregister()

Eine oder mehrere Variablen aus der Session(datei) verwerfen. Dem session_unregister() muß ein session_start() oder session_register() vorangehen.

session_destroy()

Die Funktion session_destroy() veranlasst alle Variablen einer Session zu verwerfen und die Session(datei) löschen.

Ein genauerer Einblick in die Funktionsweise dieser Funktionen wird hier gewährt: Was geschieht im Filesystem des Servers, wenn ich Sessions benutze?.

Beispiel 1

Beispiel 1: seite1.php


<?php
    // Falls nicht vorhanden, generiert eine Session(datei)
    // auf dem Server.
    // Falls bereits vorhanden, liest Sessiondaten wieder ein und
    // (re-)initialisiert die gespeicherten Variablen.
	
    @session_start();
	
    // Erst wenn das Script terminiert(!), merkt PHP den Inhalt
    // der Variablen $s_userName und $s_userPermissions in
    // den Sessiondaten.
	
    session_register("s_userName","s_userPermissions");
	
    $s_userName         =   "dtg";
    $s_userPermissions  =   "keine :=(";
?>

Beispiel 1: seite2.php


<?php
    // Falls nicht vorhanden, generiert eine Session(datei)
    // auf dem Server.
    // Falls bereits vorhanden, liest Sessiondaten wieder ein und
    // (re-)initialisiert die gespeicherten Variablen.
	
    @session_start();
	
    // Gibt den Inhalt der wiederhergestellten Variablen aus.
    echo "<P>Hallo ".$s_userName.",";
    echo "<P>Du hast ".$s_userPermissions." Zugriffsrechte.";
	
    // Wird in diesem Script kein session_unregister() oder
    // session_destroy() ausgeführt, bleiben die Daten erhalten!
?>

Damit das Folgescript (seite2.php) weiß, in welcher Datei auf dem Server die benötigten Daten zu finden sind, muß ihm die sog. Session-ID übergeben werden. Diese Session-ID repräsentiert den eindeutigen Namen der Session (es ist der bereits erwähnte 32-Zeichen lange String).

Um die Session-ID an eine andere Seite zu übergeben, benutzt PHP4 in der Standardeinstellung Session-Cookies, welche nicht gespeichert werden und mit dem Schließen des Browsers verfallen. In diesen Cookies wird der Name der Session (z.B. PHPSESSID) und die zugehörige Session-ID abgelegt. Bei einem Request auf ein Folgescript wird der Cookieinhalt mitgeschickt, und PHP weiß damit in welcher Sessiondatei die benötigten Daten gespeichert sind.

Dies passiert automatisch, ohne daß zusätzlicher Code geschrieben werden muß. Ist man auf PHP3 angewiesen, kann die PHPLIB ohne erhöhten Aufwand diesen Mechaninsmus abbilden. Diese FAQ enthält ein spezielles Kapitel über die PHPLIB.

Sind die php.ini-Parameter track_vars=On und register_globals=Off (standardmäßig On) eingestellt, dann sind u.a. die Sessiondaten nur über den $HTTP_SESSION_VARS[]-Hash ansprechbar, ansonsten werden die registrierten Variablen automatisch auf ihren letzten Wert reinitialisiert. Das gleiche gilt auch für die anderen Hashes $HTTP_GET_VARS[], $HTTP_POST_VARS[], $HTTP_COOKIE_VARS[], $HTTP_SERVER_VARS[] und $HTTP_ENV_VARS[].

Dadurch, daß die Sessionvariablen reinitialisert werden, ist es ratsam, die Sessionvariablen als solche zu kennzeichnen, damit man mit den lokalen Variablennamen eines Scripts nicht durcheinander kommt. In den Beispielen in diesem Kapitel wird das durch den Prefix s_ vor diesen Variablen realisiert.

Beispiel 2

Hat man z.B. eine komplizierte Suchmaske z.B für eine Datenbank, aus der man eine noch kompliziertere Query basteln muß, über deren Ergebnisse man auf Folgeseiten browsen will, kann es sich lohnen die Grund-Query einmalig zu generieren, und sie dann weiter an das Ausgabe-/Browse-Script zu übergeben, anstatt alle Eckparameter immerwieder zu übergeben und die Query jedesmal neu zu generieren.

Dies darf natürlich nicht über die GET- oder POST-Methode geschehen, denn der User könnte durch die Manipulation dieser Parameter ohne Probleme "böse" Queries an die Datenbank schicken. Ein Datenverlust ist dann vorprogrammiert.

Für diesen Einsatzzweck eignen sich Sessions auch, denn die dynamisch erzeugte Query wird außerhalb der Reichweite des Users auf dem Server gespeichert.

Beispiel 2: seite3.php (Formularseite)


<?php
    @session_start();
	
    if (isset($submit))
        {
            // Hier prüfen, ob _alle_ benötigten Variablen,
            // die an dieses Script übermittelt wurden,
            // legal sind!
            // Hier nur fortfahren, wenn alles in Ordnung ist
	
            session_register("s_meineTolleQuery");  

            // Die Query wird anhand der Variablen,
            // die submitted wurden, erzeugt
            $s_meineTolleQuery = "SELECT ...";
	
            // HTTP-Redirect zu der Ausgabeseite
            header("Location: http://".getenv("SERVER_NAME")
                                      ."/seite4.php");
            exit;
        }
?>
			
    <FORM action="<?=$PHP_SELF?>" method="post">
        <!--
            Hier ganz viele Radiobuttons, Checkboxen und Inputfelder
        -->
       <INPUT type="submit" name="submit">
    </FORM>

Beispiel 2: seite4.php (Ausgabeseite)


<?php
    @session_start();

    echo "<P>Diese Query wurde mir übermittelt: "
             .$s_meineTolleQuery;
    echo "<P>und jetzt mache ich was draus!";
?>

23.2. Was ist eine Session-ID? Was ist PHPSESSID?

|Session-ID|SessionID|SID|PHPSESSID|GET|Session|Name|ID|

Antwort von Daniel T. Gorski

Die sog. Session-ID ist ein zufällig ausgewählter Schlüssel, der die Sessiondaten auf dem Server eindeutig identifiziert. Dieser Schlüssel kann z.B. über Cookies oder als Bestandteil der URL an ein Folgescript übergeben werden, damit dieses die Sessiondaten auf dem Server wiederfinden kann.

PHPSESSID ist bei PHP4 der Default-Name der Session. Möchte man diesen Namen aus z.B. ästhetischen Gründen modifizieren - vor allem, wenn er als GET-Parameter als Teil der URL sichbar wird - so kann man dies in der php.ini, der Webserverkonfiguration oder direkt mit PHP bewerkstelligen. Der Artikel Wie kann ich den Namen der Session ändern, ohne in die php.ini einzugreifen? geht genauer darauf ein.

Eine Beispiel, wenn die Session-ID als GET-Parameter in der URL übertragen wird:


                            Query-String (alle GET-Parameter)
Protokoll     Subdomain      _________________|__________________
  |              |          /                                    \
http://www.daniel-gorski.de?query=xyz&PHPSESSID=cd45a3f73493d5d...
        |                |            \__________________________/
   Subdomain       Top Level Domain                |
                                       Session-Name und Session-ID

23.3. Wie stelle ich fest, ob der Client die Cookie-Annahme verweigert?

|Session-ID|SessionID|Cookie|GET|Fallback|Fall back|Browser|

Antwort von Daniel T. Gorski

Am Beispiel der Session-Fallback-Klasse in Wie übergebe ich Session-IDs ohne Cookies an eine andere Seite? Was ist Fallback? kann man nachvollziehen, wie man feststellen kann, ob der Client Cookies akzeptiert oder nicht. Das Prinzip ist simpel: Das aufgerufene Script prüft, ob ihm eine Session-ID übergeben wurde. Falls nicht, forciert das Script einen Request auf sich selbst und übergibt dabei eine frisch erzeugte Session-ID als GET- Parameter an sich selbst. Beim zweiten Durchlauf des Scriptes kann dieses feststellen, ob ihm vom Browser ein Cookie mit der Session-ID übermittelt worden ist, oder ob es die Session-ID aus dem GET-Parameter benutzen soll.

23.4. Wie übergebe ich Session-IDs ohne Cookies an eine andere Seite? Was ist Fallback?

|Session-ID|SessionID|Cookie|GET|Fallback|Fall back|URL|

Antwort von Daniel T. Gorski

Viele Browser-User haben in ihrem Browser die Cookies aus diversen Gründen deaktiviert, oder lassen sich jeden Cookie bestätigen. Sollte ein Cookie auf dem lokalen Rechnersystem nicht gesetzt werden können, muß ein Ersatzmechanismus her - ein sog. Fallback. In diesem Fall ist der Fallback (Rückfall / Atavismus) eine Ersatzmethode, die die Übergabe der Session-ID an ein Folgescript ohne Cookies erlaubt.

Man kann den Fallback dadurch realisieren, daß man dem Folgescript die Session-ID quasi "manuell" bei jedem GET


<A href="test.session.php?<?=session_name()."=".session_id()?>">

oder POST - bei Formularen - mittels


<INPUT type  = "hidden"
       name  = "<?=session_name()?>" 
       value = "<?=session_id()?>">

übergibt. ACHTUNG: Das bedeutet, daß jeder Link und jedes Formular innerhalb einer Website mit einem zusätzlichen Parameter versehen werden muß! Wird die Session-ID nicht korrekt übergeben, wird ein Folge-Script nicht auf die Sessiondaten zugreifen können - diese Daten sind für dieses Script "verloren".

PHP4 kann man auch mit dem --enable-trans-sid-Parameter kompilieren. Dann hat dies zufolge, daß wenn der Client (Browser) keine Cookies annehmen kann/will, alle relativen Links einer Webpage mit dem zusätzlichen SessionName=Session-ID Parameter ergänzt werden. Dies klingt zunächst gut, aber man sollte beachten, daß durch den zusätzlichen Aufwand, den der PHP-Parser leisten muß, sich diese Technik nicht für High-Traffic-Websites oder Server mit vielen Vhosts eignet. Auch wenn man Projekte realisiert, die auf anderen Webservern laufen sollen, kann man nicht davon ausgehen, daß das betreffende PHP mit --enable-trans-sid kompiliert worden ist.

Die --enable-trans-sid-Technik versagt (PHP 4.0.1.pl2) auch bei folgenden Konstrukten:


<FORM action="<?=$PHP_SELF?>">

weil offensichtlich zuerst an den action-Tag die Session-ID-Information angehängt wird, und dann erst der Wert von $PHP_SELF. Das Ergebnis sieht dann fälschlicherweise so aus:


<FORM action="?PHPSESSID=cd45a3f76f7325099c755b25b/test.session.php">

Fallback-Klasse

Wie bereits erwähnt, muß man u.U. selbst dafür Sorge tragen, daß der Fallback-Mechnismus greift, wenn der Client keine Cookies annimmt. Eine PHP-Klasse die das leisten kann ist auf http://develnet.org/ verfügbar.

Sie fügt bei Bedarf die Session-ID an Hyperlinks, Formulare und Redirects und ermöglicht die punktgenaue Steuerung des Fallbacks. Mit dieser Klasse muss man sich ebenfalls keine Gedanken beim Hosterwechsel machen, da man nicht auf die u.U. nicht vorhandene --enable-trans-sid-Funktionalität angewiesen ist.

Diese Klasse erlaubt zusätzlich das bequeme Registrieren von Session-Variablen, auch wenn PHP mit register_globals=off konfiguriert ist.

23.5. Warning: Cannot send session cookie - headers already sent...

|Cookie|Header|Cache|Fehler|Session|HTTP|

Antwort von Daniel T. Gorski

Wie bei allen anderen HTTP-Headern, darf auch vor dem Setzen von Cookies (Sessionfunktionen von PHP4 benutzen standardmäßig Cookies) kein einziges Byte des Codes an den Client gesendet werden. Erst wenn alle HTTP-Header gesendet worden sind, dürfen entsprechende Daten (z.B. HTML) gesendet werden.

Typische Stolperfallen sind Leerzeichen bzw. -zeilen vor dem ersten <? bzw. <?php Delimiter des Scripts oder mit include() oder require() importierte Scriptfragmente, die natürlich gar keine Ausgabe produzieren dürfen - weder vor dem ersten Delimiter, noch dazwischen, noch nach dem letzten.

Zusätzlich kommt durch die auto_prepend_file-Einstellung in der php.ini, bzw. in der Webserverkonfiguration, eine weitere potentielle Fehlerquelle hinzu.

23.6. Wie kann ich den Namen der Session ändern, ohne in die php.ini einzugreifen?

|Session|Name|php.ini|aendern|umbenennen|

Antwort von Daniel T. Gorski

In der php.ini wird der Name der Session in dem Parameter session_name festgelegt - standardmäßig auf PHPSESSID. Möchte man ohne Eingriff in die php.ini oder in die Webserverkonfiguration diesen Namen ändern, steht die Funktion session_name() zu Verfügung. Diese Funktion muß vor dem (Re)initialisieren der Sessiondaten (session_start() bzw. session_register()) ausgeführt werden.


<?php
    // Einen anderen Namen für die Session festlegen
    session_name("meineSession");
    @session_start();
?>

23.7. Wie schütze ich Sessiondaten zusätzlich?

|Session|Schutz|Host|virtuell|Sicherheit|

Antwort von Daniel T. Gorski

Laufen auf einer Maschine mehrere virtuelle Hosts (vhosts), z.B. bei einem Hoster, muß der verantwortliche Administrator dafür Sorge tragen, daß - wenn überhaupt - der Safe-Mode nur für 100% vertrauenswürdige vhost-Nutzer ausgeschaltet werden darf (safe_mode=Off). Dies würde - neben anderen systemnahen Eingriffen - erlauben, daß ein Script von einem anderen Vhost folgenden Code ausführen darf:


<?php
    // Inhalt von /tmp löschen
    system("rm -rf /tmp");
?>

Dies hätte in der PHP4-Standardeinstellung (aber mit safe_mode=Off) zufolge, daß alle Sessiondaten anderer Benutzer gelöscht worden wären. Gegebenfalls sollte man sich mit einer entsprechenden Anfrage an seinen Hoster wenden.

Eine andere Möglichkeit dies zu verhindern wäre es, für jeden Vhost eine andere Einstellung des session.save_path-Parameters zu wählen, wenn Sessiondaten in Files gespeichert werden.

23.8. Wie groß darf die Menge an Daten sein, die ich in einer Session speichern darf?

|Session|Daten|Menge|Kilobyte|Performance|speichern|

Antwort von Daniel T. Gorski

Diese Frage läßt sich im Grunde nur mit "maßvoll" beantworten. Der Unterschied zwischen wenigen Bytes und 5KB, wird sich nicht ungünstig auf die Performance des Servers auswirken.

Eigene Performancemessungen ergeben hier eindeutig einen Wissensvorteil. Zudem sollte man bedenken, daß größere Datenmengen besser in einer Datenbank aufgehoben sind - und man sollte seine Datenverwaltung nochmals gründlich überschlafen.

23.9. Wie kann ich mir den Inhalt der Sessiondaten anzeigen lassen?

|Session|Inhalt|anzeigen|Daten|

Antwort von Daniel T. Gorski

Ähnlich wie die Ausgabe anderer PHP-Hashes (assoziativer Arrays) lassen sich Sessiondaten mittels einer kleinen Schleife ausgeben. Zuvor muß die Session mit session_start() initialisiert werden. Dies bewirkt, daß der $HTTP_SESSION_VARS-Hash gefüllt wird. Der Konfigurationsparameter track_vars der php.ini muß eingeschaltet sein.


<?php
    @session_start();
    while (list($key,$value) = each($HTTP_SESSION_VARS))
       {
           echo $key." = ".$value."<br>";
       }
?>

23.10. Wie kann ich mir den Inhalt der Cookiedaten anzeigen lassen?

|Session|Cookie|Daten|anzeigen|Inhalt|

Antwort von Daniel T. Gorski

Analog zu obigen Beispiel kann man über $HTTP_COOKIE_VARS auf den Inhalt eines Cookies zugreifen. Auch hier muß der Konfigurationsparameter track_vars der php.ini eingeschaltet sein.


<?php
    @session_start();
    while (list($key,$value) = each($HTTP_COOKIE_VARS))
       {
           echo $key." = ".$value."<br>";
       }
?>

23.11. Sessiondaten werden nach session_destroy() nicht gelöscht. Wie kann ich sie trotzdem löschen?

|Session|loeschen|Daten|Datei|Fehler|session_destroy|

Antwort von Daniel T. Gorski


<?php
    // Wenn es doch nötig wird - brute force

    @session_start(); 
    @session_destroy();

    if (strtolower(session_module_name()) == 'files') 
        { 
            $deli = substr(PHP_OS, 0, 3) == 'WIN' 
                    ?   '\\' 
                    :   '/'; 
            @unlink(get_cfg_var('session.save_path') 
                   .$deli.'sess_'.session_id()); 
        } 
?>

23.12. Was geschieht im Filesystem des Servers, wenn ich Sessions benutze?

|Session|Datei|Verzeichnis|Server|speichern|save_path|

Antwort von Daniel T. Gorski

Damit der Vorgang der Sessionspeicherung ein wenig verdeutlicht wird, untersuchen wir die Veränderungen im Filesystem des Servers. Die folgenden Beispiele laufen auf einem Linux/Unixsystem. Um sie nachvollziehen zu können, muß PHP4 mit safe_mode=Off konfiguriert werden. Zusätzlich wird davon ausgegangen, daß der Client (Browser) Cookies akzeptiert.

Als allererstes braucht man ein Script, welches den Inhalt des im session.save_path festgelegten Directories anzeigen kann:


<?php
    // Datei: list.dir.php
    // Liste das "session.save_path" Directory
    // "safe_mode" muß "Off" sein
    if (strtolower(session_module_name()) == "files")
        {
            echo "<pre>";
            system("ls -l ".get_cfg_var("session.save_path"));
            echo "</pre>";
        }
?>

Dieses Script wird unter dem Namen list.dir.php gespeichert. Hat man z.B. Shell-Zugriff auf den benötigten Teil des Servers, führt natürlich auch ein einfaches ls -l /tmp zu der von list.dir.php produzierten Ausgabe.

Das obige Script wird ausgeführt, um den Ursprungszustand des im session.save_path gespeicherten Verzeichnisses zu betrachten. Zunächst produziert das Script folgendes:

Ausgabe (mit list.dir.php):


    insgesamt 0
    srwxrwxrwx    1 root     root   0 Sep 22 21:38 mysql.sock

Das Verzeichnis (in diesem Fall /tmp) ist fast leer. Die Datei mysql.sock kann für unseren Zweck vernachlässigt werden.

Als nächstes schreibt man ein Script, welches nach und nach ergänzt oder verändert wird, um die Veränderungen im Filesystem zu beobachten. Der Name diese Scriptes sei session.php. Dieses Script enthält nur die Funktion session_start(). Nach dem Start beobachten wir die Veränderungen:


<?php
    // Datei: session.php
    @session_start();
?>

Ausgabe (mit list.dir.php):


    insgesamt 0
    srwxrwxrwx    1 root     root   0 Sep 22 21:38 mysql.sock
    -rw-------    1 wwwrun   www    0 Okt  1 17:58 sess_cd45a3f76f73250..

Wie man sehen kann, hat PHP eine Sessiondatei mit den Zugriffsrechten des Webservers erzeugt, dessen Prozeß es ja ist. Diese Datei ist zunächst 0 (Null) Byte groß. Diese Datei wird gleich die Sessiondaten aufnehmen.

Als nächstes wird das Script um die session_register() Funktion erweitert, die festlegt, daß die Variablen $s_userName und $s_userPermissions und ihre Inhalte gespeichert werden sollen. Bei den Parametern der session_register() Funktion handelt es sich nicht um die Variablen selbst, sondern um ihre Namen. Diese Parameter besitzen kein führendes "$".


<?php
//  Datei: session.php
    @session_start();
    session_register("s_userName","s_userPermissions");

    $s_userName        = "dtg";
    $s_userPermissions = "keine :=(";
?>

Ausgabe (mit list.dir.php):


    insgesamt 4
    srwxrwxrwx    1 root     root   0 Sep 22 21:38 mysql.sock
    -rw-------    1 wwwrun   www   55 Okt  1 17:58 sess_cd45a3f76f73250..

Die Sessiondatei ist nun auf 55 Byte angewachsen. Sie enthält folgenden String:


    s_userName|s:3:"dtg";s_userPermissions|s:9:"keine :=(";

also die serialisierten (serialize()) Namen und Inhalte der Variablen, die mit session_register() bestimmt wurden. In den Sessiondaten können verschiedene Variablentypen gespeichert werden, also auch Arrays und Objekte.

Wenn man jetzt auf eine Variable in der Sessiondatei verzichten will, kann man mittels session_unregister() PHP davon abhalten, die betreffende Variable zu speichern:


<?php
    // Datei: session.php
    @session_start();
    session_unregister("s_userPermissions");

    $s_userPermissions = "ich will nicht gespeichert werden";
?>

Ausgabe (mit list.dir.php):


    insgesamt 4
    srwxrwxrwx    1 root     root   0 Sep 22 21:38 mysql.sock
    -rw-------    1 wwwrun   www   21 Okt  1 17:59 sess_cd45a3f76f73250..

Die Variable $s_userPermissions wurde verworfen, die Sessiondatei ist nur noch 21 Byte groß und enthält nur noch die Variable $s_userName:


    s_userName|s:3:"dtg";

Möchte man nun alle Sessiondaten löschen stellt PHP4 die Funktion session_destroy() zur Verfügung. Vor einem session_destroy() muß aber ein session_start() oder session_register() ausgeführt werden:


<?php
    // Datei: session.php
    @session_start();
    session_destroy();
?>

Ausgabe (mit list.dir.php):


    insgesamt 0
    srwxrwxrwx    1 root     root   0 Sep 22 21:38 mysql.sock

Die Sessiondatei wurde gelöscht und die Sessionvariablen stehen für weitere Scripte nicht mehr zur Verfügung. Wird nach diesem Zeitpunkt nochmals die Funktion session_start() bzw. session_register() im gleichen Browserfenster aufgerufen, wird die Sessiondatei erneut erzeugt, und zwar u.U. mit dem gleichen Namen d.h. mit der gleichen Session-ID(!). Der Grund dafür ist, daß der vom Browser gespeicherte Cookie - der die Session-ID enthält - erneut an den Server übermittelt wird.

23.13. Wie benutze ich die Session-Funktionen unter Windows?

|Session|Windows|Pfad|speichern|php.ini|Konfiguration|save_path|

Antwort von Sebastian Bergmann

Der Wert von session.save_path in der php.ini ist in seiner Standardeinstellung für den Einsatz der session_*() Funktionen auf Win32 unbrauchbar. Abhilfe schafft hier das Anlegen eines neuen Verzeichnisses, zum Beispiel c:\winnt\temp\sessions\, dessen Ort man nun als Wert für session.save_path in der php.ini angibt.