Mailinglisten-Archive |
Oliver Kummerow schrieb:
> http ist ein sog. "stateless" also zustandsloses
> Protokoll und erlaubt keine Benutzerfuehrung
> ueber Session-Variablen bzw. die Abfrage von
> Programmstatusinformationen.
Das ist soweit erst einmal richtig, aber es gibt verschiedene
Möglichkeiten, State auf dem Server zu halten, sobald man es
geregelt bekommt, die verschiedenen Browser zu unterscheiden, die
simultan auf den Server zugreifen.
> Mir bekannte Auswege: CGI-Elemente (Variablenuebergabe via
> Get und Post) lassen sich in php einlesen und ansonsten
> gibt es offenbar nur den Weg ueber Cookies.
>
> -->>> Kennt jemand noch andere Moeglichkeiten?
Grundsätzlich gibt es vier verschiedene, mir bekannte
Möglichkeiten, einem Browser eine solche eindeutige Markierung zu
verpassen. Die beste dieser Methoden ist die von Dir genannte
Möglichkeit, einen Cookie zu setzen. Diese Methode sollte von
einer Session-Bibliothek nach Möglichkeit verwendet werden, weil
sie tatsächlich für alle praktischen Zwecke die wenigsten
Schmerzen bereitet, falls der Client Cookies akzeptiert.
Tut er dies nicht, gibt es drei weitere Möglichkeiten:
- Man erzeugt einen GET-Parameter und schleift diesen durch die
Präsentation. Dies setzt voraus, daß alle Seiten der Präsentation
dynamisch erzeugt werden, weil man mindestens alle A, FRAME und
FORM-Tags entsprechend präparieren muß, daß sie den GET-Parameter
enthalten.
Beispiel: Angenommen, ein User bekäme die Session-ID
d41d8cd98f00b204e9800998ecf8427e, dann müßten alle A-Tags in der
Präsentation die Form <a
href="/bla.php3?Session=d41d8cd98f00b204e9800998ecf8427e">bla</a>
haben. Dem Aufruf der Folgeseite, die ebenfalls dynamisch erzeugt
werden würde, stünde dann die Session-ID zur Verfügung. Im
Gegensatz zu POST-Parametern ist hier kein Formular zur
Propagation der ID notwendig.
- Man erzeugt eine PATH_INFO-Komponente, die die Session-ID
enthält. Dies setzt ebenfalls eine dynamische Erzeugung aller
Seiten voraus, weil man wiederum alle A-, FORM- und FRAME-Tags
präparieren muß, um die ID zu propagieren. Diesmal sieht das Link
dann so <a
href="/bla.php3/d41d8cd98f00b204e9800998ecf8427e">bla</a> oder so
<a href="/d41d8cd98f00b204e9800998ecf8427e/bla.php3">bla</a> aus,
wobei man im zweiten Fall ein wenig mit Apache Rewrite-Rules
spielen muß, damit ein Schuh (bzw. eine Session) daraus wird.
- Man erzeugt eine Authentication (401) und setzt die Session-ID
als Realm-Name, akzeptiert aber jeden beliebigen Usernamen und
jedes beliebige Paßwort. In allen folgenden Aufrufen wird die
Session-ID als Realm mitgeliefert.
Die dritte Methode hat wie Cookies den Vorteil, daß nicht alle
Seiten der Präsentation dynamisch generiert werden müssen. Auch
erscheint wie bei Cookies die ID nicht in der URL, sodaß sie auch
nicht außerhalb der Session (etwa durch Abdruck in Zeitschriften
oder durch Bookmarking) konserviert werden kann.
In jedem Fall genügt es, eine einzelne eindeutige ID zu
übermitteln. Auf dem Server kann man dann einen persistenten
Speicher (Datenbank, DBM-Datei, reguläre Datei, Shared Memory)
haben, den man über diese ID indiziert und in dem man beliebig
viele Variablen halten kann. Es ist nicht notwendig und auch
nicht empfehlenswert, den kompletten State einer Anwendung über
HIDDEN-Variablen oder andere Maßnahmen von Seite zu Seite zu
retten und dabei zwischen Server und Client Ping-Pong zu spielen.
Es ist notwendig, daß die IDs, die eine Session identifizieren,
nicht ratbar sind. Wäre eine Session-ID "46", wäre man versucht,
sich kurzerhand die ID "45" oder "47" zu verpassen und einmal zu
sehen, was dann passiert. Wählt man stattdessen vollkommen
zufällige IDs aus einem sehr großen, dünn besetzten Raum
möglicher IDs, ist es sehr unwahrscheinlich bis unmöglich, durch
Raten an fremde Sessions zu gelangen. Eine solche ID kann man
entweder mit der PHP3-Funktion mt_rand() generieren (den ID-Raum
*GROSS* wählen) oder mit "md5(uniqid("geheim"))". Im letzteren
Fall hat man einen ID-Raum von 2^128 möglichen IDs, der durch
eine kryptographische Hashfunktion addressiert wird (also
wahrscheinlich gleichverteilt genutzt wird - das wäre dann
optimal).
Dadurch, daß man für die Session nur eine Opaque ID übermittelt
und den eigentlichen State auf dem Server hält, nimmt man dem
Anwender Manipulationsmöglichkeiten, die er beim Ping-Pong
Spielen mit Session-Variablen hätte. Zugleich wird die zu
übertragende Datenmenge verkleinert und der State ist nicht durch
Dritte abhörbar, da er nie über das Netz kommuniziert wird.
PHPLIB implementiert ein solches System (und noch ein paar
Extras) und kann dabei die ID über Cookies und über GET
transportieren. PHPLIB realisiert damit einige (wenige)
Fähigkeiten eines richtiges Application-Servers ohne den Overhead
eine zusätzliche Middleware einführen zu müssen. Dafür skaliert
es sich wesentlich schlechter - für Hochlast wird man sich auf
Apple WebObjects oder ähnliche Software zurückziehen müssen.
Kristian
--
Kristian Köhntopp, NetUSE Kommunikationstechnologie GmbH
Siemenswall, D-24107 Kiel, Germany, +49 431 386 436 00
Using PHP3? See our web development library at
http://phplib.shonline.de/ (GPL)
php::bar PHP Wiki - Listenarchive