Wie lange bleibt eine Session am Server gespeichert?

Hi!

Ich frage mich, wie lange ein Webserver eine Session speichert. Wenn ich dem Clienten zB. ein Cookie mit der SID setze, mit einem Jahr Laufzeit, speichert der Server die Session dann auch ein Jahr lang?
Kommt mir irgendwie komisch vor. Das würde doch auf Dauer extrem Resourcen fressen, oder nicht?
Aber sonst wären Cookies über einen längeren Zeitraum ja unnütz, wenn der Server eh nicht länger als, was weiß ich, X Stunden/Tage speichert.

Und wenn der Webserver mal rebootet wird? Ist es da üblich, vorher ein Session-Backup zu machen? Gibt es sowas überhaupt?

Danke im Voraus!

zwutz

Die Laufzeit ist begrenzt, hängt aber im Endeffekt immer davon ab, wie es implementiert wird.
Ein Cookie hat eine feste Laufzeit. Danach wird es automatisch gelöscht bzw. zumindest ignoriert. Serverseitig ist oft ein recht kurzer Timer (im Minutenbereich) integriert, nach dessen Ablauf die Session gelöscht wird. Der Timer wird dabei bei jeder Anfrage zurückgesetzt

Das heißt, man kann u.U. gar keinen "1-Jahr"-Login realisieren?
Ein Minutenbereich ist doch total unsinnig...

Ich möchte eine Registrier/Login-Funktion schreiben, und Mitglieder sollen sich halt nicht jedes mal neu einloggen müssen...

Tobiking2

Session schrieb:

Das heißt, man kann u.U. gar keinen "1-Jahr"-Login realisieren?
Ein Minutenbereich ist doch total unsinnig...

Ich möchte eine Registrier/Login-Funktion schreiben, und Mitglieder sollen sich halt nicht jedes mal neu einloggen müssen...

Du musst halt etwas anderes im Cookie speichern als die Session ID. Meistens wird die Benutzer ID und das Passwort in irgendeiner verschlüsselten Form gespeichert.

Mhm, verstehe.
Aber dann könnte ich gleich sämtliche Session-Funktionen weglassen und nur setcookie()/$_COOKIE[] verwenden, nicht?
Ich find es schöner, wenn im Cookie nur die SID gespeichert ist.

Wo am Webserver konfiguriert man diese Session-Laufzeit? Hat aber nix mit diesen Einstellungen zu tun, oder?:

session.cache_expire, session.gc_divisor, session.gc_maxlifetime, session.gc_probability... also der php.ini Kram.

Tobiking2

Session schrieb:

Mhm, verstehe.
Aber dann könnte ich gleich sämtliche Session-Funktionen weglassen und nur setcookie()/$_COOKIE[] verwenden, nicht?
Ich find es schöner, wenn im Cookie nur die SID gespeichert ist.

Cookies werden auf dem Client gespeichert und sind (normalerweise) langlebig. Sessions sind auf dem Server gespeichert und sind kurzlebig. Man sollte das nutzen was sich besser eignet.

Wenn du viele Daten speichern musst, macht es wenig Sinn diese als Cookie zu speichern, die der Client bei jeder Anfrage mitsenden muss. Bei Foren werden die Login Daten im Cookie gespeichert, aber nach dem Login (oder auch wenn man nicht angemeldet ist) wird eine Session angelegt in der alles andere liegt.

Session schrieb:

Wo am Webserver konfiguriert man diese Session-Laufzeit? Hat aber nix mit diesen Einstellungen zu tun, oder?:

session.cache_expire, session.gc_divisor, session.gc_maxlifetime, session.gc_probability... also der php.ini Kram.

Doch, das sollten genau diese Einstellungen sein. Der Garbage Collector geht regelmäßig die Sessions durch und löscht die abgelaufenen.

Ach, auf meinem webhoster werden alle 24 Stunden die Sessions gelöscht.
Ich möchte es nun anders machen:

MySQL Tabelle mit Username/Password/CookieHash.
CookieHash ist anfänglich Null.

User loggt sich ein. Dabei wird ein CookieHash erzeugt (übrigens bei jedem Login neu, zur Sicherheit), der Tabelleneintrag entsprechend gesetzt und der Wert per Cookie an den Browser geschickt.

Für Skripte meiner Website ist der User nun eingeloggt, wenn $_COOKIE["cookieHash"] in einem Tabelleneintrag gefunden wird. Username und eventuell weitere Daten können dann ja zugeordnet werden.

User loggt sich aus. Cookie wird gelöscht und Tabelleneintrag CookieHash wieder auf Null gesetzt.

Äh, ist das wirklich so einfach? Oder gibt es da eine Sicherheitslücke? Oder andere Probleme? Ich seh da grade keine.

Und ob ich weitere Daten wie zB. die bevorzugte Sprache im Cookie oder der Datenbank speichere, ist egal, oder? Kommt halt auch auf die Daten/Menge an.

Danke!

zwutz

so in etwa würde ich es auch machen. Die Session-ID (oder etwas vergleichbar eindeutiges) beim Login in der DB und als Cookie auf dem Client speichern.

Kommt ein User auf die Seite wird das Cookie abgefragt und der entsprechende User eingeloggt. Zur Sicherheit würde ich noch ein paar weitere Informationen mit abspeichern, um ihn besser identifizieren zu können (Betriebssystem, Browser, User-Agent, etc)

Und ja, es ist eine Sicherheitslücke. Vor allem, wenn dritte Zugriff auf den PC haben. Deswegen sowas nur als Option anbieten, die standardmäßig deaktiviert ist

Da fällt mir ein... ich möchte ja für einen nicht eingeloggten user nicht bei jedem Seitenaufruf den Hash im Cookie in der Usertabelle suchen (Es könnte ja sein, dass ein Cookie mit dem namen "sessionHash" (oder whatever) existiert, aber mit einem Wert, welcher nicht gefunden wird, dann würde ständig abgefragt und der user nie eingeloggt werden).
Wo soll ich speichern, ob das bereits abgefragt wurde? Bleibt $_COOKIE erhalten? Wohl eher nicht. $_SESSION will ich nicht verwenden, weil ich dann auch für nicht eingeloggte user immer oben im Link die session-ID übergeben müsste. Find ich jetzt nicht so toll..

Danke!
MfG

Hmm, den Cookiewert auf Null setzen ist nicht 100% sicher, oder? Denn wenn der Browser ein Cookie sendet, heißt das ja nicht, dass er auch eines akzeptiert?!
Ich möchte einfach ständige Datenbankabfragen vermeiden, ist ja klar...

Wenn ich recht überlege, gibt es doch sonst keine Möglichkeit.
Entweder immer eine Session behalten, auch für nicht eingeloggte user, oder das "Risiko" eingehen, dass ein user einen sessionHash als cookie hat, welcher nicht gefunden wird.

Wobei das echt selten der Fall sein dürfte, nämlich nur dann wenn...

... der user den Wert manuell ändert (selbst Schuld)
... der user inzwischen aus der Datenbank gelöscht wurde, nicht aber das cookie

Und so teuer ist diese Abfrage auch wieder nicht, oder (bei wahrscheinlich dauerhaft < 100 users):

$statement = $databaseHandle->prepare("SELECT name FROM users WHERE sessionHash = :sessionHash");
$statement->bindParam(":sessionHash", $sessId, PDO::PARAM_STR);
$statement->execute();

zwutz

wenn die Session aus dem Cookie nicht gefunden wurde, Cookie löschen
wenn kein Cookie gefunden wurde entweder das suchen in der DB ersparen oder eine Session anlegen. Das Cookie wird nach Ablauf der Session wieder gelöscht und du musst die ID nicht ständig als URL-Parameter mitliefern (es sei denn, der Client akzeptiert keine Cookies)

Für die Datenbankperformance: Die ID nicht direkt in der Benutzertabelle speichern, sondern eine zweite Tabelle mit User-ID, Session-ID und evtl. Sessionlaufzeit bzw weiterer Daten anlegen. Den Index auf die Session-ID legen und dann sollte das auch bei großen beständen fix genug gehen. Vorteil an der zusätzlichen Tabelle ist, dass inaktive Nutzer nicht die Abfrage verlangsamen können. Es sind nur die User mit aktiver Session in der Tabelle.
Dann einfach regelmäßig alle Einträge, deren Session abgelaufen ist, entfernen

Cookie löschen geht aber nicht, wenn der Browser keine Cookies akzeptiert. Darum gehts ja.
Aber mit diesem Sonderfall finde ich mich ab.

In meinem Fall werden es auch höchstwahrscheinlich dauerhaft unter 100 user bleiben, da brauche ich wohl keine weitere Tabelle, zumal das automatische Löschen auch wieder ein Problem wäre, denn mein webhoster erlaubt zB. keine includes in Skripten, die per Cronjob aufgerufen werden

zwutz

Session schrieb:

Cookie löschen geht aber nicht, wenn der Browser keine Cookies akzeptiert. Darum gehts ja.
Aber mit diesem Sonderfall finde ich mich ab.

dieser Sonderfall wird in der Regel damit abgegolten, dass derjenige eben einen URL-Parameter akzeptieren muss. PHP handelt das aber afair automatisch, wenn du eine Session startest

zumal das automatische Löschen auch wieder ein Problem wäre, denn mein webhoster erlaubt zB. keine includes in Skripten, die per Cronjob aufgerufen werden

das muss kein Cronjob sein. Bevor du die Session aus der DB holst, entfernst du einfach alle veralteten aus der DB und machst erst dann deine eigentliche Anfrage. So ist definitiv nie ein veralteter Eintrag drin und du sparst dir die Abfrage nach der Gültigkeit

Wenn du eh vorhast die Session in einer DB zu speichern, würde ich empfehlen, das du dir mal session_set_save_handler anschaust.

Damit kannst du die Funktionen zum speichern der session ersetzen.

Dadurch kann man die sessions ganz leicht von dem dateisystem des servers in eine datenbank verlegen. Da man dabei auch eine funktion zum gc schreiben muss, kannste natürlich auch die max_lifetime ignorieren.

Hab auf die schnell ein kleines Beispiel gefunden: http://www.tonymarston.net/php-mysql/session-handler.html

Is vielleicht nicht das beste, aber dabei solltest alles in erfahrung bringen können, das du brauchst.

Danke erstmal.

Ne, ich hab nicht vor, die Session in der DB zu speichern.

MfG