Session erzeugen und löschen...?

[Sven Rautenberg]

Moin!

Zum Starten:

session_start();

Dann weise ich zwei Variablen Werte zu:

$_SESSION['nick'];
$_SESSION['passwort'];

auf die ich dann später immer zugreife. Bis hierhin müsste das auch noch alles sehr sicher sein.

Die Frage der Sicherheit kann nur dann eine Antwort erhalten, wenn auch gesagt wird, vor was geschützt werden soll. Wenn ich einen Lastwagen mit Nitroglyzerin auf einem Parkplatz abstelle, ist das auch erstmal sehr sicher - nur eben nicht, wenn der Parkplatz öffentlich zugänglich ist (Diebstahlswahrscheinlichkeit) und in einem Erdbebengebiet liegt (Explosionswahrscheinlichkeit).

Aber wie sieht das aus mit dem ausloggen? Bisher habe ich die Sessions lediglich so beendet:

session_destroy();

Jetzt habe ich gehört, dass man vorher noch die einzelnen var's aufheben soll und zwar mit unset();

also

unset($_SESSION['nick']);
unset($_SESSION['passwort']);

Ansonsten würden diese wohl erst gelöscht werden wenn die Seite die "session_destroy();" beinhaltet zuende geladen ist...?

Hörensagen und Unkenntnis über das Session-Konzept führen mitunter zu merkwürdigen Stilblüten. :)

Nun habe ich noch gelesen das ich das session cookie löschen soll, das war mir aber neu? wieso cookie? ich dachte bisher ich arbeite mit sessions und nicht mit cookies? und wieso löschen?

PHP setzt ein Cookie, um den Browser zu veranlassen, die Session-ID immer wieder mitzusenden beim Seitenrequest. Als Hilfsmethode, falls Cookies nicht zugelassen werden, wird die Session-ID auch an alle Links und Formulare automatisch drangehängt (kann man auch deaktivieren).

Quelle ist hierbei php.net, dann wird das alte so genannte SessionCookie nicht gelöscht? Zumindest zeigt das meine Anzeige im Firefox an. Wenn ich immer wieder auf einloggen und ausloggen klicke sammeln sich ganz viele SessionCookies in der Liste bis ich die Liste einmal schließe und wieder öffne? Ich habe bei vielen anderen Seiten gesehen, dass sich diese SessionCookies oder auch Sessionids beim Logout gar nicht ändern, muss das also sein? wenn ja wieso?

Ich erkläre dir mal, wie ich mit Sessions umgehe.

1. Ich betrachte eine Session immer als existent. Da kommt ein User mit seinem Browser an, und ich gehe davon aus, dass der eine Session hat. Und das stelle ich sicher, indem jede PHP-Seite session_start() aufruft. Um weitere Details kümmere ich mich nicht, das erledigt PHP von selbst.

2. Weil eine Session immer als existent betrachtet wird, kümmere ich mich nicht um das Löschen des Session-Cookies. Der wird von ganz alleine gelöscht werden, wenn der User den Browser schließt. Außerdem: Welchen Vorteil soll das bringen? Der User kennt seine Session-ID, wenn das Cookie nicht gelöscht wird, kommt er mit derselben Session-ID unter Umständen nach mehreren Stunden Pause erneut zum Server. Dasselbe kann aber auch passieren, wenn die Session-ID in der URL steht. Es kann sowieso grundsätzlich passieren, wenn jemand mit Manipulationswillen die Session-ID irgendwie anders registriert, auf einen Zettel schreibt, und später erneut verwendet. Die Abwesenheit des Cookies bringt mir absolut gar nichts - ich betrachte Sessions immer als existent. Wenn ich nicht will, dass jemand nach einer Stunde Pause ohne erneute Anmeldung weitermachen kann, dann regle ich das programmtechnisch in PHP, indem ich die Zeit des letzten Zugriffs, der in der Session gespeichert wurde, mit der aktuellen Zeit vergleiche. Wenn das zu lange her ist, reagiert das Skript entsprechend.

3. Weil eine Session immer als existent betrachtet wird, gibt es keinen Grund, die Session-Daten in $_SESSION zu löschen - außer der Skriptablauf und die Benutzeraktion ergeben das. Sprich: Wenn das Skript erkennt, dass jemand eingeloggt ist, weil sein Username und Passwort in der Session stehen, und er loggt sich wieder aus, dann ist es natürlich sinnvoll, diese zwei Informationen aus der Session zu löschen. Und auch alles andere, was nur im Zusammenhang mit einem gültigen Login zugriffsfähig sein soll. Sessions selbst haben aber mit dem Login nichts zu tun. Sessions existieren immer. Aber nur manche Sessions haben den Zustand "User ist eingeloggt". Alle anderen Sessions haben logischerweise den Zustand "User ist nicht eingeloggt" - trotzdem bleiben die Sessiondaten in $_SESSION im Grundsatz unberührt, geändert wird nur der Teil, der aufgrund der Zustandsänderung neu hinzugefügt oder entfernt werden muß.

4. Die Garbage Collection von PHP sorgt dafür, dass zu alte und unbenutzte Session-Daten automatisch gelöscht werden. Diesem Mechanismus kann man vertrauen. Man kann ihn auch seinen eigenen Anforderungen anpassen, indem man die Aufräumwahrscheinlichkeit höher setzt (zu Lasten der Performance) oder die minimale Lebenszeit dieser Daten anpaßt.

Von den diversen Session-Funktionen benötigt man im Alltag eigentlich nur diese:

session_start() - selbsterklärend...
session_name() - liefert den Session-Namen (Standard wäre PHPSESSID, das ist aber konfigurierbar)
session_id() - liefert die aktuelle Session-ID

Für Anwendungen, die einen hohen Sicherheitsbedarf haben, die beispielsweise nicht durch vorgefertigte ID-Links angreifbar sein sollen:
session_regenerate_id() - führt die Session fort, aber unter einer neuen ID. Sollte man beim Login durchführen.

Alle anderen Funktionen sind entweder veraltet und sollten nicht mehr verwendet werden (session_register etc.) oder sind speziell darauf ausgelegt, die Sessiondaten in Eigenregie zu speichern (z.B. in einer Datenbank).

Gerade zu session_destroy() steht nach meiner Ansicht im Handbuch ziemlich viel Merkwürdiges, ganz besonders in den Benutzeranmerkungen, aber auch im offiziellen Text. Sowas ist allerdings normal und erklärlich: Die Programmierer dieses Features sind nicht unbedingt diejenigen, die das Handbuch geschrieben und überarbeitet haben. In die Handbuchtexte fließen die Userkommentare aber mit ein, was grundsätzlich eine gute Sache ist, denn nur dadurch werden unklare oder lückenhafte Stellen deutlicher. Aber wenn es um Features geht, die sowohl den Usern als auch den Handbuchschreibern im Prinzip unklar sind, und die auch niemand so richtig enthusiastisch testet und durch Quelltextanalyse verifiziert, dann kommt so ein unausgegorenes Produkt heraus.

- Sven Rautenberg