[edit] Last updated: Mon, 01 Nov 2010

CXLVII. Session Funktionen

Einführung

Die Unterstützung von Sessions in PHP bietet die Möglichkeit, bestimmte Daten während einer Folge von Aufrufen Ihrer Website festzuhalten. Damit können Sie persönlichere Applikationen erstellen und Ihre Website ansprechender gestalten.

Einem Besucher wird beim Aufruf Ihrer Website eine eindeutige ID, die sogenannte Session-ID, zugeordnet. Diese wird entweder benutzerseitig in einem Cookie abgelegt oder in der URL übermittelt.

Die Unterstützung von Sessions erlaubt Ihnen, eine beliebige Anzahl von Variablen zu registrieren und diese über Anfragen hinweg zu erhalten. Wenn ein Besucher Ihre Website aufruft, überprüft PHP automatisch (falls session.auto_start auf 1 gesetzt ist) oder auf Anfrage (explizit durch session_start() oder implizit durch session_register()), ob mit der Anfrage schon eine bestimmte Session-ID gesendet wurde. Wenn dies der Fall ist, wird die zuvor gespeicherte Umgebung wiederhergestellt.

Achtung

Falls Sie session.auto_start aktivieren, können Sie keine Objekte in Ihre Session aufnehmen, weil die Definition der Klasse vor dem Start der Session geladen werden muss, damit die Objekte in Ihrer Session wiederhergestellt werden.

Alle registrierten Variablen werden serialisiert, nachdem die Anfrage beendet ist. Registrierte Variablen, die nicht definiert sind, werden als nicht definiert gekennzeichnet. Auch bei darauffolgenden Zugriffen werden sie nicht vom Session-Modul definiert, außer der Benutzer definiert sie später.

Warnung

Einige Datentypen können nicht serialisiert werden, um in Sessions gespeichert zu werden. Dazu gehören resource-Variablen oder Objekte mit Ringreferenzen (d.h. Objekte, die eine Referenz auf sich selbst an andere Objekte übergeben).

Anmerkung: Die Behandlung von Sessions wurde in PHP 4.0 eingeführt.

Anmerkung: Bitte beachten Sie beim Arbeiten mit Sessions, dass der Datensatz einer Session nicht angelegt wird, bevor eine Variable mit der Funktion session_register() registriert oder dem superglobalen Array $_SESSION ein neuer Schlüssel hinzugefügt wird. Das gilt auch dann, wenn eine Session mit der Funktion session_start() gestartet wurde.

Sessions und Sicherheit

Externe Links: » Session fixation

Das Session-Modul bietet keine Garantie dafür, dass Informationen, die Sie in einer Session speichern, nur vom Benutzer gesehen werden können, der die Session erzeugt hat. Sie müssen zusätzliche Maßnahmen ergreifen, um die Integrität der Session ihrer Wichtigkeit entsprechend angemessen aktiv zu schützen.

Schätzen Sie die Wichtigkeit der Daten ab, die in Ihren Sessions transportiert werden und treffen Sie zusätzliche Schutzmaßnahmen -- in der Regel bezahlen Sie dafür mit einer geringeren Benutzerfreundlichkeit. Wenn Sie z.B. Benutzer vor einfachen Social Engineering Tactics (Anm. des Übersetzers: Techniken der Ausnutzung menschlicher Schwächen) schützen wollen, müssen Sie session.use_only_cookies aktivieren. Cookies müssen dann benutzerseitig auf jeden Fall aktiviert sein, weil Sessions sonst nicht funktionieren.

Es gibt mehrere Wege, über die eine Sessio-ID an Dritte gelangen kann. Eine entführte Session-ID ermöglicht diesen, auf alle Daten zuzugreifen, die mit dieser Session-ID verbunden sind. Erstens sind das URLs, die Session-IDs enthalten. Wenn Sie auf eine externe Site verweisen, könnte die URL inklusive Session-ID in den Referrer-Logs der externen Site gespeichert werden. Zweitens kann ein aktiverer Angreifer Ihren Netzwerkverkehr abhören. Falls Ihr Netzwerkverkehr nicht verschlüsselt ist, werden Session-IDs im Klartext über das Netzwerk übertragen. Hier ist die Lösung, auf Ihrem Server SSL zu implementieren und die Verwendung für Ihre Benutzer obligatorisch zu machen.

Anforderungen

Diese Erweiterung benötigt keine externen Bibliotheken.

Anmerkung: Optional können Sie für die Speicherung von Sessions die von Ralf S. Engelschall entwickelte Shared Memory Allocation (mm) verwenden. Sie müssen dazu » mm herunterladen und installieren. Für Windows-Plattformen steht diese Option nicht zur Verfügung. Beachten Sie, dass das Sessionspeicherungs-Modul für mm nicht dafür garantiert, dass gleichzeitige Zugriffe auf die selbe Session richtig gesperrt sind. Die Verwendung eines auf Shared Memory basierenden Dateisystems (wie z.B. tmpfs unter Solaris/Linux oder /dev/md unter BSD) könnte für die Speicherung von Sessions in Dateien geeigneter sein, weil sie entsprechend gesperrt sind. Die Session-Daten werden im Hauptspeicher gespeichert und folglich bei einem Neustart des Webservers gelöscht.

Installation

Die Unterstützung von Sessions ist in PHP standardmäßig aktiviert. Falls Sie Ihr PHP ohne Unterstützung von Sessions bauen wollen, müssen Sie bei der Konfiguration die Option --disable-session angeben. Um für die Speicherung von Sessions die shared memory allocation (mm) zu benutzen, müssen Sie PHP mit der Option --with-mm[=DIR] konfigurieren.

Die Windowsversion von PHP enthält diese Erweiterung. Um diese Funktionen zu verwenden, müssen Sie keine zusätzlichen Erweiterungen aktivieren.

Anmerkung: Standardmäßig werden alle Daten, die zu einer bestimmten Session gehören, in einer Datei gespeichert, die in dem Verzeichnis liegt, das durch die INI Option session.save_path bestimmt ist. Für jede Session wird (unabhängig davon, ob sie überhaupt Daten enthält) eine Datai erzeugt. Das liegt daran, dass eine Session geöffnet wird (eine Datei wird erzeugt), ohne dass jemals Daten in diese Datei geschrieben werden. Beachten Sie, dass es sich bei diesem Verhalten um einen Nebeneffekt der Beschränkungen beim Arbeiten mit dem Dateisystem handelt und dass es mit einer benutzerdefinierten Session-Speicherfunktion (wie z.B. mit einer, die eine Datenbank verwendet) möglich ist, Sessions nicht zu verfolgen, wenn sie keine Daten enthalten.

Laufzeit Konfiguration

Das Verhalten dieser Funktionen wird durch Einstellungen in der php.ini beeinflusst.

Tabelle 243. Session-Konfigurationsoptionen

Bezeichnung	Grundeinstellung	Änderbar	Changelog
session.save_path	""	PHP_INI_ALL
session.name	"PHPSESSID"	PHP_INI_ALL
session.save_handler	"files"	PHP_INI_ALL
session.auto_start	"0"	PHP_INI_ALL
session.gc_probability	"1"	PHP_INI_ALL
session.gc_divisor	"100"	PHP_INI_ALL	Seit PHP 4.3.2 verfügbar.
session.gc_maxlifetime	"1440"	PHP_INI_ALL
session.serialize_handler	"php"	PHP_INI_ALL
session.cookie_lifetime	"0"	PHP_INI_ALL
session.cookie_path	"/"	PHP_INI_ALL
session.cookie_domain	""	PHP_INI_ALL
session.cookie_secure	""	PHP_INI_ALL	Seit PHP 4.0.4 verfügbar.
session.cookie_httponly	""	PHP_INI_ALL	Seit PHP 5.2.0 verfügbar.
session.use_cookies	"1"	PHP_INI_ALL
session.use_only_cookies	"1"	PHP_INI_ALL	Seit PHP 4.3.0 verfügbar.
session.referer_check	""	PHP_INI_ALL
session.entropy_file	""	PHP_INI_ALL
session.entropy_length	"0"	PHP_INI_ALL
session.cache_limiter	"nocache"	PHP_INI_ALL
session.cache_expire	"180"	PHP_INI_ALL
session.use_trans_sid	"0"	PHP_INI_ALL	PHP_INI_ALL in PHP <= 4.2.3. PHP_INI_PERDIR in PHP < 5. Seit PHP 4.0.3 verfügbar.
session.bug_compat_42	"1"	PHP_INI_ALL	Seit PHP 4.3.0 verfügbar.
session.bug_compat_warn	"1"	PHP_INI_ALL	Seit PHP 4.3.0 verfügbar.
session.hash_function	"0"	PHP_INI_ALL	Seit PHP 5.0.0 verfügbar.
session.hash_bits_per_character	"4"	PHP_INI_ALL	Seit PHP 5.0.0 verfügbar.
url_rewriter.tags	"a=href,area=href,frame=src,form=,fieldset="	PHP_INI_ALL	Seit PHP 4.0.4 verfügbar.

Weitere Details und die Definitionen der PHP_INI_*-Konstanten finden Sie im Anhang G, php.ini Einstellungen.

Das Sessionmanagementsystem unterstützt eine Anzahl von Konfigurationsoptionen, die Sie in Ihrer php.ini setzen können. Wir geben Ihnen dazu einen kleinen Überblick.

session.save_handler string

session.save_handler definiert den Namen der Prozedur, die benutzt wird, um die Daten zu speichern und zurückzuholen, die mit der Session in Verbindung stehen. Grundeinstellung files. Bitte beachten Sie, dass einzelne Erweiterungen ihre eigenen save_handler registrieren können. Welche Prozeduren registriert sind, kann auf Basis der jeweiligen Installation mit phpinfo() ermittelt werden. Siehe auch session_set_save_handler().

session.save_path string

session.save_path definiert das Argument, das an die Speicherprozedur übergeben wird. Wenn Sie die standardmäßige files Prozedur wählen, ist das der Pfad, unter dem die Dateien erzeugt werden. Grundeinstellung /tmp. Siehe auch session_save_path().

Für diese Anweisung gibt es ein optionales Argument N, das die Anzahl der Verzeichnisebenen bestimmt, über die Ihre Session-Dateien verteilt werden. Wird sie zum Beispiel auf '5;/tmp' gesetzt, kann das das Anlegen einer Session-Datei und Speicherstelle wie /tmp/4/b/1/e/3/sess_4b1e384ad74619bd212e236e52a5a174If bewirken. Um N verwenden zu können, müssen Sie alle diese Verzeichnisse vorher anlegen. In ext/session gibt es für diesen Zweck ein kleines Shell-Script namens mod_files.sh. Beachten Sie, dass die automatische 'Müllentsorgung' (garbage collection) nicht durchgeführt wird, wenn N verwendet wird und größer 0 ist (für weitere Informationen siehe eine Kopie der php.ini). Achten Sie bei der Verwendung von N außerdem darauf, dass Sie session.save_path zwischen Anführungsstriche setzen, weil der Trenner (;) in der php.ini auch für Kommentare benutzt wird.

Warnung

Wenn Sie ein Verzeichnis gewählt haben, für das jeder Leserechte hat, wie das z.B. bei /tmp (Grundeinstellung) der Fall ist, könnten andere Serverbenutzer mit Hilfe der Dateiliste dieses Verzeichnisses Ihre Sessions entführen.

Anmerkung: Vor PHP 4.3.6 mussten Benutzer von Windows diese Variable ändern, um die Session-Funktionen von PHP nutzen zu können. Es muss ein gültiger Pfad, z.B. c:/temp, angegeben werden.

session.name string

session.name spezifiziert den Namen der Session, der als Cookie-Name verwendet wird. Grundeinstellung PHPSESSID. Siehe auch session_name().

session.auto_start boolean

session.auto_start spezifiziert, ob das Session-Modul zu Beginn einer Anfrage automatisch eine Session startet. Grundeinstellung 0 (deaktiviert).

session.serialize_handler string

session.serialize_handler definiert den Namen der Prozedur, die benutzt wird, um Daten zu serialisieren/deserialisieren. Gegenwärtig werden ein internes PHP-Format (Name php) und WDDX (name wddx) unterstützt. WDDX steht nur zur Verfügung, wenn PHP mit WDDX support kompiliert wurde. Grundeinstellung php.

session.gc_probability integer

session.gc_probability wird in Verbindung mit session.gc_divisor dazu verwendet, die Wahrscheinlichkeit zu regeln, mit der die gc (garbage collection) Routine gestartet wird. Grundeinstellung 1. Siehe auch session.gc_divisor.

session.gc_divisor integer

session.gc_divisor definiert gekoppelt mit session.gc_probability die Wahrscheinlichkeit, mit der die gc (garbage collection) Routine bei jeder Initialisierung einer Session gestartet wird. Die Wahrscheinlichkeit errechnet sich aus gc_probability/gc_divisor. 1/100 bedeutet z.B., dass die GC-Routine bei jeder Anfrage mit einer Wahrscheinlichkeit von 1% gestartet wird. Grundeinstellung 100.

session.gc_maxlifetime integer

session.gc_maxlifetime spezifiziert die Anzahl der Sekunden, nach denen Daten als 'garbage' ('Müll') betrachtet und entsorgt werden. Die Speicherbereinigung wird zu Beginn einer Session durchgeführt.

Anmerkung: Falls sich der Wert von session.gc_maxlifetime in verschiedenen Scripts unterscheidet, aber sie die Sessiondaten an der selben Stelle speichern, löscht das Script mit dem kleinsten Wert die Daten. Verwenden Sie die Anweisung in diesem Fall zusammen mit der Anweisung session.save_path.

Anmerkung: Falls Sie die standardmäßige dateibasierte Session-Prozedur verwenden, muss Ihr Dateisystem die Zugriffszeiten (atime) verfolgen. Windows FAT tut dies nicht. Sie müssen sich daher einen anderen Weg einfallen lassen, um die 'Müllentsorgung' Ihrer Session zu erledigen, wenn Sie an ein FAT-Dateisystem gebunden sind oder an irgendein anderes Dateisystem, das keine atime-Kontrolle bietet. Seit PHP 4.2.3 wird mtime (modified date) anstatt atime verwendet. Sie werden also keine Problem mit Dateisystemen haben, bei denen atime nicht zur Verfügung steht.

session.referer_check string

session.referer_check enthält die Zeichenkette, auf die Sie jeden HTTP-Referer überprüfen wollen. Wenn der Referer vom Client gesendet und die Zeichenkette nicht gefunden wurde, wird die eingebettete Session-ID als ungültig gekennzeichnet. Grundeinstellung ist eine leere Zeichenkette.

session.entropy_file string

session.entropy_file gibt den Pfad zu einer externen Quelle (Datei) an, die bei der Erzeugung einer Session-ID als zusätzliche Entropiequelle verwendet wird. Beispiele sind /dev/random oder /dev/urandom, die auf vielen Unix-Systemen zur Verfügung stehen.

session.entropy_length integer

session.entropy_length spezifiziert die Anzahl der Bytes, die von der oben spezifizierten Datei gelesen werden. Grundeinstellung 0 (deaktiviert).

session.use_cookies boolean

session.use_cookies spezifiziert, ob das Modul Cookies verwendet, um die Session-ID clientseitig zu speichern. Grundeinstellung 1 (aktiviert).

session.use_only_cookies boolean

session.use_only_cookies spezifiziert, ob das Modul nur Cookies verwendet, um die Session-ID clientseitig zu speichern. Mit Aktivierung dieser Einstellung wird möglichen Angriffen durch Übermittlung von Session-IDs in URLs vorgebeugt. Diese Einstellung wurde in PHP 4.3.0 hinzugefügt.

session.cookie_lifetime integer

session.cookie_lifetime spezifiziert die Cookie-Lebensdauer, die an den Browser geschickt wird, in Sekunden. Der Wert 0 bedeutet "bis der Browser geschlossen wird." Grundeinstellung 0. Siehe auch session_get_cookie_params() und session_set_cookie_params(). Da das Cookie vom Browser zurückgegeben wird, wird seine Lebensdauer nicht verlängert. Es muss mittels setcookie() gesendet werden.

session.cookie_path string

session.cookie_path spezifiziert den Pfad, in dem das Session-Cookie gesetzt wird. Grundeinstellung /. Siehe auch session_get_cookie_params() und session_set_cookie_params().

session.cookie_domain string

session.cookie_domain spezifiziert die Domain, unter der das Session-Cookie gesetzt wird. In der Grundeinstellung überhaupt keine, was bedeutet, dass entsprechend der Spezifikation für Cookies der Hostname des Servers verwendet wird, der das Cookie erzeugt hat. Siehe auch session_get_cookie_params() und session_set_cookie_params().

session.cookie_secure boolean

session.cookie_secure spezifiziert, ob Cookies nur über sichere Verbindungen geschickt werden sollen. Grundeinstellung off. Diese Einstellung wurde in PHP 4.0.4 hinzugefügt. Siehe auch session_get_cookie_params() und session_set_cookie_params().

session.cookie_httponly boolean

session.cookie_httponly markiert das Cookie als nur über das HTTP-Protokoll zugänglich. Das bedeutet, dass für Skriptsprachen wie z.B. JavaScript nicht zugänglich ist. Diese Einstellung kann helfen, Identitätsdiebstahl durch XSS-Angriffe zu reduzieren (obwohl es nicht von allen Browsern unterstützt wird).

session.cache_limiter string

session.cache_limiter spezifiziert die Methode der Cacheverwaltung, die bei Session-Seiten benutzt wird (none/nocache/private/private_no_expire/public). Grundeinstellung nocache. Siehe auch session_cache_limiter().

session.cache_expire integer

session.cache_expire spezifiziert in Minuten, wie lange Session-Seiten im Cache bleiben. Bei nocache ist diese Angabe wirkungslos. Grundeinstellung 180. Siehe auch session_cache_expire().

session.use_trans_sid boolean

session.use_trans_sid bestimmt ob transparente SID-Unterstützung aktiviert ist oder nicht. Grundeinstellung 0 (deaktiviert).

Anmerkung: In PHP 4.1.2 oder darunter wird sie durch compilieren mit --enable-trans-sid aktiviert. Ab PHP 4.2.0 ist das Feature trans-sid immer eincompiliert.
URL-basiertes Session-Management hat im Vergleich zu Cookie-basiertem Session-Management zusätzliche Sicherheitsrisiken. Benutzer können zum Beispiel eine URL, die eine aktive Session-ID enthält, per Email an Freunde schicken oder in ihren Bookmarks speichern und immer mit der selben Session-ID auf Ihre Seite zugreifen.

session.bug_compat_42 boolean

Die PHP-Versionen bis 4.2.3 haben eine undokumentierte Funktion/einen undokumentierten Fehler, der es Ihnen gestattet, eine Session-Variable im globalen Bereich zu initialisieren, obwohl register_globals deaktiviert ist. Ab Version 4.3.0 gibt PHP bei Verwendung dieser Funktion eine Warnung aus, wenn zusätzlich session.bug_compat_warn aktiviert ist. Diese Funktion/dieser Fehler kann durch Deaktivieren dieser Einstellung deaktiviert werden.

session.bug_compat_warn boolean

Die PHP-Versionen bis 4.2.3 haben eine undokumentierte Funktion/einen undokumentierten Fehler, der es Ihnen gestattet, eine Session-Variable im globalen Bereich zu initialisieren, obwohl register_globals deaktiviert ist. Ab Version 4.3.0 gibt PHP bei Verwendung dieser Funktion eine Warnung aus, wenn sowohl session.bug_compat_42 als auch session.bug_compat_warn aktiviert sind.

session.hash_function mixed

session.hash_function gibt Ihnen die Möglichkeit, den Prüfsummen-Algorithmus für die Erzeugung von Session-IDs selbst zu bestimmen. '0' bedeutet MD5 (128 Bit) und '1' bedeutet SHA-1 (160 Bit).

Ab PHP 6.0.0 ist es auch möglich, einen der Algorithmen zu bestimmen, die durch die Hash-Erweiterung (falls vorhanden) zur Verfügung stehen, wie z.B. sha512 oder whirlpool. Eine vollständige Liste unterstützter Algorithmen erhalten Sie mit der Funktion hash_algos().

Anmerkung: Dies wurde in PHP 5 eingeführt.

session.hash_bits_per_character integer

session.hash_bits_per_character gibt Ihnen die Möglichkeit, zu definieren wieviele Bit bei der Umwandlung der binären Prüfsummen-Daten in etwas Lesbares in jedem Zeichen gespeichert werden. Mögliche Werte sind '4' (0-9, a-f), '5' (0-9, a-v) und '6' (0-9, a-z, A-Z, "-", ",").

Anmerkung: Dies wurde in PHP 5 eingeführt.

url_rewriter.tags string

url_rewriter.tags bestimmt, wenn Unterstützung für transparente SID aktiviert ist, welche HTML-Tags so umgeschrieben werden, dass sie die Session-ID beinhalten. Grundeinstellung a=href,area=href,frame=src,input=src,form=fakeentry,fieldset=

Anmerkung: Wenn Sie HTML/XHTML strict-Konformität wollen, müssen Sie den form-Eintrag entfernen und Ihre Formularfelder zwischen <fieldset>-Tags setzen.

Die Konfigurationseinstellungen von track_vars und register_globals beeinflussen, wie die Session-Variablen gespeichert und wiederhergestellt werden.

Anmerkung: Seit PHP 4.0.3 ist track_vars immer aktiviert.

Resource Typen

Diese Erweiterung definiert keine Resource-Typen.

Vordefinierte Konstanten

Folgende Konstanten werden von dieser Erweiterung definiert und stehen nur zur Verfügung, wenn die Erweiterung entweder statisch in PHP kompiliert oder dynamisch zur Laufzeit geladen wurde.

SID (string): Konstante, die entweder den Namen und die ID der Session in der Form "name=ID" enthält oder eine leere Zeichenkette, falls die Session-ID in einem entsprechenden Cookie gesetzt wurde.

Beispiele

Anmerkung: Seit PHP 4.1.0 steht $_SESSION genau wie $_POST, $_GET, $_REQUEST und so weiter, als globale Variable zur Verfügung. Im Gegensatz zu $HTTP_SESSION_VARS ist $_SESSION immer global. Deshalb brauchen Sie für $_SESSION nicht das Schlüsselwort global zu verwenden. Bitte beachten Sie, dass in dieser Dokumentation nun überall $_SESSION verwendet wird. Sie können $_SESSION durch $HTTP_SESSION_VARS ersetzen, wenn Sie Letzteres bevorzugen. Beachten Sie auch, dass Sie Ihre Session mit session_start() starten müssen, bevor die Verwendung von $_SESSION zur Verfügung steht.
Für die Schlüssel des assoziativen $_SESSION-Arrays gelten die selben Beschränkungen, wie für die Bezeichnungen von regulären Variablen in PHP, d.h. sie dürfen nicht mit einer Zahl, sondern müssen mit einem Buchstaben oder Unterstrich beginnen. Um weitere Deteils zu erhalten, siehe Abschnitt Variablen.

Falls register_globals deaktiviert ist, können nur Bestandteile des globalen assoziativen Arrays $_SESSION als Session-Variablen registriert werden. Wiederhergestellte Session-Variablen stehen nur im Array $_SESSION zur Verfügung.

Aus Gründen der Verbesserung der Sicherheit und der Lesbarkeit des Codes wird die Verwendung von $_SESSION (oder $HTTP_SESSION_VARS bei PHP 4.0.6 oder niedriger) empfohlen. Mit $_SESSION werden die Funktionen session_register(), session_unregister() und session_is_registered() nicht benötigt. Auf die Session-Variablen kann wie auf jede normale Variable zugegriffen werden.

Beispiel 1891. Registrierung einer Variablen mit $_SESSION.


<?php

session_start();

// Verwenden Sie bei PHP 4.0.6 oder niedriger $HTTP_SESSION_VARS

if (!isset($_SESSION['zaehler'])) {

    $_SESSION['zaehler'] = 0;

} else {

    $_SESSION['zaehler']++;

}

?>

Beispiel 1892. Aufheben der Registrierung einer Variablen mit $_SESSION und deaktiviertem register_globals.


<?php

session_start();

// Verwenden Sie bei PHP 4.0.6 oder niedriger $HTTP_SESSION_VARS

unset($_SESSION['zaehler']);

?>

Achtung

Heben Sie NICHT die Registrierung der gesamten $_SESSION mit unset($_SESSION) auf, weil dies die Registrierung von Variablen durch die Superglobale $_SESSION deaktivieren würde.

Warnung

Sie können in Session-Variablen keine Referenzen verwenden, weil es keine praktikable Möglichkeit gibt, eine Referenz in eine andere Variable zurückzuführen.

Wenn register_globals aktiviert ist, kann jede globalen Variable als Session-Variable registriert werden. Beim Neustart einer Session werden diese Variablen als entsprechende globale Variablen wiederhergestellt. Da PHP wissen muss, welche globalen Variablen als Session-Variablen registriert sind, muss der Benutzer Variablen mit der Funktion session_register() registrieren. Sie können das vermeiden, indem Sie einfach Einträge in $_SESSION setzen.

Achtung

Verwenden Sie nicht session_register(), session_is_registered() und session_unregister(), wenn Sie $_SESSION vor PHP 4.3 verwenden und register_globals deaktiviert ist. Es ist sowohl aus Sicherheitsgründen als auch wegen der Performance empfehlenswert, register_globals zu deaktivieren.

Wenn register_globals aktiviert ist, dann referenzieren die globalen Variablen und die Einträge von $_SESSION automatisch die selben Werte, die in der vorherigen Instanz der Session registriert wurden. Falls die Variable mittels $_SESSION registriert wird, steht die globale Variable allerdings erst ab der nächsten Anfrage zur Verfügung.

Es gibt einen Fehler in PHP 4.2.3 und früheren Versionen. Wenn Sie eine neue Session-Variable mittels session_register() registrieren, referenzieren der Eintrag im globalen Bereich und der $_SESSION-Eintrag bis zum nächsten session_start() nicht den selben Wert. D.h. eine Änderung an der neu registrierten globalen Variablen wird nicht vom $_SESSION-Eintrag widergespiegelt. Dies wurde in PHP 4.3 korrigiert.

Übermittlung der Session-ID

Es gibt zwei Methoden, eine Session-ID zu übermitteln:

Cookies
URL Parameter

Das Session-Modul unterstützt beide Methoden. Cookies sind optimal, aber da sie nicht immer zur Verfügung stehen, bieten wir auch noch eine Alternative an. Die zweite Methode hängt die Session-ID direkt an die URLs.

PHP ist in der Lage, Links transparent umzuwandeln. Falls Sie nicht PHP 4.2 oder höher verwenden, müssen Sie das beim Übersetzen von PHP manuell aktivieren. Unter Unix müssen Sie dazu configure mit --enable-trans-sid aufrufen. Wenn diese Option und die Laufzeit-Option session.use_trans_sid aktiviert sind, werden relative URIs automatisch so geändert, dass sie die Session-ID enthalten.

Anmerkung: Die php.ini-Anweisung arg_separator.output ermöglicht es, die Trennung von Argumenten anzupassen. Geben Sie dort für volle XHTML-Konformität & an.

Alternativ können Sie die Konstante SID verwenden, die definiert ist, nachdem die Session gestartet wurde. Falls der Client kein geeignetes Session-Cookie gesendet hat, hat sie die Form session_name=session_id. Andernfalls wird sie zu einer leeren Zeichenkette erweitert. Aus diesem Grund können Sie sie bedingungslos in URLs einbetten.

Das folgende Beispiel demonstriert, wie eine Variable registriert wird und wie unter Verwendung einer SID korrekt auf eine andere Seite verwiesen wird.

Beispiel 1893. Zählen der Seitenaufrufe eines einzelnen Benutzers


<?php

if (!session_is_registered('zaehler')) {

    session_register('zaehler');

    $zaehler = 1;

} else {

    $zaehler++;

}

?>



<p>

Hallo Besucher, Sie haben diese Seite <?php echo $zaehler; ?> Mal aufgerufen.

</p>



<p>

Hier gehts <A HREF="nextpage.php?<?php echo strip_tags(SID)?>">weiter</A>

</p>

Die Funktion strip_tags() wird verwendet, um bei der Ausgabe der SID XSS-ähnliche Angriffe zu verhindern.

Die oben gezeigte Ausgabe der SID ist nicht nötig, wenn PHP mit --enable-trans-sid übersetzt wurde.

Anmerkung: Bei nichtrelativen URLs wird davon ausgegangen, dass sie auf externe Seiten zeigen und deshalb keine SID angehängt, weil es ein Sicherheitsrisiko wäre, die SID an einen anderen Server zu übermitteln.

Wenn Sie die Speicherung in einer Datenbank oder irgendeine andere Art der Speicherung realisieren wollen, können Sie session_set_save_handler() verwenden, um eine Reihe von benutzerdefinierten Speicherfunktionen zu erzeugen.

Inhaltsverzeichnis

session_cache_expire — Liefert die aktuelle Cache-Verfallszeit
session_cache_limiter — Liefert und/oder setzt die aktuelle Cacheverwaltung
session_commit — Alias von session_write_close()
session_decode — Dekodiert die Daten einer Session aus einer Zeichenkette
session_destroy — Löscht alle in einer Session registrierten Daten
session_encode — Kodiert die Daten der aktuellen Session als Zeichenkette
session_get_cookie_params — Liefert die Session-Cookie Parameter
session_id — Liefert und/oder setzt die aktuelle Session-ID
session_is_registered — Überprüft, ob eine globale Variable in einer Session registriert ist
session_module_name — Liefert und/oder setzt das aktuelle Session-Modul
session_name — Liefert und/oder setzt den Namen der aktuellen Session
session_regenerate_id — Ersetzt die aktuelle Session-ID durch eine neu erzeugte
session_register — Registriert eine oder mehrere globale Variablen in der aktuellen Session
session_save_path — Liefert und/oder setzt den aktuellen Speicherpfad der Session
session_set_cookie_params — Setzt die Session-Cookie Parameter
session_set_save_handler — Setzt benutzerdefinierte Session-Speicherfunktionen
session_start — Initialisiert eine Session
session_unregister — Hebt die Registrierung einer globalen Variablen in der aktuellen Session auf
session_unset — Löscht alle Session-Variablen
session_write_close — Speichert die Session-Daten und beendet die Session

session_cache_expire

session_pgsql_status

[edit] Last updated: Mon, 01 Nov 2010

add a note User Contributed Notes Session Funktionen

Sam Yong - hellclanner at live dot com 27-Jul-2011 02:01


The following has been tested true in PHP 5.3.5.



Setting the session variables after the execution of the script i.e. in __destruct function, will not work. 



<?php



class Example{



    function __destruct(){

        $_SESSION['test'] = true;

        session_write_close();

    }



}



?>



The above example will write nothing into the temporary session file, as I observed through a custom Session Save Handler.

jitchavan at gmail dot com 01-Apr-2011 06:43


IE issue :-



when form target set to iframe source and after posting form content you are setting session variables,

In this scenario if parent page having image src blank then session values set in iframe action page will be LOST surprisingly in IE ONLY.Solution is quite simple don't keep Image src blank.

ted at tedmurph dot com 07-Oct-2010 05:34


I was having problems with $_SESSION information not being written or being lost in a seemingly random way.  There was a Location: call being made deep in a Zend OAuth module, I am using an IIS server with PHP as a CGI, etc.





The answer was simply that you need to have the domain be consistent for sessions to work consistently.  In my case, I was switching back and forth between www.EXAMPLE.com:888 and EXAMPLE.com:888.  The unusual port, the hidden Location: call, the handoff with OAuth, etc all served to confuse me, but the intermitent error was caused by this simple goof of keeping the domain consistent.

hinom06 [at] hotmail.co.jp 29-Aug-2010 10:28


simple session test version 1.1



<?php 

/* [EDIT by danbrown AT php DOT net: 

   The author of this note named this 

   file tmp.php in his/her tests. If 

   you save it as a different name, 

   simply update the links at the 

   bottom to reflect the change.] */ 



error_reporting( E_ALL ); 

ini_set( 'display_errors', 1);

date_default_timezone_set('Asia/Tokyo');



//ini_set( 'session.save_path', '/tmp' ); // for debug purposes

   

session_start(); 



// check if session_id() exists.

/*

for example, if exists and session wont read, must send session.name as parameter in URL.



Some servers configurations may have problem to recognize PHPSESSID, even if transid value is 0 or 1.  

So, this test is usefull to identify any causes.



*/

if( session_id() == '' )

{

    echo 'session_id() empty';

}else{

    echo session_id();

}

echo '<hr>';



$sessPath   = ini_get('session.save_path'); 

$sessCookie = ini_get('session.cookie_path'); 

$sessName   = ini_get('session.name'); 

$sessVar    = 'foo'; 



echo '<br>sessPath: ' . $sessPath; 

echo '<br>sessCookie: ' . $sessCookie; 



echo '<hr>'; 



if( !isset( $_GET['p'] ) ){ 

    // instantiate new session var 

    $_SESSION[$sessVar] = 'hello world'; 

}else{ 

    if( $_GET['p'] == 1 ){ 



        // printing session value and global cookie PHPSESSID 

        echo $sessVar . ': '; 

        if( isset( $_SESSION[$sessVar] ) ){ 

            echo $_SESSION[$sessVar]; 

        }else{ 

            echo '[not exists]'; 

        } 



        echo '<br>' . $sessName . ': '; 



        if( isset( $_COOKIE[$sessName] ) ){ 

        echo $_COOKIE[$sessName]; 

        }else{ 

            if( isset( $_REQUEST[$sessName] ) ){ 

            echo $_REQUEST[$sessName]; 

            }else{ 

                if( isset( $_SERVER['HTTP_COOKIE'] ) ){ 

                echo $_SERVER['HTTP_COOKIE']; 

                }else{ 

                echo 'problem, check your PHP settings'; 

                } 

            } 

        } 



    }else{ 



        // destroy session by unset() function 

        unset( $_SESSION[$sessVar] ); 



        // check if was destroyed 

        if( !isset( $_SESSION[$sessVar] ) ){ 

            echo '<br>'; 

            echo $sessName . ' was "unseted"'; 

        }else{ 

            echo '<br>'; 

            echo $sessName . ' was not "unseted"'; 

        } 



    } 

} 

?> 

<hr> 

<a href=tmp.php?p=1&<?php echo $sessName . '=' . session_id();?>>test 1 (printing session value)</a> 

<br> 

<a href=tmp.php?p=2&<?php echo $sessName . '=' . session_id();?>>test 2 (kill session)</a>

Trevor Brown 04-Aug-2010 08:17


A confirmation of behaviour, just in case this saves anyone else some time...



There is (potentially) a special case when session.gc_probability = 0 and session.gc_divisor = 0.  Depending on how they wanted to work their maths underneath, the coders *might* have opted to interpret 0/0 as 1 (which is sometimes assumed in certain maths proofs), but thankfully it seems they haven't.  With both values set to 0, the session code will follow the spirit of the directives and invoke the garbage collector with zero probability.  At least this is true with php 5.2.5 (which, to be certain, I inspected the source of).



To be safe, however, setting both to zero is *probably* not a good idea because usually 0/0 is undefined, so it could presumably mean anything (some arguments exist that claim 0/0 is equal to every fraction).  Wouldn't you rather know for sure what your probability was set to?  In other words, don't set gc_divisor = 0

Jeremy Speer 19-Feb-2010 12:14


When working on a project, I found a need to switch live sessions between two different pieces of software. The documentation to do this is scattered all around different sites, especially in comments sections rather than examples. One difficulty I encountered was the session save handler for one of the applications was set, whereas the other was not. Now, I didn't code in the function session_set_save_handler(), instead I utilize that once I'm done with the function (manually), however this function could easily be extended to include that functionality. Basically, it is only overriding the system's default session save handler. To overcome this after you have used getSessionData(), just call session_write_close(), session_set_save_handler() with the appropriate values, then re-run session_name(), session_id() and session_start() with their appropriate values. If you don't know the session id, it's the string located in $_COOKIE[session_name], or $_REQUEST[session_name] if you are using trans_sid. [note: use caution with trusting data from $_REQUEST, if at all possible, use $_GET or $_POST instead depending on the page].



<?php

function getSessionData ($session_name = 'PHPSESSID', $session_save_handler = 'files') {

    $session_data = array();

    # did we get told what the old session id was? we can't continue it without that info

    if (array_key_exists($session_name, $_COOKIE)) {

        # save current session id

        $session_id = $_COOKIE[$session_name];

        $old_session_id = session_id();

        

        # write and close current session

        session_write_close();

        

        # grab old save handler, and switch to files

        $old_session_save_handler = ini_get('session.save_handler');

        ini_set('session.save_handler', $session_save_handler);

        

        # now we can switch the session over, capturing the old session name

        $old_session_name = session_name($session_name);

        session_id($session_id);

        session_start();

        

        # get the desired session data

        $session_data = $_SESSION;

        

        # close this session, switch back to the original handler, then restart the old session

        session_write_close();

        ini_set('session.save_handler', $old_session_save_handler);

        session_name($old_session_name);

        session_id($old_session_id);

        session_start();

    }

    

    # now return the data we just retrieved

    return $session_data;

}

?>

brfelipe08 at hotmail dot com 28-Aug-2009 06:26


If you need to use sessions, and some accents required for some Latin-based languages, you should encode your files in ISO-8859-1.

You will run into some problems if you try to use UTF-8 - with or without BOM -, and ANSI will not support accents.

ISO-8859-1 will both support sessions and the accents.

edA-qa at disemia dot com 08-May-2009 12:18


WARNING for Debian users.  Just to drive you completely crazy Debian does its own form of session management and will completely ignore all alterations to the values who do within your PHP script.



Debian sets up a <crontab /etc/cron.d/php5> which deletes all files, including those in subdirectories, which exceed the gc_maxlifetime specified in the <php.ini> file only.



That is, on Debian (and likely variants like Ubuntu) modifying the session expiration settings (like gc_maxlifetime) does *NOTHING*.  You *HAVE* to modify the global <php.ini>.  Not even a <.htaccess> file will help you.

edA-qa at disemia dot com 07-May-2009 05:14


Sessions may be deleted before the time limit you set in gc_maxlifetime. 



If you have multiple pages on the same server, each using the session (the same or distinct named sessions, it doesn't matter), the *minimum* gc_maxlifetime of any of those scripts ends up being the effective lifetime of the session files.



This can also apply to the lifetime coming from a CLI invocation of a PHP script on that machine which happens to use the session.



This can be bothersome since even though you think all your pages include the same file which sets up the script, even a single PHP page which doesn't can invoke the GC and have the scripts deleted.



Thus, if you need to set a long gc_maxlifetime you are best doing this through the INI file or in a .htaccess file for the entire directory.

LaurentT 03-Dec-2008 02:51


For UNIX :





One might encounter some problems with sessions, having different sites on the same server : sessions would either merge if one is using more than one site at a time or crash if sites are owned by different system users. For instance :





www.example.com is stored in /home/site1/www


www.example.net is stored in /home/site2/www





Using both www.example.com and www.example.net would cause sessions to act weird.





If you're using PHP as an Apache module, you can easely use php_value in the http.conf to set a unique session.name depending on the site. If you're using suPHP though (PHP as CGI) you can't use php_value, though you can use suPHP_ConfigPath.





Here's an example : 





<VirtualHost 10.10.10.10:8081>


    DocumentRoot /home/site1/www


    ServerName www.example.com


    suPHP_ConfigPath /home/site1/server_config


</VirtualHost>


<VirtualHost 10.10.10.10:8082>


    DocumentRoot /home/site2/www


    ServerName www.example.net


    suPHP_ConfigPath /home/site2/server_config


</VirtualHost>





Each server_config folder contain a php.ini file specific to the vHost. You then just have to change the values of each session.name to unique ones and you're done !

hinom - iMasters 04-Jun-2008 09:00


simple session test





<?php


/* [EDIT by danbrown AT php DOT net:


   The author of this note named this


   file tmp.php in his/her tests. If


   you save it as a different name,


   simply update the links at the


   bottom to reflect the change.] */





session_start();





$sessPath   = ini_get('session.save_path');


$sessCookie = ini_get('session.cookie_path');


$sessName   = ini_get('session.name');


$sessVar    = 'foo';





echo '<br>sessPath: ' . $sessPath;


echo '<br>sessCookie: ' . $sessCookie;





echo '<hr>';





if( !isset( $_GET['p'] ) ){


    // instantiate new session var


    $_SESSION[$sessVar] = 'hello world';


}else{


    if( $_GET['p'] == 1 ){





        // printing session value and global cookie PHPSESSID


        echo $sessVar . ': ';


        if( isset( $_SESSION[$sessVar] ) ){


            echo $_SESSION[$sessVar];


        }else{


            echo '[not exists]';


        }





        echo '<br>' . $sessName . ': ';





        if( isset( $_COOKIE[$sessName] ) ){


        echo $_COOKIE[$sessName];


        }else{


            if( isset( $_REQUEST[$sessName] ) ){


            echo $_REQUEST[$sessName];


            }else{


                if( isset( $_SERVER['HTTP_COOKIE'] ) ){


                echo $_SERVER['HTTP_COOKIE'];


                }else{


                echo 'problem, check your PHP settings';


                }


            }


        }





    }else{





        // destroy session by unset() function


        unset( $_SESSION[$sessVar] );





        // check if was destroyed


        if( !isset( $_SESSION[$sessVar] ) ){


            echo '<br>';


            echo $sessName . ' was "unseted"';


        }else{


            echo '<br>';


            echo $sessName . ' was not "unseted"';


        }





    }


}


?>


<hr>


<a href=tmp.php?p=1>test 1 (printing session value)</a>


<br>


<a href=tmp.php?p=2>test 2 (kill session)</a>

paul at shirron dot net 05-May-2008 07:19


In php.ini, I have:



session.save_path="C:\DOCUME~1\pjs9486\LOCALS~1\Temp\php\session"



I was cleaning out the temp directory, and deleted the php directory. Session stuff quit working. I re-created the php directory. Still no luck. I re-created the session directory in the php directory, and session stuff resumed working.



I would have expected session_start() to have re-created directories in the path, if they didn't exist, but, it doesn't.



Note to self: Don't do that again!!!!

Vextor 04-Apr-2008 08:24


It seems that the garbage engine can't delete the expired session related to the itself. If there is only one session, it won't expire even if it has expired the gc_maxlifetime set.



It will be necessary another client connecting, starting a different session, and the garbage collector of this new session will be able to clean the other expired sessions.



I tested this in Windows with file sessions.

session a emailaddress d cjb d net 28-Mar-2008 11:33


It doesn't appear in the documentation, or in anyone's comment here, but setting session.gc_maxlifetime to 0 means the session will not expire until the browser is closed.



Of course this still doesn't fix the problems associated with the garbage collector doing it's own thing.

The best solution to that still appears to be changing session.save_path

Csar 07-Mar-2008 07:38


There's a bug in Internet explorer in which sessions do not work if the name of the server is not a valid name. For example...if your server is called web_server (_ isn't a valid character), if you call a page which uses sessions like http://web_server/example.php your sessions won't work but sessions will work if you call the script like this


[IP NUMBER]/example.php

Niko 24-Feb-2008 02:07


to anonymousleaf at gmail dot com:



you can get the same result by using this much simplier function call:



<?php

session_start();

session_regenerate_id();

?>

at the top of the file.

Anonymous 18-Dec-2007 11:10


Hey people,



   This caused a minimal amount of discomfort, but however was quickly solved when I peeked in the php.ini and saw that the entire 'session.save_path' was commented out!  This must have been from the version change from 5.0 to 5.2, and sessions naturally began to work correctly when I removed the comment token and filled in the value like so (using Apache):



session.save_path = "c:\Windows\Temp"



Maybe this will serve as a starting point and save some time for some of you out there who start from a fresh php.ini.



--Matthew

carl /a/ suchideas /o/ com 30-Sep-2007 09:45


Another gotcha to add to this list is that using a relative session.save_path is a VERY BAD idea.



You can just about pull it off, if you're very careful, but note two related points:



1) The path is taken relative to the directory of the ORIGINALLY executed script, so unless all pages are run from the same directory, you'll have to set the directory separately in each individual subfolder



2) If you call certain functions, such as session_regenerate_id(), PHP will try to take the session directory relative to the exectuable, or something like that, creating an error IN the executable. This provides slightly cryptic error messages, like this:



Warning: Unknown: open(relative_path\ilti9oq3j9ks0jvih1fmiq4sv1.session, O_RDWR) failed: No such file or directory (2) in Unknown on line 0



Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (relative_path) in Unknown on line 0



... so don't even bother. Just use



<?php ini_set("session.save_path",dirname(__FILE__)."/relative_path"); ?>



(or equivalent) in a file which you know is always in the same place relative to the file.



{PHP version 5.1.6}

jsnell at e-normous dot com 29-Aug-2007 01:58


Careful not to try to use integer as a key to the $_SESSION array (such as $_SESSION[0] = 1;)  or you will get the error "Notice: Unknown: Skipping numeric key 0. in Unknown on line 0"

Nigel Barlass 28-Jun-2007 06:07


Lima's note on sessions and browser's tabs needs to be modified for my version of php as the call to uniqid('') will return an alphanumeric string.

Hence the ereg statement should be:

if(!ereg('^SESS[0-9a-z]+$',$_REQUEST['SESSION_NAME'])) {...

legolas558 d0t users dot sf dot net 01-May-2007 08:45


To clear out a possible doubt of other readers which have read this part of "Eric dot Deplagne at nerim dot net" note:



--------

In fact, two other variables (at least) play a role in session duration, and will explain that the session might last more than expected. The gc erasing your data is a probabilistic thing. Each time a session is opened, the probability the gc is started is session.gc_probability/session.gc_divisor. session.gc_probability defaults to 1 and session.gc_divisor defaults to 100, which makes a 1% probability.



This is to have sessions long enough. I'm unsure about having sessions lasting exactly the time we want them to.

--------



The gc erasing of the sessions is NOT a probabilistic thing, they are erased ONLY when they are older than the number of seconds specified in "session.gc_maxlifetime" ini setting.



The probabilistic fact is that old sessions will not be erased if the garbage collector is not run frenquently enough, but anyway it is your choice to have a higher or lower "session.gc_probability" on "session.gc_divisor" ratio.



So, talking from the server side point of view, a session can last more than the specified amount of time but not less. And if the client respects the cookies duration (in case of cookie-based sessions) those invalid sessions will not last more than expected.



You finally might want to add a timestamp inside the session and validate its age through it to radically solve the problem, if necessary. Example:



<?php



session_start();



if (!isset($_SESSION['generated']))

    $_SESSION['generated'] = time();

else { // if the session is not allowed to live more, regenerate it

    if (time() - $_SESSION['generated'] > ini_get('session.gc_maxlifetime'))

        $_SESSION = array('generated' => time());

}

?>

g_s_b 27-Apr-2007 08:37


If you try to use your own session handling functions (eg. for saving session data to DB) make sure session.auto_start directive is 0.



The manual warns about not being able to put objects in your sessions with auto_start=1: I guess that for the same reason your customized handling functions are ignored is sessions start automatically.



Hope this saves somebody a few minutes.

skysama at googles_mail dot com 17-Apr-2007 11:56


If your session are not retrieving correctly make sure that session.cookie_secure is to set to 'Off' if you are NOT going through https. Everytime you navigate the site your session data will not be retrieved and your sessionid will change. It may be obvious but I spent two days trying to figuring this out. Hope it helps someone.

Edemilson Lima <pulstar at gmail dot com> 17-Apr-2007 06:17


Sessions and browser's tabs





May you have noticed when you open your website in two or more tabs in Firefox, Opera, IE 7.0 or use 'Control+N' in IE 6.0 to open a new window, it is using the same cookie or is passing the same session id, so the another tab is just a copy of the previous tab. What you do in one will affect the another and vice-versa. Even if you open Firefox again, it will use the same cookie of the previous session. But that is not what you need mostly of time, specially when you want to copy information from one place to another in your web application. This occurs because the default session name is "PHPSESSID" and all tabs will use it. There is a workaround and it rely only on changing the session's name.





Put these lines in the top of your main script (the script that call the subscripts) or on top of each script you have:





<?php


if(version_compare(phpversion(),'4.3.0')>=0) {


    if(!ereg('^SESS[0-9]+$',$_REQUEST['SESSION_NAME'])) {


        $_REQUEST['SESSION_NAME']='SESS'.uniqid('');


    }


    output_add_rewrite_var('SESSION_NAME',$_REQUEST['SESSION_NAME']);


    session_name($_REQUEST['SESSION_NAME']);


}


?>





How it works: 





First we compare if the PHP version is at least 4.3.0 (the function output_add_rewrite_var() is not available before this release). 





After we check if the SESSION_NAME element in $_REQUEST array is a valid string in the format "SESSIONxxxxx", where xxxxx is an unique id, generated by the script. If SESSION_NAME is not valid (ie. not set yet), we set a value to it. 





uniqid('') will generate an unique id for a new session name. It don't need to be too strong like uniqid(rand(),TRUE), because all security rely in the session id, not in the session name. We only need here a different id for each session we open. Even getmypid() is enough to be used for this, but I don't know if this may post a treat to the web server. I don't think so.





output_add_rewrite_var() will add automatically a pair of 'SESSION_NAME=SESSxxxxx' to each link and web form in your website. But to work properly, you will need to add it manually to any header('location') and Javascript code you have, like this:





<?php


header('location: script.php?'.session_name().'='.session_id()


      . '&SESSION_NAME='.session_name());


?>


<input type="image" src="button.gif" onClick="javascript:open_popup('script.php?<?php 


echo session_name(); ?>=<?php echo session_id(); ?>&SESSION_NAME=<?php echo session_name(); ?>')" />





The last function, session_name() will define the name of the actual session that the script will use. 





So, every link, form, header() and Javascript code will forward the SESSION_NAME value to the next script and it will know which is the session it must use. If none is given, it will generate a new one (and so, create a new session to a new tab).





May you are asking why not use a cookie to pass the SESSION_NAME along with the session id instead. Well, the problem with cookie is that all tabs will share the same cookie to do it, and the sessions will mix anyway. Cookies will work partially if you set them in different paths and each cookie will be available in their own directories. But this will not make sessions in each tab completly separated from each other. Passing the session name through URL via GET and POST is the best way, I think.

Marcin Wiazowski 03-Apr-2007 01:11


'session.cookie_domain' should be set to empty string for all local domain names, not only for 'localhost' (but should not be empty for local IP addresses):



<?php

ini_set('session.cookie_domain', (strpos($_SERVER['HTTP_HOST'],'.') !== false) ? $_SERVER['HTTP_HOST'] : '');

?>

Marce! 22-Dec-2006 12:20


Be careful when using use_trans_sid and javascript together. When adding a form dynamically with javascript, you usually need to put it in quotes and use addslashes() for your html code.

This will nicely put slashes into the code for your form and the javascript will work perfectly. Or so you would think. PHP does recognise the form, even with the slashes added. So it will neatly insert a hidden variable to your form, with the name of your session variable and the value of the session ID. This hidden variable isn't slashed though, and it may break your javascript code.



The only solution I came up with, is to manually add the hidden variable, before applying the addslashes() function. It will then be shown correctly, and PHP will not insert the hidden value. Of course you may get both a cookie and the variable, depending on your settings, but it does work.

robin at amiance dot com 26-Nov-2006 10:19


If you want the simplest way there is to log a session out after 30 minutes (or any other period of inactivity) simply add a second line after session_start(), like this:





<?php


session_start();


setcookie("PHPSESSID",$_COOKIE['PHPSESSID'],time()+1800);


?>





Where 1800 is the time in seconds before the session should expire. PHPSESSID is the default session ID. This way, every time a user loads a page they get their session extended.

nhap24 09-Sep-2006 05:03


I spent about 8 hours debugging a problem with sessions and redirecting, and I finally found the problem, which after looking back, should have been the first thing I tried.



I use sessions to prevent hotlinking, so if someone hotlinks my file, I will redirect them to a different page by re-writing the header information.  When I redirected, I sent path information in the GET data about the file they were trying to access.  Long story short, when I redirected with a forward-slash "/" AFTER the .php, the page would create a different session ID than the rest of my domain was using.  This happened despite the fact that the cookie path was set to "/" (which should have captured any path on my domain).  



The issue was even harder to figure out, because the page with the wrong session ID was NOT creating a second cookie.  The only cookie was the one with the proper ID, but the broken page did not use this cookie (where then, did it get this ID from?).



To fix the problem, I simply removed the forward-slash from the GET data (base64_encoding works nicely).



I imagine this is an issue with my browser parsing the url, but I tried both Opera and Firefox (IE doesn't load anymore :/) and both browsers showed the same problem.



I looked into hidden header data, failure to write the cookie, trans_ses_id (even though it was set to false), HTTP_HOST, everything, but in the end it was just a stupid forward-slash that had done me in.

greenthumb at 4point-webdesign dot de 01-Sep-2006 11:56


Similar to the use of captcha images you can easely track and advise user who don't accept cookies, especially no session cookies without redirecting them.



so here's the deal:



if the main script (which outputs the html) doesn't have a value in it's session which says that a session is running successfully a different value is saved in the session and an image is included in the html which checks wether the session-check value is set or not. 



If it's set the image-script sets a confirming value which will verify the session to be running correctly and output a transparent 1*1px gif.



If the value is not set the image outputs an advising image which tells to allow cookies.



You can also wrap the image with a link who refers the user  to a page addressing the cookie issue. If the 1px trans is generated the user will hardly find the link, but if the error-image is generated he will surely be able to click it.



pros: 

- works

- no rerouting, you can see the result on the first page opened by the user

- no javascript



cons: 

- bad accessebility (if you give the image an alt-text any blind user will read it at least on the first call, but you cold also write this into the alt text... so maybe there are no cons)



i hope this'll help

rehevkor5 at fastmail dot fm 25-May-2006 11:34


If you have a value specified for session.referer_check you may run into difficulty when someone accesses your site and attempts to log in with a mis-capitalized URL.  The logon will fail because any calls to session_start() will result in the existing session being trashed and a new one being created.  This becomes a bigger problem when the logon is followed by a header("Location: ...") redirect, because the session_start() at the top of the page will fail.





Because session_start() always returns true, it's not obvious how to detect when the referer check fails.  To detect it, I have come up with a method which compares the intended session id with the session id after session_start() is run.  If they are different, the user is redirected to the proper location.  This example uses a technique to avoid session id fixation, as well.





<?php


ini_set('session.referer_check', 'www.yourdomain.edu/ltr/');


ini_set('session.use_only_cookies', 1);


session_name('yourapp'.str_replace('.', '', $_SERVER['REMOTE_ADDR']));


session_start();


if($_GET['badreferer'])


    echo 'You tried accessing the site with a bad URL. Try logging on again.';


if(isUserAuthed($name, $pass))


{


    $old_sessid = session_id(); //save current session id so we can delete it later


    if( !session_regenerate_id() ) //get a new session id (must do this before destroying the old session)


        die("Couldn't regenerate your session id.");


                


    $new_sessid = session_id(); //save new session id so we can get back to it


                


    session_id($old_sessid);


    unset($old_sessid);


    session_destroy(); //destroy the session they got before they logged in


                


    session_id($new_sessid);


    session_start(); //start the new session


                


    $_SESSION = array(); //not really necessary any more, but still a good idea


                


    if(session_id() != $new_sessid)


    {


        /*If this is true, then the session_start() failed to work properly. If session_start() failed to work properly, the most likely cause is that the referer url is different from that set in fuxebox.ini on session.referer_check. The most common cause of this is URL capitalization problems. Therefore, we relocate them to the proper URL, and set a flag to display an error because we can't use pushError() if the session isn't valid. */


                    


        $good_url = ini_get('session.referer_check');


        header('Location: http://'.$good_url.'?badreferer=1');


        exit;


    } else {


        unset($new_sessid);


        //Set session variables here


        $_SESSION['isloggedin'] = 1;


        


        echo 'You have been logged in.';


    }





}


?>

php AT coryforsyth [removeme] d0t com 08-May-2006 07:14


I just finished a marathon debugging session with sessions, and I wanted to share what I learned with the rest of the PHP community because this has been a problem I've battled on several projects before finally solving it today.



I am using sessions to register a user's ID, and every so often, for no apparent reason, the session would seem to expire and my logged-in user would get kicked out.



This is the code I am using to validate a user:

<?php

session_start();



$auth = false;



if (isset($_SESSION['user_id'])) {

   $user = new User($_SESSION['user_id']);

   $auth = true;

else {

   $login = $_REQUEST['login'];

   $password = $_REQUEST['password'];

   $login = clean($login);

   $password = clean($password);

   // clean() is my own function to escape quotes and so on

   $user = checkLogin($login,$password);

   if (!is_null($user)) {

        $auth = true;

   }

}



if (!$auth) {

   die("you must log in.");

}



// etc etc ... //

?>



I was scratching my head as to why, on about 10% of the times I sent a user to a new page (a PHP page that didn't have any of the sessions stuff--no session_start() and no mention of any session variables), when they came back the session variables were all empty.



I came upon a clue when I used ini_set to change the session.save_path location.  My idea was that maybe the session files in /tmp were being deleted by other users on the system or something.  So I added this line before session_start():

<?php

ini_set('session.save_path',"/path/to/unique/dir/");

?>

I knew no one else was saving their sessions there, so I started logging in to my page and at the same time checking for the creation of new sess_* files.  I noticed that sometimes, especially when I had problems, a second session file (that was empty) would appear.



What I realized was that the URL was changing from www.coryforsyth.com to coryforsyth.com.  When the presence of the WWW changed, PHP thought it was a different session and created an empty one that caused my script to log me out.  If I went to the location bar of my browser and added/removed the WWW (to the way it had been before), all was well and I was still logged in.



An incredibly thorny problem. I hope this post helps someone else fix it, or even better prevent it.  I changed my hosting preferences to automatically add a WWW to my domain if it wasn't typed that way.



thanks,

Cory Forsyth

brady at volchok dot com 17-Apr-2006 12:15


Session locking (concurrency) notes:





As mentioned several times throughout this section on Sessions, the default PHP session model locks a session until the page has finished loading. So if you have two or three frames that load, and each one uses sessions, they will load one at a time. This is so that only one PHP execution context has write access to the session at any one time.





Some people work around this by calling session_write_close() as soon as they've finished writing any data to the $_SESSION - they can continue to read data even after they've called it. The disadvantage to session_write_close() is that your code still will lock on that first call to session_start() on any session'ed page, and that you have to sprinkle session_write_close() everywhere you use sessions, as soon as you can. This is still a very good method, but if your Session access follows some particular patterns, you may have another way which requires less modification of your code.





The idea is that if your session code <b>mostly</b> reads from sessions, and rarely writes to them, then you can allow concurrent access. To prevent completely corrupted session data, we will lock the session's backing store (tmp files usually) while we write to them. This means the session is only locked for the brief instant that we are writing to the backing store. However, this means that if you have two pages loading simultaneously, and both modify the session, the <i>Last One Wins</i>. Whichever one loads first will get its data overwritten by the one that loads second. If this is okay with you, you may continue - otherwise, use the session_write_close method, above.





If you have complicated bits of code that depend on some state in the session, and some state in a database or text file, or something else - again, you may not want to use this method. When you have two simultaneous pages running, you might find that one page runs halfway through, modifying your text file, then the second one runs all the way through, further modifying your text file, then the first one finishes - and your data might be mangled, or completely lost.





So if you're prepared to debug potentially very, very nasty race conditions, and your access patterns for your sessions is read-mostly and write-rarely (and not write-dearly), then you can try the following system. 





Copy the example from session_set_save_handler() into your include file, above where you start your sessions. Modify the session write() method:





<?php


function write($id, $sess_data)


{


  global $sess_save_path, $sess_session_name;





  $sess_file = "$sess_save_path/sess_$id";


  if ($fp = @fopen($sess_file, "w")) {


   flock($fp,LOCK_EX);


   $results=fwrite($fp, $sess_data);


   flock($fp,LOCK_UN);


   return($results);


  } else {


   return(false);


  }





}


?>





You will probably also want to add a GC (Garbage Collection) method for the sessions, as well.





And of course, take this advice with a grain of salt - We currently have it running on our testing server, and it seems to work OK there, but people have reported terrible problems with the Shared Memory session handler, and this method may be as unsafe as that.





You can also consider implementing your own locks for scary concurrency-sensitive bits of your code.

Cosmo 01-Apr-2006 04:47


Fairly new to PHP, I've been looking to alter session timeouts on a shared host where I don't have direct access to configure php.ini.  There doesn't appear to be any easy way to find out how to do this in this manual (nor from a quick web search).



The code below seems to work OK to set session timeout.     a timeout of 30 secs is used for convenient testing.  gc settings must come before session_start().



The garbage collection is made 100% by setting probability and divisor to the same value - if I have correctly understood what these functions do.

  

(on the first pass of the file, there is no session file - that's established only when the script ends for the first time.  Keep reloading to test).



Comments welcome.



<?php

  ini_set('session.gc_maxlifetime',30);

  ini_set('session.gc_probability',1);

  ini_set('session.gc_divisor',1);

    session_start();

    

// check to see what's happening

$filepath = ini_get('session.save_path').'/sess_'.session_id();

    

if(file_exists($filepath)) 

{

    $filetime = filemtime ($filepath);

    $timediff = mktime() - $filetime;

    echo 'session established '.$timediff.' seconds ago<br><br>';

}

?>

crown2gain at yahoo dot com 01-Mar-2006 10:19


I just spent a lot of time trying to figure out why my session variables were not available after I seemed to have set them(could echo after setting).  I use the same script for several different functions, so the user may reload the page for other purposes.  Someone else posted the use of session_write_close();  before a Location redirect.  This also worked in put this after I set the session variables the variables are available when the page reloads for another function.





<?php


$_SESSION['guid'] = $guid;


$_SESSION['userdata'] = $response;


session_write_close();


?>

a l bell at hutchison dot com dot au 28-Feb-2006 03:17


Please Note;



Internet explorer users beware.



When using session_start() to begin a session this session will remain open until the page has finished loading or it is explicitly terminated.



You can lose the session however if the the page contains a reference to <img src=""> with name and id references (which may be used if the image is referencing a dynamic image, called by javascript)  This seems to casue IE6 to refresh the page session id and hence loose the session.



This took hours for me to diagnose when users were getting unexpectedly logged out of my site due to this "" in the img src.

kintar at infinities-within dot net 28-Feb-2006 09:10


Important note that it just took me the better part of two hours to figure out:  Even if you're using session_write_close(), calling exit after a redirect will eat your session variables.  I had the following:



Source of register.php:

<?PHP



// Some files included here



// Process our posted form data

$result = processPost();



if ($result)

{

  redirect('success.php');

}

else

{

  redirect('failure.php');

}



exit;

?>



processPost() was setting a couple of session variables, including an error message, but neither results page was seeing those variables.  I removed the exit call from the register page, and all works fine.



/bonks self

hans at nieser dot net 14-Feb-2006 07:15


FreeBSD users, instead of modifying the PHP5 port Makefile, you can either install the session extension using the www/php5-session port, or you can install several extensions at once (you can pick them from a menu) using the lang/php5-extensions port. Same goes for PHP4

just_somedood at yahoo dot com 01-Feb-2006 09:31


If you're running FreeBSD, and installed php5 (have not checked 4) from the ports, and are getting errors saying the session functions are undefined, try running phpinfo().  You'll probably see that the '--disable-all' configure command was used.  To fix, edit the /usr/ports/lang/php5/Makefile, and remove the '--disable-all' line.  In that directory, run a 'make deinstall', if you installed already.  Next, run 'make install' while still in that same directory.  It should work fine after that.

jerry dot walsh at gmail dot com 24-Jan-2006 06:56


If you're using sharedance to distributed php sessions across a group of machines beware of the following:



On a freebsd 6.x system I have observed a huge performance hit caused by dns/host file lookups.



To ensure maximum performance using sharedance you should set the 'SESSION_HANDLER_HOST' constant to an IP rather than a hostname.



When i did this my requests per second jumped from 55 to 389 requests per second!

jazfresh at hotmail dot com 19-Dec-2005 06:55


The vanilla implementation of session will blindly spew back the value of the session_id that the user sends it after URL decoding it. This can be used as an attack vector, by including strings like "%0D%0ALocation:%20http://someothersite.com/%0D%0A" in the cookie. Never trust user input, always cleanse it. If you only expect alphanumerics in the session hash, reject any session_id that doesn't contain it.



<?php

if(!preg_match('#^[[:alnum:]]+$#', $_COOKIE['session_id'])) {

  unset($_COOKIE['session_id']);

}

session_start();

?>

Bram 19-Nov-2005 08:39


[editors note]


It should be noted that it's highly recommended to store sessions for each virtual host in seperate directories or in a database.


[/editors note]





I just noticed that it's possible to access the same session through multiple apache virtual hosts.


So keep this in mind when using sessions for anything sensitive, and make sure to encrypt the data (using the mcrypt functions for example, when available).

Lachlan Hunt 10-Nov-2005 06:10


> Note:  The arg_separator.output  php.ini directive allows to customize the argument seperator. For full XHTML conformance, specify &amp; there.



Exactly the same rule applies to HTML as well, there is abolutely no reason why this should not be set to &amp; by default.  The only difference is that in XHTML, XML error handling defines that it's a well formedness error.  For HTML, error handling was not so well defined nor sanely implemented and tag soup parsers just accept it, but that doesn't make it right.



arg_separator.output *MUST* be set to either of these if you're outputting either HTML or XML:



arg_separator.output = "&amp;"

arg_separator.output = ";"



http://www.w3.org/QA/2005/04/php-session

christopher dot klein at ecw dot de 23-Oct-2005 11:26


If you have trouble with Internet Explorer 6 and non-working sessions (all session-data is lost after clicking on a link), please look user-hints for setcookie().

You have to add the following line after session_start() to get sessions working:



<?php

  // Initalize session

  session_start();

  // Send modified header

  header('P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"');

?>

akoma at t3 dot rim dot or dot jp 19-Sep-2005 03:50


If your are using UTF-8, make sure your source

code editor to do not put the BOM mark 

(unicode sign) at the top of your source code. so

it is sent before session_start() causing "headers

already sent" message on httpd error log.

fasteddie at byu dot edu not_this_part 16-Aug-2005 08:43


I hope this helps someone:

---PHP SESSIONS NOT WORKING---

My sessions wouldnt ever load from disk. The sessions would start just fine, and a session file would be created and written to disk. (BTW, I'm on a win XP box, Apache 2.0.54, PHP version 5.0.4.) However, next time I loaded the page, the old session would not be used. Instead, a NEW session was created. For me, this happened no matter what computer I was using, whether it was the server (localhost) or a client (remote). A new session was created EVERY TIME I loaded the page.. it was annoying. After a few hours of googling, I gave up and decided to mess around in the php.ini file. I changed this line:

session.cookie_path = /

to this:

session.cookie_path =



Now, php sessions are loaded properly.



I havent tried many things but I think maybe it is because windows needs backslashes (\) instead of forward slashes (/), and if you just leave it blank, it turns out ok.

artistan at cableone dot net 08-Aug-2005 10:29


I rewrote adodb's session management class to work across servers with database managed sessions.  Take a look at http://phplens.com/lens/lensforum/msgs.php?id=13428

Christian Boltz <php-manual at cboltz dot de> 28-Jul-2005 04:33


Another note about session.bug_compat_42 and bug_compat_warn.



[full error message:

    "Your script possibly relies on a session side-effect which existed 

    until PHP 4.2.3. Please be advised that the session extension does 

    not consider global variables as a source of data, unless

    register_globals is enabled. You can disable this functionality and 

    this warning by setting session.bug_compat_42 or 

    session.bug_compat_warn to off, respectively."

]



The following short script causes the bug_compat_42 warning to appear.



<?php

  session_start();

  $_SESSION['var'] = NULL;

  $var = "foo";

?>



It took me an hour to find out this :-(  - so I post it here to avoid 

that more people need such a long time.



Conclusion and test results:



You'll get this warning if $_SESSION['var'] contains NULL and you assign 

anything (except NULL) to the global variable $var.



The warning will _not_ appear:

- if $_SESSION['var'] contains anything else   - or -

- if you don't use a global variable named $var

d43m0n at shaw dot ca 18-Jul-2005 01:19


Hello,



I posted earlyer about a issue/bug with Windows servers handling sessions. If you did not read it, it was based on the fact that if you can use ini_set to re-define the session.save_path to a relitive location. PHP will instead use it as the exact location with out looking at the directory where your script is bein execute, thus to say, the session file is not created, or re-read. This of course only occurs if you use <?php reregister_id() ?>. This function is told to open the requested session file, obtain the varibles, regenerate an id for that session, create the new session file and then send the cookie header to the client, of course I did not create this function, so it may not be in that order.



The following code will generate the error that I speak of, and will not successfully generate the new session id, of course like I said above, this only accours on PHP 5 & 5.0.4 under the Windows Environment.



<?php



  define("_PATH_TMP", "./tmp");

  ini_set('session.save_path', _PATH_TMP);

  session_start(); 

  $_SESSION['sid']['obsolete'] = session_id();

  session_regenerate_id();

  $_SESSION['sid']['replaced'] = session_id();

  print_r($_SESSION);



?>



(I know that PHP may use defined constants that include '_' characters at the beggining, if it has not already, but I am taking that chance atm...)



This can simply be resolved by using the following code:



<?php

  define("_PATH_TMP", dirname($_SERVER['SCRIPT_FILENAME']) . "/tmp");

  ini_set('session.save_path', _PATH_TMP);

  session_start(); 

  $_SESSION['sid']['obsolete'] = session_id();

  session_regenerate_id();

  $_SESSION['sid']['replaced'] = session_id();

  print_r($_SESSION);

?>



As you can see it uses the uses the servers environment to assurtain the exact location to the script, then locates the next root directory of it, and then allows you to define the tmp directory.



* Of course, you dont need to use a tmp directory, and this issue only occurse when using subdirectorys, I found that the following works just aswell, but this did not fit my needs!



<?php



  define("_PATH_TMP", "./");

  ini_set('session.save_path', _PATH_TMP);

  session_start(); 

  $_SESSION['sid']['obsolete'] = session_id();

  session_regenerate_id();

  $_SESSION['sid']['replaced'] = session_id();

  print_r($_SESSION);



?>

nigelf at esp dot co dot uk 16-Jun-2005 04:52


Session data is not available to an object's __destruct method as sessions are closed before the object is 'destroyed'.

Richard [at] postamble [dot] [co] [uk] 13-Jun-2005 07:44


Having to use transparent on a system where trans_sid was not compiled, I came up with the folowing ob_start handler:

<?php

function ob_sid_rewrite($buffer){

    $replacements = array(

        '/<\s*(a|link|script)\s[^>]*(href|src)\s*=\s*"([^"]*)"/',

        '/<\s*(a|link|script)\s[^>]*(href|src)\s*=\s*\'([^\'<>]*)\'/',

        );

          

   $buffer = preg_replace_callback($replacements, "pa_sid_rewriter", $buffer);



   $buffer = preg_replace('/<form\s[^>]*>/',

        '\0<input type="hidden" name="' . session_name() . '" value="' . session_id() . '"/>', $buffer);

        

   return $buffer;

}



function pa_sid_rewriter($matches){

    $buf = $matches[0];

    $url = $matches[3];

    $url_orig=$url;

    if ($url[0]=='/' || $url[0]=='#' || preg_match('/^[A-Za-z0-9]*:/', $url))

        return $buf;



    $ses_name = session_name();

    if (strstr($url, "$session_name="))

        return $buf;

    

    $p = strpos($url, "#");

    $ref = false;

    if($p){

        $ref = substr($url, $p);

        $url = substr($url, 0, $p);

    }

    if (strlen($url)==0)

        return $buf;

    if (!strstr($url, "?"))

        $url.="?";

    else

        $url.="&amp;";

    $url.=session_name() ."=".session_id();

    if($ref)

        $url.=$ret;

    return str_replace($url_orig, $url, $buf);

}

?>



It adds a field to urls and a fake form entry.



You can start the rewrite by doing the folowing at the start of the script:

<?php

function pa_set_trans_sid(){

    if ( defined('SID') ){ // use trans sid as its available

        ini_set("session.use_cookies", "0");

        ini_set("session.use_trans_sid", "true");

        ini_set("url_rewriter.tags", "a=href,area=href,script=src,link=href," 

. "frame=src,input=src,form=fakeentry");

    }else{

        ob_start('ob_sid_rewrite');

    }

}

?>

trev at beammeupnowplease dot com 03-Jan-2005 08:09


You can't turn off session.use_trans_sid on an individual script basis until PHP5. 





However, if you use ini_set('url_rewriter.tags', ''); at the top of your script this will stop the SID being written to the URL's in PHP4. 





Hopefully will save someone else a frustrating couple of hours. 





Trev

Michael Wells 22-Nov-2004 09:04


If you are trying to share sessions across a cluster of servers, and don't want to use NFS, or a relatively heavy and slow RDBMS, there is an excellent tool called ShareDance that can do it over a simple TCP protocol. ShareDance comes complete with a PHP interface example and works 'out of the box' for me.



http://sharedance.pureftpd.org/



My thanks to Frank Denis for writing this elegant, valuable piece of software.

Dopey 02-Sep-2004 11:06


Be careful when using the Content-Length header with session.use_trans_sid enabled. Technically, it might not be a bug, but PHP does not update the header when it adds the session ID to links in a page. The result is that only partial content is shown in a browser.



In short: if you use ob_get_length to figure out Content-Length, turn session.use_trans_sid off!

schulze at telstra dot com dot not dot this dot bit 06-Jun-2004 04:10


sessions not sticking and cookies not setting with IE? took me ages to find the problem.



you need a 'compact privacy policy'! it's not hard once you know how! 



this was too much for me: http://www.w3.org/TR/P3P/



but http://www.sitepoint.com/article/p3p-cookies-ie6/2 is very easy to apply



and a visit to this site is very worthwhile: http://www.privacycouncil.com/freep3pfix.php



happy PHP to all!



Erich

Afternoon 04-May-2004 12:28


I found a good solution to create a persistent session by storing a persistence flag, ironically, in the session itelf. I start the session (which sends a Set-Cookie with no expiry time), read the flag and then, if the user wants a persistent session, stop and restart the session with the expiry time set using session_set_cookie_params, which then sends a cookie with a good expiry time. This solution has been quickly tested with all major browsers and seems to work.



I have outlined the whole process in my blog: http://aftnn.org/journal/508

pautzomat at web dot de 19-Nov-2003 12:05


Be aware of the fact that absolute URLs are NOT automatically rewritten to contain the SID. 



Of course, it says so in the documentation ('Passing the Session Id') and of course it makes perfectly sense to have that restriction, but here's what happened to me:

I have been using sessions for quite a while without problems. When I used a global configuration file to be included in all my scripts, it contained a line like this:



$sHomeDirectory = 'http://my.server.com/one/of/my/projects'



which was used to make sure that all automatically generated links had the right prefix (just like $cfg['PmaAbsoluteUri'] works in phpMyAdmin). After introducing that variable, no link would pass the SID anymore, causing every script to return to the login page. It took me hours (!!) to recognize that this wasn't a bug in my code or some misconfiguration in php.ini and then still some more time to find out what it was. The above restriction had completely slipped from my mind (if it ever was there...)



Skipping the 'http:' did the job.



OK, it was my own mistake, of course, but it just shows you how easily one can sabotage his own work for hours... Just don't do it ;)

ricmarques at spamcop dot net 15-Oct-2000 05:16


Regarding session.cache_limiter :





For those of you who - like me - had trouble finding the meaning of the possible values (nocache, public and private), here's the explaination taken from the HTTP 1.1 Specification at


http://www.w3.org/Protocols/rfc2068/rfc2068








"14.9.1 What is Cachable





[snip]





public


  Indicates that the response is cachable by any cache, even if it would normally be non-cachable or cachable only within a non-shared cache. (See also Authorization, section 14.8, for additional details.)





private


  Indicates that all or part of the response message is intended for a  single user and MUST NOT be cached by a shared cache. This allows an origin server to state that the specified parts of the response are intended for only one user and are not a valid response for requests by other users. A private (non-shared) cache may cache the response.





  Note: This usage of the word private only controls where the response may be cached, and cannot ensure the privacy of the message content.





no-cache


  Indicates that all or part of the response message MUST NOT be cached anywhere. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests.





  Note: Most HTTP/1.0 caches will not recognize or obey this directive."

shanemayer42 at yahoo dot com 19-Aug-2000 07:11


Session Garbage Collection Observation:





It appears that session file garbage collection occurs AFTER the current session is loaded.  





This means that:


even if session.gc_maxlifetime = 1 second, 


if someone starts a session A and no one starts a session for an hour,  that person can reconnect to session A and all of their previous session values will be available (That is, session A will not be cleaned up even though it is older than gc_maxlifetime).

add a note