Ein kleiner Auszug aus dem antiquierten Artikel:

Da Session-Ids üblicherweise in temporären Cookies gespeichtert werden, die beim Request/Response zwischen Server und Client ausgetauscht werden, entsteht beim Umgang mit Sessions ein technisches Problem, und zwar wenn der Client/Browser keine Cookie annehmen kann oder will. In diesem Fall muss die Session-Id auf einem anderem Weg übertragen werden, und zwar als ein Teil des URL (also der Adresse einer Website).

Das PHP-Script muss feststellen, ob der Client Cookies annimmt und ggf. darauf reagieren. Diesen Mechanismus nennt man Fallback. Also einen Rückfall oder Atavismus: zuerst wird versucht einen Cookie zu setzen, schlägt dies fehl wird auf eine alternative Verfahrensweise ausgewichen.

Ein großer Nachteil des Fallbacks im URL ist, dass bei einer aktiven Verlinkung der Referer (also die Adresse der Seite – woher man kam) von den meisten Browsern an die Ziel-Seite übergeben wird und somit die Session-Id Fremden mitgeteilt wird.

Da dies ein potentielles Sicherheitsrisiko darstellt, empfiehlt es sich bei Links auf fremde Seiten auf die Übergabe der Session-Id zu verzichten. Dies klingt einleuchtend, birgt aber Fallen, sofern man PHP mit der Option --enable-trans-sid kompiliert hat und den kaputt-automatischen Fallback von PHP 4 benutzt (Stand Sommer 2000).

Befindet man sich auf einer Seite, die Session-Fallback benutzt, und steuert man eine fremde Seite über die direkte Eingabe des URL in das Adressfeld des Browsers oder über ein Lesezeichen (Bookmark), so ist nicht zu befürchten, dass der Browser den Referer samt der Session-Id an die fremde Seite sendet.

--enable-trans-sid befähigt den PHP-Parser selbständig den Fallback auszuführen, sofern er zusätzlich in der php.ini aktiviert wird (session.use_trans_sid=1). Durch das automatische – bei jedem Request wiederkehrende – Umschreiben aller relevanten HTML-Tags (<a>, <form>, etc.) durch den Parser benötigt das Script mehr Zeit um abgearbeitet zu werden.

Abhängig von der PHP-Version funktioniert der in PHP implementierte Fallback u.U. nicht richtig, und liefert falschen Code. Vorallem eingebettete JavaScript-Funktionen können funktionellen Schaden erleiden, wenn sie Konstrukte wie z.B. location.href="index.php" nutzen. In diesem Fall gibt es für den Parser kaum eine Chance das als relevanten Code zu erkennen und ggf. die Session-Id als GET-Paramater an den diesen Redirect anzufügen. Die Session-Daten wären dann für das index.php-Script verloren, da ja keine mehr Zuordnung zu der Sessiondatei hergestellt werden kann

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 /tmp -l 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:

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();
?>

insgesamt 0
srwxrwxrwx    1 root     root   0 Sep 22 21:38 mysql.sock
-rw-------    1 wwwrun   www    0 Apr 17 18:00 sess_edb0e8665db4...

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ührendenes “$”.

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

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

insgesamt 4
srwxrwxrwx    1 root     root   0 Sep 22 21:38 mysql.sock
-rw-------    1 wwwrun   www   55 Apr 17 18:01 sess_edb0e8665db4...

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 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';
?>

insgesamt 4
srwxrwxrwx    1 root     root   0 Sep 22 21:38 mysql.sock
-rw-------    1 wwwrun   www   21 Apr 17 18:02 sess_edb0e8665db4...

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 PHP die Funktion session_destroy() zur Verfügung. Vor einem session_destroy() muß zwingend ein session_start() oder session_register() ausgeführt werden:

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

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 erneut eine (leere) Sessiondatei erzeugt, und zwar exakt mit dem gleichen Namen d.h. mit der gleichen Session-ID. Der Grund dafür ist, daß der vom Browser gespeicherte Cookie – der ja die Session-ID enthält – erneut bei einem Request an den Server übermittelt wird.

Warning: Cannot send session cookie – headers already sent…
Der häufigste Fehler ist der Versuch eine Session zu starten, nachdem HTML-Daten an den Browser geschickt worden sind. Diesen Versuch quitiert PHP 4 mit “Warning: Cannot send session cookie – headers already sent…”.

Ein Response – die Antwort – des Webservers teils sich in zwei Bereiche:

• den Header, der u.a. den Content-Type (z.B. HTML oder Bilddaten) der Daten definiert
• und die Daten selbst

Wird nun von einem PHP-Script z.B. ein Leerzeichen ausgegeben, so nimmt PHP an, dass es sich um HTML handelt und schickt automatisch entsprechende Header und das Leerzeichen (Daten) an den Browser. Versucht nun PHP danach nochmals einen Header zu senden, kommt es zu der beschreibenen Fehlermeldung, da das Senden der Header bereits abgeschlossen ist.

Man mag sich jetzt fragen, wo der Zusammenhang zwischen dem Versuch session_start() resp. session_register() auszuführen und den Headern besteht. Nun, die Session-Funktionen benutzen Cookies zur Speicherung der Session-ID, und ein Cookie wird als Teil des Response-Headers an den Browser übermittelt. In der PHP-Voreinstellung führt jedes Starten der Session zum Versuch einen Cookie mittels einem Header an den Client zu schicken.

Die typischen Stolperfallen:

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

1: <!-- HTML: meine dynamische Webseite mit Sessions -->
2:  
3: <?php
4:   @session_start();  
5: ?>

Falsch (Leerzeile in Zeile 4):

1: <?php
2:   include 'seitenkopf.php';
3: ?>
4:  
5: <?php
6:   @session_start();  
7: ?>

Richtig:

1: <?php
2:   /* 'seitenkopf.php' produziert keine Ausgabe! */
3:      
4:   include 'seitenkopf.php';
5:  
6:   @session_start();  
7: ?>

• Eine Session muss vor der Ausgabe jeglicher Zeichen gestartet werden, also am besten als einer der allerersten Befehle eines Scriptes.

Warning: open(/tmp\sess_…, O_RDWR) failed…

Windowsbasierte Betriebssysteme benutzen einen Backslash (”\”) als Verzeichnistrenner. In der php.ini ist dagegen der Standardpfad für die Sessiondateien als /tmp eingetragen – also mit einem normalem Slash (”/”), wie er auf unixoiden Betriebssystemen benutzt wird. Abhilfe schafft hier z.B. das Anlegen eines Verzeichnisses c:\temp und die entsprechende Änderung in der globalen Konfigurationsdatei php.ini:

session.save_path  = c:\temp       ; für Windows

Da wir mittlerweile wissen, dass die Werte von registrierten Sessionvariablen erst am Ende des Scriptes gespeichert werden, können wir davon ausgehen, dass der Versuch eine Sessionvariable innerhalb einer Funktion zu registrieren nur zu einem Teilerfolg führen wird. Der Variablename wird in den Session-Daten gespeichert (registriert), aber der Wert der Variable wird der letzte Wert im globalen Scope sein: u.U. leer oder falsch. Wahrscheinlich wurde das innerhalb einer Funktion nicht beabsichtigt.

Datei: sess.howto5.php

<?php
  @session_start();
  $s_foo = 'one'; 

  function doRegister() {
    session_register('s_foo');     
    $GLOBALS['s_foo'] = 'another';
  } 

  doRegister();
?>

Dieses Script registriert die Variable $s_foo mit ihrem Wert (”another”) in der Session. Wie man es sich leicht vorstellen kann, können solche Konstrukte ins Auge gehen, wenn sich Variablen mit gleichen Namen im globalem Scope befinden: in diesem Fall wird der Wert “one” der Variable $s_foo überschreiben.

Datei: sess.howto6.php

<?php
  @session_start(); 

  function doSomething($x) {
    $y = $x * $x;
    return $y;
  }

  session_register('s_result');
  $s_result = doSomething(42);
?>

Datei: sess.howto7.php

<?php
  @session_start(); 

  function doSomething($x) {
    $y = $x * $x;
    $z = dechex($y);   

    return array('y' => $y, 'z' => $z);
  } 

  session_register('s_result');
  $s_result = doSomething(42);
?>

Datei: sess.howto8.php

<?php
  @session_start(); 

  function doSomething($x) {
    $y = $x * $x;
    $z = dechex($y);

    return array('y' => $y, 'z' => $z);
  }

  session_register('s_y', 's_z');

  $s_result = doSomething(42);

  $s_y = $s_result['y'];
  $s_z = $s_result['z'];
?>

Die Initialisierung der Session setzt zuerst einen Prozeß in Gang, den man Garbage Collection (gc) nennt, und der dafür sorgt, dass alle verwaisten Sessiondateien aus dem Filesystem entfernt werden – erst danach wird ggf. eine neue Sessiondatei angelegt.

Um zu bestimmen, ob eine Sessiondatei verwaist ist, stellt PHP 4 den Konfigurationsparameter session.gc_maxlifetime in der php.ini bereit.

Der nummerische Wert von session.gc_maxlifetime gibt an, nach wievielen Sekunden eine Sessiondatei als Müll angesehen wird und entfernt werden darf (Default: 1440 Sekunden = 24 Minuten). Wenn die Differenz aus der Initialisierungszeit der Session (Jetzt-Zeit aus der Sicht des Scripes) und dem letzten Zugriff auf eine oder mehrere Sessiondateien den session.gc_maxlifetime-Wert übersteigt, werden diese Dateien gelöscht.

In der PHP 4-Defaulteinstellung wird die Garbage Collection statistisch jedoch nur bei jedem hundertsten session_start() angestoßen.

Verantwortlich hierfür ist der Konfigurationsparameter session.gc_probability. Dieser hat den Wert “1″ und gibt die Wahrscheinlichkeit an, mit welcher die Müllsammlung gestartet wird, also in 1% der Fälle. Möchte man, dass ältere Sessiondateien zuverlässig gelöscht werden, so ist dieser Wert auf 100 (=100%) zu stellen.

Jede Garbage Collection benötigt natürlich auch ein wenig Zeit, sodaß man sich die Frage stellen sollte, ob es nicht ausreicht die Sessiondateien z.B. nur bei jeder zehnten Sessioninitialisierung (10%) löschen zu lassen.

Diese Parameter können in der php.ini, aber auch – wie viele andere Optionen – in den Webserverkonfigurationsdateien, der .htaccess-Datei oder direkt im Script beeinflußt werden.

Hier ein paar Beispiele für die verschiedenen Konfigurationsmöglichkeiten:

php.ini:

session.gc_maxlifetime = 600  ; 10 Minuten Lebenszeit
session.gc_probability = 50   ; 50% - ca. bei jedem
                              ; zweiten Mal löschen

httpd.conf oder .htaccess oder verwandte Dateien:

# Session lebt 30 Minuten
php_value  session.gc_maxlifetime  1800

# Alte Session mit 100% Wahrscheinlicheit löschen
php_value  session.gc_probability  100

Direkt im Script:

<?php 

    // 20 Minuten Lebenszeit
    ini_set("session.gc_maxlifetime", 1200);

    // 100% Wahrscheinlichkeit
    ini_set("session.gc_probability", 100);

?>

Werden diese Parameter direkt im Script verändert, so muß dies vor dem ersten session_start() resp. session_register() ausgeführt werden, also bevor die Session initialisiert wird.

Abhängig von der register_globals-Einstellung in der php.ini, werden die in den Sessiondaten registrierten Variablen bei einem session_start() wieder restauriert – d.h. diese Variablen und ihre Werte werden im globalen Variabenscope wiederhergestellt.

Zusätzlich stellt PHP 4 assoziative Arrays (Hashes) mit externen Daten zur Verfügung. Mit “externen Daten” sind Daten von außerhalb des Scriptes gemeint: also z.B. Server-Variablen, GET-, POST- und COOKIE (GPC) Daten. Diese Daten lassen sich über die entsprechenden Hashes abrufen. Hier eine Auswahl der PHP-Hashes:

• $HTTP_SERVER_VARS
• $HTTP_GET_VARS
• $HTTP_POST_VARS
• $HTTP_COOKIE_VARS
• und $HTTP_SESSION_VARS

Ab der PHP Version 4.1.0 wurden diese Hashes durch die superglobalen Hashes ersetzt. Möchte man die Beispiele aus diesem Tutorial benutzen, so sind je nach PHP Version die entprechenden Hashes im Quelltext zu ersetzen:

• $_SERVER
• $_GET
• $_POST
• $_COOKIE
• und $_SESSION

Der letzte Hash ($HTTP_SESSION_VARS resp. $_SESSION) ist für unseres Tutorial von besonderer Bedeutung: in diesem Hash werden – nach dem Start einer Session – die registrierten Session-Variablen ebenfalls zur Verfügung gestellt. Also sind die Session-Daten zweifach vorhanden: als einzelne Variablen und zusammenhängend als ein Hash. Doch Vorsicht: in neueren PHP 4-Versionen werden die $HTTP_SESSION_VARS als Referenzen behandelt, d.h. eine Änderung des Inhalts einer Variable in diesem Hash zieht auch eine Änderung der Variable mit gleichem Namen im globalen Variablen-Scope nach sich. Dieses Verhalten ändert sich je nach Blut-THC-Konzentration der PHP Programmierer.

Der Zugriff auf alle externen Daten sollte nicht direkt über die automatisch restaurierten Variablennamen erfolgen, sondern über Hashes, da anderenfalls durch Mißkonfigurationen der php.ini Sicherheitslücken entstehen könn(t)en. Diesem Leitsatz folgen wir auch hier und arbeiten mit dem $HTTP_SESSION_VARS-Hash.

Als nächstes wollen wir uns mal ein paar kleine Beispiele anschauen. Damit diese Beispiele wunschgemäß laufen, muss dein Browser temporäre Session-Cookies akzeptieren. Also, sollte die Session-Cookie-Annahme bei deinem Browser ausgeschaltet sein, so ist jetzt der richtige Zeitpunkt sie wieder einzuschalten.

Im separaten Fallback-Tutorial wird beschrieben wie man Session-IDs auch ohne Cookies durchschleifen kann.

So nun zu den Beispielen

Einfache Registrierung von Variablen

Datei: sess.howto1.php

<?php
  @session_start();
  session_register('s_userName', 's_userPerm');
  $s_userName = 'dtg';
  $s_userPerm = 'nada';
?>

<html>
<body>
  <h1>
    Datei: <?php echo getenv('SCRIPT_NAME') ?>
  </h1>

  <p>
     Es wurden Variablen in der Session registriert.
  </p>

  <a href="sess.howto2.php">Weiter ...</a>
</body>
</html>

<?php
  @session_start();
?>

<html>
<body>
  <h1>
    Datei: <?php echo getenv('SCRIPT_NAME') ?>
  </h1>

  <p>
    Folgende Variablen wurden in der Session registriert:
  </p>

  <?php
    foreach ($HTTP_SESSION_VARS as $k => $v) {
      echo '<p>' . $k . ' = ' . $v . '</p>';
    }
  ?>

  <a href="sess.howto1.php">Zurück ...</a>
</body>
</html>

Registrierung mit Formular

Datei: sess.howto3.php

<?php
  @session_start();
  if (isset($HTTP_POST_VARS['submit'])) {

    session_register('s_userUnfug');
    $s_userUnfug = $HTTP_POST_VARS['s_userUnfug'];

    header('Location: http://'.getenv('HTTP_HOST').'/sess.howto4.php');
    exit;
  }
?>

<html>
<body>
  <h1>
    Datei: <?php echo getenv('SCRIPT_NAME') ?>
  </h1>

  <form action="<?php echo getenv('SCRIPT_NAME') ?>" method="post">

    <p>
      Hier kannst du Unfug eingeben:
    </p>

    <input name="s_userUnfug"
           type="text"
           value="<?php
                     echo $HTTP_SESSION_VARS['s_userUnfug']
                   ?>">
    <input name="submit" type="submit">
  </form>
</body>
</html>

<?php
  @session_start();
?>

<html>
<body>
  <h1>
    Datei: <?php echo getenv('SCRIPT_NAME') ?>
  </h1>

  <p>
    Das ist Unfug:
    <?php echo $HTTP_SESSION_VARS['s_userUnfug'] ?>
  </p>

  <a href="sess.howto3.php">Zurück ...</a>
</body>
</html>

Diese Variablen verbleiben in den Session-Daten bis sie explizit mit session_unregister() ‘entfernt’ werden, die Session-Daten gänzlich – z.B. mit session_destroy() – gelöscht werden oder die Session ihre Lebensdauer erreicht (php.ini: session.gc_maxlifetime).

Ab der PHP Version 4.1.0 wurden die sog. superglobalen Hashes eingeführt. Somit gelten die $HTTP_*_VARS als veraltet, obwohl sie per Schalter in der php.ini noch aktiviert werden können, um die Kompatibilität mit älteren Scripten zu gewährleisten. Anstatt $HTTP_SESSION_VARS ist in neueren PHP Versionen $_SESSION zu benutzen.

Die wichtigsten PHP 4-Sessionfunktionen mit ihrer Auswirkung seien hier kurz vorgestellt:

• session_start()
• session_register()
• session_unregister()
• session_destroy()

session_start()

Die Session initialisieren und eine Session(datei) auf dem Server erstellen. Wurde beim Request 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 im laufendem Script reinitialisiert.

Manche PHP 4-Versionen enthalten einen Bug, der bei der php.ini -Einstellung register_globals=off, den $HTTP_SESSION_VARS-Hash nicht richtig wiederherstellen. Bei einen Verdacht auf eine Fehlfunktion könnte diese Einstellung auf on geändert werden und u.U. der Webserver neu gestartet werden.

Zusätzlich werden, je nach Einstellung des session.gc_probability- und des session.gc_maxlifetime-Parameters, die in dem Augenblick der Sessioninitialisierung angehäuften und nicht mehr benötigten Sessiondateien auf dem Server gelöscht.

Wenn das error_reporting() schärfer eingestellt ist, gibt session_start() bei älteren PHP 4-Versionen eine Notice aus, wenn die Garbage Collection – das Löschen alter Sessiondateien – durchgeführt wird. Da diese Notice nicht erwünscht ist, empfiehlt es sich vor die session_start()-Funktion ein “@” zu schreiben, welches die entsprechende Ausgabe unterdrückt.

<?php
    @session_start();
?>

Bei der Entwicklung einer sessionbasierten Applikation sollte man einen besonderen Augenmerk auf den “@” Operator richten, da das “@” auch einen beliebten Programmierfehler unterdrückt, der dann schlecht aufzuspüren ist.

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ührendenes “$”.

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.

<?php
    $var1 = 'variable #1';
    $var2 = 42;
    $var3 = true;

    @session_start();
    session_register('var1');
    session_register('var2', 'var3');
?>

session_unregister()

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

<?php
    @session_start();
    session_unregister('var1');
?>

session_destroy()

Die Funktion session_destroy() veranlasst PHP alle Variablen einer Session zu verwerfen und die Session(datei) löschen. Dem session_destroy() muss ebenfalls ein session_start() oder session_register() vorangehen.

<?php
    @session_start();
    session_destroy();
?>

Manche Portierungen von PHP 4 für windowsbasierte Betriebssysteme haben Probleme mit der Löschung von Sessiondateien und melden: “Warning: Session object destruction failed …”. In diesem Fall kann man mittels des folgenden Scriptes die Sessiondatei “manuell” löschen:

<?php
    @session_start();
    @session_destroy();  /* könnte fehlschlagen */

    if (strtolower(session_module_name()) == 'files') {
        @unlink(
            get_cfg_var('session.save_path')
            .'/sess_'
            .session_id()
        );
    }
?>

Dieses Script löscht die Sessiondatei aus dem Filesystem, sodaß beim erneuten Zugriff keine Daten wiederhergestellt werden können.

• Registrierte Variablen werden am Ende eines Scriptes in die Session(datei) geschrieben.
• Sie können zwischen dem Registrieren und dem Scriptende verschiedene Werte haben.
• Der Zugriff auf registrierte Variablen ist erst wieder nach einem session_start() möglich.

Dies bedeutet, dass sich der Programmierer der serverseitigen Software theoretisch keine Sorgen machen muss, wie die Session-ID vom Browser wieder zurück zum Webserver kommt, da diese Arbeit automatisch vom Browser erledigt wird.

Cookies sind nichts anderes als menschenlesbare Textdateien, in denen ein Webserver spezifische Daten auf der lokalen Platte des Benutzers ablegen kann. Diese Daten sind u.U. recht kryptisch gehalten, so daß meistens nur der Autor der serverseitigen Software – die den Cookie gesetzt hat – weiß, wie diese Cookie-Daten zu interpretieren sind.

Dies ist aber für uns irrelevant und soll uns nicht weiter beschäftigen, denn wir wollen feststellen, daß die Größe des Cookie – per Definition – ca. 4000 Zeichen nicht überschreiten darf (wovon wir ca. 40 Zeichen benötigen), und dass es zwei Arten von Cookies gibt:

• “Persistente Cookies” werden für einen definierten Zeitraum (Gültigkeitsdauer) auf der Festplatte des Benutzers als normal lesbare Textdatei gespeichert. Dieser Zeitraum kann sich von wenigen Minuten bis mehreren Jahren erstrecken.
• Die Lebensdauer der “temporären Session-Cookies” beschränkt sich auf die Lebensdauer des Browser-Fensters. Wird dieses geschlossen, wird auch der temporäre Cookie verworfen. Dieser Cookie wird üblicherweise nicht auf der Festplatte gespeichert; er residiert im Arbeitsspeicher des Rechners.

In der Standardeinstellung benutzt PHP 4 die zweite Variante – die temporären Cookies – um Session-IDs zu speichern. Im Cookie wird der Name der Session und die bereits erwähnte zufällige Zeichenfolge der Session-ID gespeichert. Der Name der Session ist eine frei wählbare Bezeichnung, die uns später als Variable bei der Auswertung der Sessiondaten im PHP-Script zu Verfügung stehen wird. Per Voreinstellung lautet der Name der Variable bei PHP 4: PHPSESSID. Die Länge der von PHP 4 produzierten Session-ID beträgt 32 Zeichen.

Als Ergebnis können wir annehmen, dass bei der Initialisierung einer Session, PHP einen Cookie mit etwa dem folgenden Inhalt beim Benutzer hinterlegt:

PHPSESSID=edb0e8665db4e9042fe0176a89aade16

Der linke Teil des Strings wird als Sessionname und der rechte – die zufällige Zeichenkette “edb0e8665db4e9042fe0176a89aade16″ – als Session-ID bezeichnet.

Diese Session-ID ist der Schlüssel zur Wiedererkennung des Benutzers und zur Restaurierung der von ihm gesetzten Daten. Die Session-ID repräsentiert bei PHP 4 – per Voreinstellung – eine temporäre Datei im Filesystem des Servers. Auf unixoiden Betriebssystemen wird die PHP-Sessiondatei standardmäßig im Verzeichnis /tmp/ erstellt. In der php.ini – der globalen Konfigurationsdatei – oder ein der Webserverkonfiguration läßt sich dieser Wert natürlich verändern.

Diese Session-Datei bekommt im Namen den Prefix sess_, so dass das Ergebnis im Filesystem des Servers folgendermaßen aussehen kann:

goosh@warpcore:~> ls /tmp/ -l
insgesamt 0
-rw------- 1 wwwrun www 0 Apr 17 18:00 sess_edb0e8665db4...

In dieser Datei kann ein PHP-Script Benutzerdaten ablegen – z.B. die Artikelnummer und die Anzahl der bestellten Artikel für einen Warenkorb oder einfach nur ob ein Benutzer sich authorisiert hat und Zugriff auf eine Webseite hat.

Dadurch dass der Browser den Inhalt des Cookies bei einem Request mitschickt, ist es möglich den Benutzer über mehrere Webseiten zu authentifizieren oder die vom Benutzer gesetzten Variablen von einer Seite auf eine andere zu übernehmen.

Die Manipulation dieser Session-Datei bleibt nur dem serverseitig ausgeführtem PHP-Script vorbehalten. Der Client weiß nicht welche Daten von dem Script gespeichert werden und er kann keinen mittelbaren Einfluß auf diese Daten nehmen. Ausnahme bildet hier die Änderung oder Löschung dieser Daten durch den Administrator oder durch ein auf dem Server laufendes Script mit entsprechenden (Datei-)Rechten.

• In der Voreinstellung benutzt PHP 4 temporäre Cookies um Session-IDs zu speichern.
• Defaultname der Session ist PHPSESSID.
• Eine mit PHP 4 generierte Session-ID ist 32 Zeichen lang (MD5 digest).
• Sessiondateien werden im Ordner /tmp/ gespeichert.
• Sessiondateien können nur serverseitig geändert werden.

Wozu Sessions?

Sofern man dieses Tutorial online liest, wird man entweder auf einen Link geklickt, oder die Adresse dieser Seite manuell eingegeben haben. Spätestens dabei wird es (hoffentlich) aufgefallen sein, dass die Adressen der meisten Webseiten mit http:// beginnen.

Die Abkürzung HTTP liest sich “HyperText Transfer Protocol” und ist der Grundstein für das World Wide Web, wie wir es heute kennen – es regelt die Verständigung zwischen dem Client (z.B. Browser) und dem Webserver, der die auf ihm gespeicherten Webseiten zur Verfügung stellt.

In der derzeitigen Implementation (HTTP 1.1), hat das HTT-Protokoll leider einen großen Nachteil: es ist “zustandslos”. Vereinfacht bedeutet das:

• Der Client (Browser) öffnet eine Verbindung zum Webserver, und fragt nach einer Webseite (Request).
• Der Webserver antwortet (Response) mit dem gewünschten Inhalt (oder einer Fehlermeldung).
• Der Client empfängt bestenfalls die Daten und stellt sie dar.
• Die Verbindung zwischen Client und Server wird beendet, es wird kein “Zustand” – keine dauerhafte Verbindung – aufrecht erhalten.

Merke:

• Das HTT-Protokol ist zustandslos (stateless)
• Request: die Anfrage des Browsers an den Webserver
• Response: die Antwort des Webservers auf einen Request

Zunächst klingt diese Verfahrensweise logisch und nicht besonders tragisch, da offensichtlich die angeforderten Daten – wie gewünscht – ihren Weg zum Browser finden. Das Problem für den Programmierer der Webseiten-Logik entsteht erst dann, wenn es nötig wird, den Client von einem Request zum anderem zu identifizieren – d.h. die Requests zu unterscheiden, ob sie vom gleichem Client stammen oder nicht.

Diese Unterscheidung (Authentifizierung) ist schon z.B. bei einer einfachen Warenkorb-Funktion notwendig, damit bestellte Artikel nicht im Warenkorb eines anderen Benutzers landen, der sich zufällig zur gleichen Zeit im gleichem Online-Shop bewegt. Ebenfalls wird diese Unterscheidung notwendig, um ausgewählten Benutzern restriktiven Zugriff auf spezielle Teile einer Website zu erlauben (Authorisierung) z.B. auf Administrationsbereiche oder Bereiche in denen Informationen für einen geschlossenen Benutzerkreis (CUG – closed user group) zur Verfügung stehen.

Eine eindeutige Unterscheidung anhand der IP-Adresse ist – wie es oft landläufig von Neulingen geglaubt wird – nicht möglich bzw. stellt aus der Sicht des Webservers keinen sicheren Weg zu Authentifizierung eines Clients dar, da einerseits mehrere Clients mit der gleichen IP im WWW unterwegs sein können (Masquerading) und andereseits ein Client über mehrere Requests hinweg verschiedene IP-Adressen (Proxies) haben kann. Wie das genau funktioniert ist aber eine andere Geschichte.

Merke:

• Eine IP ist in unserem Kontext nicht eindeutig.
• Authentifizierung: Wiedererkennung eines Benutzers.
• Authorisierung: Überprüfung individueller Zugangsdaten eines wiedererkannten Benutzers und Gewährleistung damit vebundener Rechte.

Die Lösung für das Problem sind sog. Sessions-IDs, eindeutige “Schlüssel”, die bei der HTTP-Kommunkation über den Zeitraum einer Sitzung (engl. Session) auf einer Webseite ihre Gültigkeiten behalten.

Was ist eine Session-ID? Wo werden Sessiondaten gespeichert?

Die Session-ID – es ist eine zufällige Zeichenfolge – wird serverseitig generiert und wird beim allerersten Response des Webservers an den Browser geschickt, der sie dann speichert. Üblicherweise wird eine Session-ID in Cookies abgelegt, da der Browser bei jedem Request automatisch den Inhalt des Cookies an den Webserver schickt der ihn gesetzt hat.

Dies bedeutet, dass sich der Programmierer der serverseitigen Software theoretisch keine Sorgen machen muss, wie die Session-ID vom Browser wieder zurück zum Webserver kommt, da diese Arbeit automatisch vom Browser erledigt wird.

Cookies sind nichts anderes als menschenlesbare Textdateien, in denen ein Webserver spezifische Daten auf der lokalen Platte des Benutzers ablegen kann. Diese Daten sind u.U. recht kryptisch gehalten, so daß meistens nur der Autor der serverseitigen Software – die den Cookie gesetzt hat – weiß, wie diese Cookie-Daten zu interpretieren sind.

Dies ist aber für uns irrelevant und soll uns nicht weiter beschäftigen, denn wir wollen feststellen, daß die Größe des Cookie – per Definition – ca. 4000 Zeichen nicht überschreiten darf (wovon wir ca. 40 Zeichen benötigen), und dass es zwei Arten von Cookies gibt:

• “Persistente Cookies” werden für einen definierten Zeitraum (Gültigkeitsdauer) auf der Festplatte des Benutzers als normal lesbare Textdatei gespeichert. Dieser Zeitraum kann sich von wenigen Minuten bis mehreren Jahren erstrecken.
• Die Lebensdauer der “temporären Session-Cookies” beschränkt sich auf die Lebensdauer des Browser-Fensters. Wird dieses geschlossen, wird auch der temporäre Cookie verworfen. Dieser Cookie wird üblicherweise nicht auf der Festplatte gespeichert; er residiert im Arbeitsspeicher des Rechners.

In der Standardeinstellung benutzt PHP 4 die zweite Variante – die temporären Cookies – um Session-IDs zu speichern. Im Cookie wird der Name der Session und die bereits erwähnte zufällige Zeichenfolge der Session-ID gespeichert. Der Name der Session ist eine frei wählbare Bezeichnung, die uns später als Variable bei der Auswertung der Sessiondaten im PHP-Script zu Verfügung stehen wird. Per Voreinstellung lautet der Name der Variable bei PHP 4: PHPSESSID. Die Länge der von PHP 4 produzierten Session-ID beträgt 32 Zeichen.

Als Ergebnis können wir annehmen, dass bei der Initialisierung einer Session, PHP einen Cookie mit etwa dem folgenden Inhalt beim Benutzer hinterlegt:

PHPSESSID=edb0e8665db4e9042fe0176a89aade16

Der linke Teil des Strings wird als Sessionname und der rechte – die zufällige Zeichenkette “edb0e8665db4e9042fe0176a89aade16″ – als Session-ID bezeichnet.

Diese Session-ID ist der Schlüssel zur Wiedererkennung des Benutzers und zur Restaurierung der von ihm gesetzten Daten. Die Session-ID repräsentiert bei PHP 4 – per Voreinstellung – eine temporäre Datei im Filesystem des Servers. Auf unixoiden Betriebssystemen wird die PHP-Sessiondatei standardmäßig im Verzeichnis /tmp/ erstellt. In der php.ini – der globalen Konfigurationsdatei – oder ein der Webserverkonfiguration läßt sich dieser Wert natürlich verändern.

Diese Session-Datei bekommt im Namen den Prefix sess_, so dass das Ergebnis im Filesystem des Servers folgendermaßen aussehen kann:

goosh@warpcore:~> ls /tmp/ -l
insgesamt 0
-rw------- 1 wwwrun www 0 Apr 17 18:00 sess_edb0e8665db4...

In dieser Datei kann ein PHP-Script Benutzerdaten ablegen – z.B. die Artikelnummer und die Anzahl der bestellten Artikel für einen Warenkorb oder einfach nur ob ein Benutzer sich authorisiert hat und Zugriff auf eine Webseite hat.

Dadurch dass der Browser den Inhalt des Cookies bei einem Request mitschickt, ist es möglich den Benutzer über mehrere Webseiten zu authentifizieren oder die vom Benutzer gesetzten Variablen von einer Seite auf eine andere zu übernehmen.

Die Manipulation dieser Session-Datei bleibt nur dem serverseitig ausgeführtem PHP-Script vorbehalten. Der Client weiß nicht welche Daten von dem Script gespeichert werden und er kann keinen mittelbaren Einfluß auf diese Daten nehmen. Ausnahme bildet hier die Änderung oder Löschung dieser Daten durch den Administrator oder durch ein auf dem Server laufendes Script mit entsprechenden (Datei-)Rechten.

Merke:

• In der Voreinstellung benutzt PHP 4 temporäre Cookies um Session-IDs zu speichern.
• Defaultname der Session ist PHPSESSID.
• Eine mit PHP 4 generierte Session-ID ist 32 Zeichen lang (MD5 digest).
• Sessiondateien werden im Ordner /tmp/ gespeichert.
• Sessiondateien können nur serverseitig geändert werden.