Mailinglisten-Archive |
Hallo Barbara,
* Barbara Griem wrote:
> Also ich frage extra vorher ab, daß der Client Cookies
> zulässt, also sollten Cookies benutzt werden. Allerdings
> finde ich den Cookie beim Client auch nicht wieder...
> (Müsste doch irgendwo bei den temporären Internetdateien
> sein...??)
Meist werden Cookies mit der Laufzeit "0" verwendet.
Das bedeutet: beendest du den Browser, so wird der
Cookie gelöscht.
Dass du den Cookie in den temporären Internetdateien
(du verwendest MS Internet Explorer?) nicht findest,
liegt daran, dass solche Cookies mit der Laufzeit einer
Browsersession (d.h. bis zum Beenden des Browsers)
vom Browser nicht in eine Datei geschrieben werden.
Macht ja auch keinen Sinn, da der Cookie ja nur so lange
gültig sein soll, wie die Browserinstanz existiert.
> Sorry wenn das alles konfus ist, aber mir ist diese
> Session-Geschichte wirklich kryptisch.
Mit einer Session stellst du sicher, dass du einen
Client über Scriptgrenzen hinweg identifizieren kannst.
Die Unterscheidung über IPs funktioniert nicht, da
mehrere Benutzer/Clients unter einer IP auftreten
können (Proxy) oder ein Benutzer unter mehreren IPs
(Reconnect zum Provider, DSL-Dialin mit automatischem
Disconnect etc.).
Aus diesem Grund gibt es die Sessions. Das ist in der
Regel eine kryptisch anmutende, 32-stellige Folge der
Zahlen 0-9 und a-f (Hexadezimalsystem), die meist über
die Funktion md5(uniqid("blahmagicstring")); erzeugt
wird. Der md5-Hash hat den Vorteil, eineindeutig zu
sein. Mit uniqid() und einem entsprechenden Zufallsstring
erzeugst du eine zufällige Folge, die an md5 übergeben
wird. So gehst du sicher, dass jedes Mal bei Erzeugen
der Session-ID, zwar ein md5-Hash erzeugt wird, dieser
aber eineindeutig ist.
Damit der Server den Benutzer also "identifizieren" kann,
ist diese Session-ID nötig. D.h. bei jedem Request muß
diese Session-ID vom Client an den Server übermittelt
werden. Findet der Server in seinen Aufzeichnungen diese
Session-ID und ist diese noch gültig, dann weiß er "Okay,
der war schon mal da". Findet er sie nicht, wird eine neue
Session-ID erzeugt und dem Client mitgeteilt.
Dieses Mitteilen geschieht in der Regel über zwei verschiedene
Wege: Cookies (bequem) oder über Anhängen der Session-ID als
Parameter an die URL (GET) oder als hidden-Form Element bei
Formularen (POST).
Der bequeme Weg liegt also darin, ein Cookie beim Client
abzuliefern und in diesem Cookie die Session-ID zu speichern.
Der Vorteil ist, dass bei jedem Request an diese Domain der
Cookie und damit auch die Session-ID automatisch mitgeliefert
wird. Wird der Cookie abgelehnt (das weißt du erst beim nächsten
Request, da Cookie über die HTTP-Header mitgeliefert werden),
so mußt du dafür sorgen, dass zukünftig die Session-ID "manuell"
angehängt wird (siehe nächster Absatz).
Bei den anderen beiden Methoden, mußt du dafür sorgen, dass
die Session-ID bei jedem Link und bei jedem Formular mit
übermittelt wird. Das heißt selbst bei einem window.open
aus JavaScript, das ein PHP-Script im neuen Fenster aufruft,
muß an dieses PHP-Script die Session-ID via GET-Parameter
übermittelt werden.
PHP4 kann dir hierbei allerdings einige Arbeit abnehmen,
mit dem Feature von --enable-trans-sid. Damit wird an alle
Links, Formulare etc., die im HTML-Code vorkommen, automatisch
die Session-ID angehängt. Dieses Feature funktioniert bis
einschließlich PHP4.0.6 *nicht*, _wenn_ du das Feature der
transparenten Output Compression verwendest, da hier die Output
Layer (Sascha, korrigiere mich falls ich falsch liege) "verschoben"
waren und das trans-sid Feature erst nach dem Komprimieren des
HTML-Codes einsetzte (und dementsprechend auch keine zu ergänzenden
Links mehr fand).
Warum allerdings Dario seine eigene Session-Klasse gebaut hat,
ist mir schleierhaft, gibt es doch dazu keinen mir auf den
ersten Blick ersichtlichen Grund ... (NIH-Syndrom? :)
--
PHP-Support * realitätsnahe Performance-Messungen mit Code-Analyse
Webapplikationsentwicklung * PHP-Schulungen * Consulting
0700-THINKPHP -*- bjoern_(at)_thinkphp.de
php::bar PHP Wiki - Listenarchive