Wie lange bleibt eine Session am Server gespeichert?

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