Mailinglisten-Archive |
* Björn Schotte wrote:
> Damit der Server den Benutzer also "identifizieren" kann,
> ist diese Session-ID nötig. D.h. bei jedem Request muß
Nachfolgend noch ein weiterer Sinn von Session-IDs. Wie
ich bereits sagte, können damit Daten über Scriptgrenzen
hinweg gerettet werden.
Das brauchst du zum Beispiel, wenn du mehrseitige Formulare
erzeugst (z.B. Wizards, wie in Ulfs OOHForms), sensible
Daten auf dem Server verbleiben sollen (Kreditkartennummern
etc.) oder Daten, die bei vorherigen Requests gesammelt wurden,
im aktuellen Script weiterverwendet werden können.
Der übliche Weg eines Anfängers (so fing ich auch an) ist
es, Daten über Scriptgrenzen durch hidden-Formulare hinweg-
zuretten. Man bekommt da schnell Probleme, denn ein hidden-
Formular enthält als Value einen String, d.h.
- was passiert, wenn in diesem String Newslines enthalten
sind? Aufwand zum Serialisieren nötig.
- was passiert, wenn die Daten sensibel sind und somit
manipuliert werden können?
Zusätzlich hat man dann noch die Schwierigkeit, wenn man
kein Formular verwenden will, muß man die gesammelten Parameter
über die URL (also mit der GET-Methode) mitteilen. Die Länge
einer URL ist vom Server begrenzt und beträgt in der Regel
2048 bzw. 4096 Zeichen (4096 ist IIRC Default-Einstellung von
Apache, kann mich aber auch täuschen).
Zusätzlich kannst du damit nicht verhindern, dass ich auf
script1.php gerade was mache (du also Daten sammelst), dann
schnell auf spiegel.de gehe um die neuesten mindergeistigen
Ergüsse von Stoiber zu lesen und dann wieder zurück zu
script1.php springe, um weiterzumachen: plötzlich sind die
Daten wieder verloren. Würdest du Sessions verwenden und mir
ein Cookie verpassen, wären die beim ersten Besuch von script1.php
gesammelten Daten noch vorhanden.
Aber, auch Sessions sind nicht perfekt: bei Übermittlung der
Session-ID via GET-Parameter muß ich darauf achten, dass beim
nächsten Besuche diese wieder vorhanden ist, also dem Server
mitgeteilt wird. Bei obigem Springen mit Spiegel.de hülfe hier
nur, auf den Back-Button des Browsers zu klicken, um an die
URL mit angehängter Session-ID zu gelangen. Bei Neueingabe von
http://www.deinedomain.de/script1.php wäre keine Session-ID
da und du würdest eine neue Session verpaßt bekommen, mithin also
an deine alten gesammelten Daten nicht mehr rankommen.
Auch bereiten Session-IDs per GET-Parameter Probleme bei Otto-
Normal-Usern (bevorzugt die Outlook-Benutzerspezies). Diese
kopieren schnell mal die URL (inkl. Session-ID) ins Outlook,
um dem Freund/der Freundin die Seite mitzuteilen. Pech nur,
wenn deine Session-ID noch gültig ist und der Freund/die Freundin
mit dieser Session-ID auf diese Seite zugreift: dann hat diese(r)
plötzlich Zugriff auf die von dir gesammelten Daten (z.B. Kreditkarten-
Daten).
Deswegen sind Cookies viel sinnvoller, auch wenn Firmen wie
DoubleClick den Cookies leider ein Negativ-Image aufprägten
(denn Cookies sind nicht böse). Noch sinnvoller sind Cookies
mit der Lebenszeit 0, d.h. Gültigkeitsdauer der Browser-Session.
Warum? Stell' dir vor du bist im Internet-Cafe und gerade bei
deinem Lieblingsshop eingeloggt. Würde ein Cookie mit der
Session-ID und einer Lebenszeit von 2 Tagen (d.h. Cookie wird
auf Festplatte gespeichert) gesetzt werden, könnte ein nachfolgender
Nutzer des Rechners durch Kenntnis der URL, bei der du warst
(Browser-History macht's möglich), plötzlich an deine auf dem
Server gespeicherten Daten kommen. Dagegen kann man sich entweder
mit Lebenszeit 0 absichern oder noch mal einen weiteren Schutzmechanismus
bauen, wie es z.B. Amazon macht: obwohl es mich als Nutzer Björn Schotte
(wegen Cookie) erkennt, muß ich mich für bestimmte Vorgänge noch einmal
mit E-Mail + Passwort einloggen.
--
PHP-Support * realitätsnahe Performance-Messungen mit Code-Analyse
Webapplikationsentwicklung * PHP-Schulungen * Consulting
0700-THINKPHP -*- bjoern_(at)_thinkphp.de
php::bar PHP Wiki - Listenarchive