Session Lifetime
 

Hey!

Ich habe auf meiner Seite ein Login-System, dass auf Sessions basiert.
Es gibt eine zentrale index.php in die alle anderen Seiten includiert werden, deshalb steht am Anfang dieser Datei session_start, sodass es auf jeden aufgerufenen Seite am Anfang steht.

Damit die User sich nicht nach jedem Schließes des Browser und / oder nach längerer Inaktivität neu einloggen müssen, setze ich die Lifetime der Session und die des Cookies (falls der User Cookies aktiviert hat) auf ein Jahr.

Nun ist es aber so, dass sich ja nicht jeder Nutzer, der die Seite besucht, registriert und einloggt. Die Session wird aber auf jeden Fall gestartet.
Nun habe ich mal in meinen tmp Ordner reingeschaut und darin waren Unmengen von Session-Dateien, von denen fast alle leer waren. Da ich aber die Lifetime auf ein Jahr gesetzt habe, räumt die garbage collection natürlich nicht auf.

Jetzt steh ich vor dem Problem, dass ich die Lifetime einer Session nur dann auf ein Jahr setzen will, wenn sich der User auch tatsächlich einloggt.
Da session_start auf jeden Fall am Anfang jeden Scriptes aufgerufen ist, wurde die Session ja bereits gestartet, wenn der User auch nur die Seite aufruft.

Meine Frage ist nun, ob ich das Problem irgendwie umgehen kann, also die Lifetime der Session nur dann auf ein Jahr setzen kann, wenn sich der User auch wirklich einloggt.

Re: Session Lifetime
 

Ich würde ein vernünftiges Auto-Login-System implementieren, d.h. du speicherst im Cookie (dessen Laufzeit du beliebig festlegen kannst) einen String, anhand dessen du in der Datenbank den User finden kannst, und wenn der Cookie gesetzt ist, loggst du den User beim Betreten der Website ein. Und die beiden ini_set-Zeilen wieder raus

Ist zwar eine hübsche Idee die Session aktiv zu lassen, aber nicht wirklich hübsch praktikabel

Re: Re: Session Lifetime
 

sorry, dass ich mich jetzt einklinke.
aber wie wird soetwas allgemein gehandhabt? also was bedeutet in diesem fall "String" - wie setzt der sich zusammen bzw. wie wird er generiert?

Sowas reicht meist als Markierung.
Ist im Grunde auch egal, Hauptsache eindeutig und
schwer zu erraten.

ja klar, passwörter kann man "salzen", aber man muss später auch aus dem cookie-"String" auf einen konkreten account schließen können.
selbst "gesalzte" passwörter können doppelt vorkommen (theoretisch).

ich glaube, ich hab's:
md5-(password mit username als salt) und im cookie noch den username und/oder user_id hinterlegen.
müsste passen - oder?

Der username sollte nicht im Cookie gespeichert werden..!
Das mit dem Salz ist auch relativ unwichtig..
Es dient nur dazu, den md5 String schwerer "vorauszusagen"
du brauchst halt irgendwas, was zufällig genug ist..

So...
Du hast sowieso eine usertabelle mit
ID | nick | email | passwort | usw

Du brauchst zusätzlich eine Tabelle: dauerlogin
dauerloginkey | userid | timestamp

Im Cookie speicherst du dann den dauerloginkey
Damit die Tabelle nicht aus dem Ruder läuft,
solltest du regelmäßig veraltete Einträge löschen.
Wenn dauerloginkey unique-index gesetzt ist, hat sich das
mit den Doppelvergaben auch erledigt..

ok, db-spalte, dachte ich mir schon.

weil du schon mit dem ausrufezeichen ausdrücken möchtest, dass es potentiell unsicher ist (in diesem fall den benutzernamen zu speichern):

ich frage mich, ob man überhaupt einen auto-login zulassen sollte?
die sicherheitslücke internetcafe fällt mir da z.b. spontan ein, ein klick auf [] automatisch einloggen (bild-leser, und nicht nur diese, klicken auf alles mögliche) und alle nachfolger haben zugriff auf meinen account - toll.

Wenn der User im Internetcafe dieses Häkchen setzt, ist er selber Schuld..

Aber du hast Recht!
Man sollte das Autologin keinesfalls zum Standard erheben..!!

Naja Problem ist, dass ich die Daten der Session weiterhin brauche, da dort nich nur Username und Rechte drin stehen.

ich hab's jetzt so gelöst, dass ich das Sessions System selbständig über eine DB verwalte. Damit hab ich ne bessere Kontrolle über die Lifetime der Session und kann sie für den Benutzer einzeln beliebig anpassen.

Grundlage war dieses Tutorial

Ein klares Wort?

Ja dann: Ich halte nix davon !!
1. Du versuchst Sessions für irgendwas zu missbrauchen, wofür sie nicht gedacht sind
2. nicht auf jedem System darfst du einen eigenen Session Handler stetzen
4. nur kurzlebige Daten in Session halten!
3. Langfristige Datenhaltung sollte in der DB stattfinden

Steht wo?

Wüsste nicht wieso das nicht erlaubt sein sollte. Wenn der Hoster die Funktion deaktiviert hat -> Hoster wechseln

Wieso?

Es ist nicht die übliche Verwendung von Sessions, aber ob jetzt ein session-cookie/session oder ein autolog-cookie/der entsprechende Datensatz, auf dem Server "offen" verbleibt, dürfte ziemlich Jacke wie Hose sein ... zumindest bin ich nach 2 Tagen überlegen über diesen Thread zu dem Schluss gekommen

Je länger die Sessions halten, desto mehr offene Sessions werden gehalten..
Je mehr offene Sessions, desto größer die Chance zur versehndlichen Übernahme..

Bei einer Lebenzeit von min 24 Minuten(Standard) ist die Wahrscheinlichkeit geringer, als wenn man das auf 1 Jahr ausdehnt...

Klar könnte man einen fürchterlichen Bug im Konzept, dadurch versuchen auszubügeln, daß man die Sessionverwaltung aufbläht...

Teil der Grundidee von Sitzungen, ist es ja gerade, daß diese auch mal enden.. und das Schließen des Browsers, ist doch der passende Zeitpunkt, warum davon abweichen und dieses wunderschöne Konzept unterlaufen..?:)
:D Wenn es dem Esel zu gut geht, dann geht er aufs Glatteis :D

Ps:
Ich halte nicht viel von Autologin Systemen, bequem, Ja, das ist auch schon das schönste daran..

Das gleiche Problem hat man bei der Auto-Login-ID auch, ist also das gleich in grün

Genau!
Ein riesen Sicherheitsloch!
Aber das kann man auch haben, ohne das arme Sessionhandlig umzukrempeln :D

Du glaubst also, dass ein 32^16 Zufallswert ein riesen Sicherheitsloch ist?
Ich finde das für reines BruteForce schon zu zeitaufwendig...