[php] Sessions for runaways

[Johann-Peter Hartmann]

Hallo Liste,

	Die Sessionproblematik ist nicht neu, und
	es sind ein Haufen Lösungen da, und es wurde
	viel darüber diskutiert.

	Trotzdem fängt es hier wieder bei Adam und Eva
	an, ohne dass jemand sich die Mühe gemacht hat,
	mal ein bischen in diesem Internet-Dingsbums
	zu recherchieren .

Christian Toepp schrieb:
> Wie ich schon in einer vorherigen Mail geschieben habe,
> darf ich keine Cookies setzen. Über die Sache mit
> dem extra-Web werde ich mal garnicht nachdenken ;-)

Burkhard Stollenwerk schrieb:
> Kann mir einer erklären was es mit Sessions gemeint ist.


	Problematik

	Also, das Grundproblem vor Sessions ist immer
	das gleiche : HTTP ist ein zustandsloses Protokoll.

	Das heißt, dass wir innerhalb einer Reihe Seiten,
	durch die sich ein Nutzer klickt, keinen Zustand
	mitnehmen können - wie etwa

	- das ist Nutzer Y auf der anderen Seite
	- er hat sich bereits mit passwort angemeldet
	- er hat einen Warenkorb
	- da sind 4 Sachen drin
	- beim letzten mal hat er sich die Rechnung an
	  Adresse X schicken lassen


	Die Lösung

	Die erste Idee, wenn man vor einem solchen Problem
	steht, ist immer : ich muss die Daten irgendwie
	mitnehmen, dass sie auf der nächste Seite wieder habe.

	Das geht auch. Man kann sie z.B. in den Cookie packen.
	Oder als Get-Variable von Seite zu Seite schleppen.
	Oder in die URL tun. Man benötigt eben irgendeinen
	Datenspeicher, der unabhängig vom Server auf der Client-
	Seite überlebt.

	Das ist hier auch Christians Frage: er darf keine
	Cookies benutzen, und auch GET/Post-Variablen .

	Grundsätzlich ist aber URL und Cookie der einzige
	Datenspeicher auf der Client-Seite, den man fest
	vorraussetzen kann.

	Bei Cookies stimmt das noch nicht einmal, da viele
	Leute Cookies deaktiviert haben - entweder weil sie
	genau wissen, was sie tun - oft aber, weil sie
	keine Ahnung haben, was sie tun, etwa aus Virenangst
	oder ähnlichem.

	Deshalb bleibt als Weg der Transport über die URL.
	Da gibt es einen ganzen Haufen Tricks, wie man sie
	dieser untermogeln kann. Etwa im Hostnamen, wie
	Sevenval es sich im Patent geschützt hat. Oder eben
	als Get-Variable, wie es oft gelöst wird. Oder als
	Bestandteil des Pfades, wie ich es am liebsten mach.

	Über Postvariablen erzeugt meist nur Unfälle, weil
	die Browser beim Reload - durchaus berechtigt -
	Ärger machen, und weil jedes Navigationselement
	ein Form-Submit sein muss.

	Get-Variablen allerdings haben den schon genannten
	Nachteil, dass sie visuelle Schmerzen in der Adressleiste
	erzeugen. Und der Nutzer bekommt sie gewissermassen
	im Edit-Modus zu sehen, kann sie also nach Belieben
	verändern.

	Der beste Weg,einen Zustand=Variablen von einem
	Klick zum nächsten zu bringen, ist eine Hybridlösung,
	die auch in der PHPlib und in PHP4 realisiert wurde.

	Dort macht man es so:
	1) Wir nehmen Cookies für die Daten
	2) Wenn keine Cookies funktionieren, nehmen wir
	   Get-Variablen

	Das bedeutet zwar, das man am Anfang jeder Sitzung
	ausprobieren muss, ob der Nutzer Cookies hat oder
	nicht, dafür bekommt er aber dann auch die beste
	Lösung geliefert.


	Die bessere Lösung

	Jetzt sind wir also soweit, dass wir einen Zustand,
	wie etwa die Kundennummer des Nutzers, von einer
	Seite zur anderen mitnehmen können.

	Wenn wir pedantisch sind, sind wir damit aber nicht
	zufrieden. Und hey, Coder/Innen sind zwangsläufig
	pedantisch, das ist unser Job.

	Warum sind wir nicht zufrieden ?

	a) die Daten, wie etwa die Nutzernummer, wird
	   ungeschützt bei jeder Seite erneut übertragen.
	   Jeder Mensch, der auf dem Weg vom Kundenrechner
	   zu unserem Server an der Leitung hängt, kann
	   sie mithören.

	b) unser Datenspeicher ist begrenzt. Zum einen
	   kann eine URL maximal 2k lang werden, wird aber schon
	   ab 500 Zeichen etwas unleserlich, zum anderen
	   werden Daten, die der Server längst schon einmal
	   gesehen hat, wieder übertragen, und müssen z.B.
	   wieder überprüft werden. Also: dicker Overhead, das.

	Der Ausweg: die Daten werden nicht auf dem Klienten,
	sondern auf dem Server gehalten, also etwa in einer
	Datenbank, einer Textdatei, im Speicher des Servers
	oder ähnliches.

	Alles, was der Klient sich merken muss, ist der Eintrag,
	den seine Daten in der Datenbank bekommen haben.

	Der wird die "Sessionid" genannt, und den bekommt man
	auch in der Praxis oft in der Adressleiste oder im Cookie
	zu sehen.



	Die eigene Sessionverwaltung

	Es gibt mit der PHPlib eine sehr ausgereifte und gebugfixte
	Sessionverwaltung in einer wunderschön objektgekapselten
	Programmierung.

	Dann gibt es noch die Sessions von PHP4, die Sascha
	Schumann, schnellster PHP-Core-Team-Coder gebaut hat,
	nachdem er die PHPlib ziemlich gut kannte.

	Beide Lösung sind oft in der Praxis erprobt und stabil.

	Trotzdem lohnt es sich immer, eine eigene Variante zu
	schreiben, wegen "NIH".

	"NIH" heisst "not invented here", und hat etwa die folgenden
	Argumente :

	- "Eh ich den Phplib-kram verstanden habe, hab ich eher
	  meine eigene Sessionverwaltung geschrieben."

	- "Wenn ich das selber programmiert habe, versteh ich das
	  viel besser."

	- "Ich lerne so viel beim Programmieren der eigenen
	  Sessionbibliothek, dass es sich für mich persönlich
	  lohnt."

	- "Da muss ich erst so viele Anpassungen an meinen Sachen
	  machen, dass eine eigene Verwaltung schneller gemacht ist"

	- ...



	So, ich hoffe, damit dieser Diskussion ein wenig Redundanz
	entnommen zu haben.

	Wenn ja, "schön", wenn nicht, "war ja klar" ;-) .

	Liebe Grüße, johann