weitere Frage zum Thema

[ChrisB]

Hi,

Ich will halt nicht nur das nötigste tun damit überhaupt was geht, sondern es richtig machen und auch kapieren was und warum ich da tu.

Na dann mach' dir klar, wie Sessions funktionieren - und schau dir dann anschliessend an, welche Einstellungsmöglichkeiten es gibt (Handbuchseite wurde ja schon genannt), und wie deren Werte sich ggf. beeinflussen.

Das Konzept „Session” dient dazu, einem Client, der über das zustandslose Protokoll HTTP Anfragen stellt, über mehrere nacheinander erfolgende Anfragen hinweg Daten zuordnen zu können.

Dazu musst der Client identifizierbar gemacht werden, denn das wie gesagt zustandslose Protokoll HTTP gibt das nicht her.
Dazu dient die Session-ID. PHP denkt sich beim ersten Start der Session eine aus, und teilt sie dem Client mit. Und der Client schickt sie bei den nächsten Anfragen wieder mit, um sich zu „identifizieren” - ”hey, ich bin der, dem du gerade den Wert 'xyz123...' genannt hast, erinnerst du dich?”.

Es gibt verschiedene Möglichkeiten, die Übergabe dieser Session-ID vom Server an den Client und zurück zu realisieren - wobei man eigentlich nur zwischen den zweien, per Cookie oder anders, unterscheiden muss.

Per Cookie ist klar - Server setzt Cookie, Client akzeptiert diesen und schickt ihn bei allen folgenden Anfragen wieder mit.
Das ist erst mal der Default (in aktuellen PHP-Installationen). Ein paar Details kann man dazu noch einstellen, Parameter, die den Umgang mit dem Cookie beeinflussen (Gültigkeitsdauer, [Sub-]Domain, Pfad, ...)

Wenn der Client keine Cookies akzeptiert, dann muss die Übertragung der Session-ID anders erfolgen - iaR. entweder per GET (bei Links), oder per POST (bei Formularen mit entsprechender Methode).
Das macht PHP seit einiger Zeit nicht mehr per Default automatisch - man muss es extra aktivieren. Dazu schrieb ich in dieser Antwort in der Fussnote schon etwas.

Die Daten, die über die Laufzeit einzelner Scriptinstanzen hinaus erhalten bleiben sollen, müssen natürlich serverseitig auch irgendwo abgelegt werden. Per Default passiert dies im Dateisystem (kann aber auch anderswo sein, bspw. in einer Datenbank oder im RAM; dazu gibt es auch die Möglichkeit, einen eigenen Session-Handler zu definieren, die sich dann um „alles” - Speicherung, Einlesen, Aufräumen alter Daten - kümmern muss) - hier ist die schon erwähnte Einstellung session.save_path von besonderem Interesse, auch in Bezug auf das folgende:

Die Daten, die serverseitig abgelegt werden, müssen natürlich auch irgendwann mal wieder weggeräumt, entsorgt werden. Darum kümmert sich der Garbage Collector - der wird zufallsgesteuert aufgerufen, und löscht die Daten von Sessions, die ihre mit session.gc_maxlifetime angegebene „Lebensdauer” überschritten haben. Diese wird vom Zeitpunkt des letzten Zugriffes (der je nach verwendetem Speichersystem leicht unterschiedlich definiert sein kann) aus gemessen. Wobei die Benennung dieser Option leicht unglücklich ist - denn es handelt sich nicht um eine maximale, sondern eine *minimale* Lebensdauer; alles, was älter ist, *darf* weggeräumt werden, muss aber nicht sofort.
Dass man ggf. den save_path für unterschiedliche Anwendungen auch unterschiedlich definieren möchte, damit sich die „verschiedenen” Garbage-Kollektoren nicht in die Quere kommen, wurde im Thread ja bereits erwähnt.

Wie gesagt, einfach mal ein bisschen im Manual die Beschreibung der einzelnen Optionen durchlesen und schauen, wo sie im geschilderten Konzept „auftauchen” - dann sollte eigentlich das meiste schon klar werden. Wenn noch was unklar bleibt, dann einfach noch mal nachfragen.

Und wenn die Konfiguration dann erst mal den Ansprüchen genügend vorgenommen wurde - dann sind Sessions letztendlich wirklich simpel.
Man muss nur in jedem Script die Session wieder aufnehmen, und hat dann in $_SESSION die in vorherigen, durch den gleichen Client aufgerufenen Scriptinstanzen abgelegten Werten wieder zur Verfügung.

MfG ChrisB