Sven Rautenberg: session.use_trans_sid verhindert Zerstören der Session

Beitrag lesen

Moin!

aber da ich mit $_SESSION=array(); und session_unset(); die daten vernichte, müsste trotzdem die session als beendet angesehen werden.

Allerhöchstens wird die Session mit leeren Werten fortgesetzt.

Sessions funktionieren unter PHP so:
Es wird ein Request registriert. Dieser startet ein Skript. Das Skript setzt möglicherweise mit session_name() einen Namen. Dann kommt session_start().

An diesem Punkt wird nachgeschaut, ob der Client in irgendeiner Weise eine Session-ID übergeben hat. Wahlweise per Cookie, GET-Parameter oder POST-Formularfeld.

Wenn in diesen Daten ein Parameter gefunden wird, der den aktuell von session_name() gesetzten Namen hat, wird der Parameterwert, der zugewiesen wurde, als session_id() verwendet. Das bedeutet, dass in dem temporären Verzeichnis, in dem die Session-Dateien abgelegt werden (das kann man natürlich ändern - sowohl das Verzeichnis, als auch die Tatsache, dass die Daten in einer Datei abgelegt werden - Datenbanken sind ebenso möglich), nach einer Datei gesucht wird, die "sess_SESSIONID" heißt. Wenn also eine PHP-generierte Session-ID genutzt wird, heißen solche Dateien gerne "sess_27878F27D787EBA6F..." oder so.

Bei session_start() wird also geschaut, ob eine Datei mit passender Session-ID existiert, und wenn ja, wird ihr Inhalt in die Variable $_SESSION gepackt.

Wenn du nun also verhindern willst, dass Leute nach Beenden der Session einfach weitermachen können, mußt du in den Session-Daten irgendwie ein Flag oder eine Information setzen, dass der Benutzer erfolgreich eingeloggt wurde. Diese Information mußt du wieder entfernen oder auf Null setzen, wenn der Benutzer sich ausloggt. Und dann natürlich bei jeder Seite, die das Login erfordert, prüfen, ob der Benutzer das Login-Kennzeichen noch gesetzt hat.

Du kannst dich jedoch keinesfalls darauf verlassen, dass mit session_destroy() bzw. dem in PHP eingestellten Timeout der Session die Daten wirkungsvoll gelöscht würden. Das Timeout ist nämlich zusätzlich noch von einem Zufallsfaktor abhängig. Standardmäßig wird statistisch nur bei jedem hunderdsten Skriptzugriff geprüft, ob irgendwelche Sessiondateien zu alt sind. Auf einer Site mit wenig Verkehr kann eine alte Session also schon mal gern zwei Tage oder drei Wochen auf dem Server liegenbleiben. Wenn du intern dann keinen Timeout-Mechanismus eingebaut hast, kriegst du ein Problem.

Du hast immer noch nicht genau gesagt, was nicht funktionieren soll. Das solltest du mal genau nachholen. Inkl. Codebeispiel/-ausschnitt.

- Sven Rautenberg

--
"Beim Stuff für's Web gibts kein Material, was sonst das Zeugs ist, aus dem die Sachen sind."
(fastix®, 13. Oktober 2003, 02:26 Uhr -> </archiv/2003/10/60137/#m338340>)