[php] Was und wozu sessions

[Björn Schotte]

* Barbara Griem wrote:
> Also ich bin php-Anfängerin und ich habe jetzt viel
> gelesen, und ich versteh immer nur die Hälfte. Bitte erklärt mir doch
> einmal ganz einfach, was genau Sessions sind und wie ich die einsetze.

HTTP ist ein zustandsloses Protokoll. Der Client (z.B. der Browser)
connected zum Server, fordert eine HTML-Seite an plus eventuelle extern
eingebettete Elemente (Bilder, JavaScript, Applets, ActiveX Controls,
embedded objects wie z.B. Flash) und beendet danach die Verbindung.

Der Server notiert "Zum Zeitpunkt X hat die IP 193.123.345.567 die
URI /foo/bla.html im Webserver www.domain.de angefordert".

Wählst du als Benutzer eine weitere Seite des Webservers www.domain.de
an, so wiederholt sich dieser Vorgang. Es entstehen n Einträge im Webserver-
Logfile. Der Webserver kann keine "Verbindung" zwischen diesen n Einträgen
der Form "Diese n Einträge gehören alle zum Client von Barbara Griem" her-
stellen.

Viele versuchen, anhand der IP diese Verbindung zwischen n Seiten her-
zustellen, d.h. "Diese n Einträge gehören alle zum Benutzer mit der IP
193.123.345.567".

Dies wäre eine mögliche Idee, allerdings eine sehr schlechte. Während
du mit deinem Browser surfst kann es sein, dass dein übergeordneter
Proxy-Cache die IP wechselt, weil dein Provider einen Proxy-Verbund
betreibt, der aus n Proxies mit n unterschiedlichen IP-Adressen besteht.

Genau der gleiche Fall, das Wechseln der IP, tritt dann ein, wenn deine
Internet-Verbindung aus irgendwelchen Gründen beendet wird und du dich
neu einwählen mußt - bei fast allen Providern bekommst du damit eine
neue IP zugewiesen. Du bist zwar der gleiche Benutzer, aber mit einer
anderen IP. Der Webserver kann allerdings nicht wissen, dass du die IP
gewechselt hast, und in diesem Moment fällt das Kartenhaus zusammen.

Ein ähnliches Problem wirst du haben, wenn viele Benutzer des Providers
über einen (Zwangs-)Proxy surfen. Damit teilen sich n Benutzer 1 Proxy
mit 1 IP. Der Webserver kann diesen Umstand nicht erkennen und nimmt
fälschlicherweise an, dass alle Connections von der IP des Proxies zu
einem Benutzer gehören, was jedoch nicht der Fall ist.

Aus diesen Gründen muß man sich einen anderen Weg überlegen, wie ein
Zustand respektive ein eineindeutiges Erkennungsmerkmal zwischen dir und
dem Webserver geschaffen werden kann.

Das erreicht man durch so genannte Session-IDs. Schlägt ein Webclient
auf dem Webserver auf, so kontrolliert die Applikation, ob der Client
eine Session-ID mitliefert. Diese Session-ID wird üblicherweise auf einem
der folgenden Wege überliefert: entweder durch ein Cookie oder als Parameter
in der URL (also "/foo/seite.php?session_ID=....").

Wird der Applikation keine Session-ID übermittelt, so muß die Applikation
annehmen, dass ein neuer Benutzer "vorbeikommt". Dies tut sie und verpaßt
dir dann eine neu generierte Session-ID.

Damit hast du im ersten Schritt zunächst einen Zustand zwischen dem
Webserver respektive der Applikation und deinem Webclient hergestellt.

Im zweiten Schritt muß garantiert werden, dass bei allen Folgeseiten
innerhalb der Applikation, die du aufrufst, deine Session-ID mit übermittelt
wird, da die Applikation z.B. vom Weg von index.php (erster Schritt, du
bekamst eine Session-ID verpaßt) auf posteingang.php dort genau deine E-Mails
anzeigen soll. Ergo muß auf posteingang.php die Session-ID aus index.php
ankommen.

Wenn deine Session-ID in einem Cookie liegt, so hast du leichtes Spiel, denn
der Browser sendet automatisch das Cookie mit der Session-ID mit. Benutzt
du keine Cookies oder möchte die Applikation die Session-ID nicht in einem
Cookie speichern, muß ein Link auf index.php, der auf posteingang.php
verweist:

  <a href="posteingang.php">Deine E-Mails</a>
  
... um die Session-ID ergänzt werden:

  <a href="posteingang.php?session_ID=...">Deine E-Mails</a>
  
Dies kann PHP ab Version 4.0.6 bzw. der kommenden Version 4.0.7/4.1
automatisch über das --enable-trans-sid Feature. D.h. es ergänzt automatisch
relative Links (ein Link der Form <a href="http://www.anderedomain.de/">
braucht nicht um die Session-ID ergänzt zu werden) um die Session-ID.

Klickst du also in deinem Browser auf diesen Link:

  <a href="posteingang.php?session_ID=...">Deine E-Mails</a>

so bekommt posteingang.php die Session-ID übermittelt und weiß "Okay,
dies ist jetzt dieser-und-jener Client". Bei Login-Verfahren werden
üblicherweise die Benutzerdaten (also welcher Benutzer bist du und damit
welche E-Mails können dir angezeigt werden) in der Session gespeichert.

Gespeichert? Nun, die Session-ID ist nicht nur dazu da, um einen Zustand
zwischen einem Webclient und dem Webserver herzustellen, sondern auch um
Daten in dieser Session zu speichern. Die Applikation legt also einen
Speicherbereich an (z.B. Datenbank) und kann dort Daten füllen, die nur der
Client/Browser bekommt, der zu dieser Session-ID gehört.

Die Applikation kann also z.B. auf der index.php eine Variable $x in der
Session registrieren und diese Variable mit einem Wert, z.B. 5:

  $x = 5;
  
belegen. Am Scriptende werden alle registrierten Variablen "aufgesammelt"
und in der Session gespeichert.

Wenn du auf den Link zu posteingang.php klickst, wird ja die Session-ID
mit übermittelt. Das Session-System schaut dann, wenn posteingang.php
aufgerufen wird, nach ob es in seinem Session-Speicherbereich diese
Session gibt und holt alle Variablen, die dort gespeichert sind, in das
PHP-Script zurück. Das heißt du kannst in posteingang.php schreiben

   print "x ist $x";
   
und wie von "Geisterhand" erscheint dort "x ist 5", obwohl posteingang.php
über die URL kein ?x=5 übermittelt bekommen hat.

Kurz gesagt: du kannst mit Sessions Daten über Scriptgrenzen "hinwegretten".
HTTP ist da recht beschränkt, da es nach dem request-response Prinzip
arbeitet (hatte ich ganz am Anfang erklärt).

Wenn du Sessions verwendest, kannst du dir oftmals das Mitschleifen von
hidden-Fields in Formularen sparen. Deine Applikationen werden sicherer,
da die Daten, die in der Session gespeichert werden, auf dem Server ver-
bleiben und nicht durch URL-Manipulationen verändert werden können.

Und: Sessions haben eine Lebenszeit. Sobald du beim ersten Kontakt eine
Session-ID verpaßt bekommt, notiert sich die Applikation die vorher vom
Entwickler/Administrator festgelegte Lebenszeit der Session. Tritt innerhalb
dieser Zeitspanne kein weiterer Kontakt (d.h. kein weiterer Request einer
Seite) zwischen dir und dem Webserver mit dieser Session-ID auf, so wird
diese als ungültig angesehen und nach einer gewissen Zeit gelöscht.

Einfaches Beispiel: Lebenszeit 30 Minuten. Du gehst zum Zeitpunkt x auf
index.php, loggst dich dort ein und bekommst eine Session-ID verpaßt.
Plötzlich ruft dich dein Kollege an und Ihr plaudert 45 Minuten lang.
Danach möchtest du auf posteingang.php gehen um zu sehen, ob neue E-Mails
vorliegen. Die Applikation wird dir sagen, dass deine Session und damit
dein Login invalid sind und du dich neu einloggen mußt.

Ich hoffe, das war verständlich.

-- 
PHP- und MySQL-Schulungen.                   * Kontakt:         *
Consultingdienstleistungen.                  *                  *
Managementseminare als Entscheidungshilfe    * team_(at)_thinkphp.de *
zu einem möglichen Einsatz von PHP und MySQL * 0931 / 78 43 804 *