nicht angemeldet
Dauerhafter Login, Session Lifetime?
Hallo zusammen,
eine Webanwendung hat ein Loginsystem. Es speichert den Login des Users mit einer eindeutigen UIN und einem Ablauf- Zeitstempel in einer DB.
Die UIN, Anwendername und anderes wird in einer Session gespeichert. Die UIN und Username wird dann mit der DB verglichen.
Angenommen man wollte ein dauerhaftes Login von einem Jahr.
$ablauf = time() + + 60*1440*365; //wäre ein Jahr
Das würde dann für den DB Eintrag ja reichen.
Man müsste doch aber auch vermutlich dafür sorgen, dass die Session auf dem Server überhaupt so lange "lebt" oder?
Per Default ist bei meinem Test XAMPP folgendes eingestellt:
session.gc_maxlifetime = 1440
session.gc_probability = 1
session.gc_divisor = 1000
Wenn ich nun zum Test die Session Werte wie unten ändere und das Datum auf den 10.12.2014 einstelle und danach den Apache neu starte, ist die Session aber trotzdem noch da
session.gc_maxlifetime = 1440
session.gc_probability = 100
session.gc_divisor = 1
Wann wird die Session denn tatsächlich gelöscht?
Würde es denn reichen wenn man die "maxlifetime" auf ein Jahr erhöht, damit auch die Session immer noch da ist?
session.gc_maxlifetime = 31556926
session.gc_probability = 1
session.gc_divisor = 1000
vielen Dank und viele Grüße
hawk
-
Tach!
Angenommen man wollte ein dauerhaftes Login von einem Jahr.
$ablauf = time() + + 60*1440*365; //wäre ein JahrOder ohne Kommentar lesbarer:
$ablauf = strtotime('now +1 year');Man müsste doch aber auch vermutlich dafür sorgen, dass die Session auf dem Server überhaupt so lange "lebt" oder?
Ja, wenn du PHPs Session-Mechanismus verwendest. Du kannst aber auch einen eigenen implementieren.
Wenn ich nun zum Test die Session Werte wie unten ändere und das Datum auf den 10.12.2014 einstelle und danach den Apache neu starte, ist die Session aber trotzdem noch da
Noch da oder eine neue mit derselben Session-ID angelegt?
Wann wird die Session denn tatsächlich gelöscht?
Bei jedem session_start() sollte der GC-Mechanismus loslaufen und gemäß der eingestellten Werte aktiv werden.
Würde es denn reichen wenn man die "maxlifetime" auf ein Jahr erhöht, damit auch die Session immer noch da ist?
Du musst auch dafür sorgen, dass keine parallel laufende Anwendung deine Session-Daten mit aufräumt, nur weil deren GC-Parameter anders eingestellt sind. Dazu solltest du jeder Anwendung einen eigenen session.save_path geben.
dedlfix.
-
Hallo dedlfix,
danke dir.
Du musst auch dafür sorgen, dass keine parallel laufende Anwendung deine Session-Daten mit aufräumt, nur weil deren GC-Parameter anders eingestellt sind. Dazu solltest du jeder Anwendung einen eigenen session.save_path geben.
Ja das habe ich eben gemerkt, als ich zum Test die Lifetime auf 60 Sek. umgestellt hatte, dann etwas wartete und dann nicht mit meiner Anwendung, sondern mit PHPMyAdmin etwas gemacht hatte. Daraufhin war dann die Session Datei von der Webanwendung gelöscht.
Per Default ist beim Xampp das /Xampp/tmp Verzeichnis für die Sessions. Wie aber will man das dann machen, wenn z.b. 10 verschiedene Anwender mit der Webanwendung arbeiten? Es liegen dann 10 verschiedene Session Dateien im tmp Verzeichnis. Nach Ablauf der Session Zeit und wenn ein Anwender wieder was im Browser macht, (und Session_start() auslöst) werden doch die anderen Session Dateien auch gelöscht?
vielen Dank und viele Grüße
hawk-
Tach!
Dazu solltest du jeder Anwendung einen eigenen session.save_path geben.
Per Default ist beim Xampp das /Xampp/tmp Verzeichnis für die Sessions. Wie aber will man das dann machen, wenn z.b. 10 verschiedene Anwender mit der Webanwendung arbeiten? Es liegen dann 10 verschiedene Session Dateien im tmp Verzeichnis.Anwender sind nicht das Problem. Deren Script-Aufrufe starten zwar auch den GC, aber der GC löscht die Dateien der anderen auch nur dann, wenn sie das Verfallsdatum überschritten haben. Der GC ermittelt das aus dem Änderungsdatum der Session-Datei plus Max-Lifetime. Und das ist auch richtig so. Wenn ein Anwender nicht mehr wiederkommt, muss ja sein Kram auch mal irgendwann weggeräumt werden. Das besorgen dann zu gegebener Zeit die anderen Session-Starts.
Was nicht möglich ist: jedem Anwender seine eigene Ablaufzeit geben zu wollen - jedenfalls nicht mit dem eingebauten GC.
dedlfix.
-
-
-
Moin!
Die UIN, Anwendername und anderes wird in einer Session gespeichert. Die UIN und Username wird dann mit der DB verglichen.
Angenommen man wollte ein dauerhaftes Login von einem Jahr.
$ablauf = time() + + 60*1440*365; //wäre ein Jahr
Das würde dann für den DB Eintrag ja reichen.
Man müsste doch aber auch vermutlich dafür sorgen, dass die Session auf dem Server überhaupt so lange "lebt" oder?Wenn du so ein "remember my login" bauen willst, du es nicht in die Session.
Erstens: Das Session-Cookie geht beim Schließen des Browsers verloren.
Zweitens: Die PHP-Session-Daten sind ebenfalls dafür gedacht, nach einer nicht so langen Zeit der Inaktivität gelöscht zu werden.
Drittens: Es bringt dir außer verbrauchtem Speicherplatz auch keinen Vorteil, wenn du Sessiondaten mindestens ein Jahr lang aufbewahrst - insbesondere, weil du damit vermutlich auch Daten aufbewahrst, deren Sinn durch Programmveränderung verloren gegangen ist, weil sie nicht mehr gebraucht werden, sondern z.B. anders abgespeichert wurden. Umgekehrt musst du in allen Programmteilen damit rechnen, dass die Datenstrukturen von vor einem Jahr auf deine aktuelle Software treffen, und dass es bei Änderungen in der Software zu inkompatiblen Situationen kommt.Die korrekte Herangehensweise wäre, dem User ein lange lebendes Cookie zu geben, in dem ein sehr langer, kryptografisch zufälliger String enthalten ist. Dieser String gilt als Ersatz für Username plus Passwort und erlaubt ebenfalls den Zugriff genau so, wie ein normales Login.
Das Session-Handling für's Login wird etwas erweitert: Wenn ein User auf eine zugriffsgeschützte Seite zugreifen will, aber in seiner Session noch nicht eingeloggt ist, schaut die Website nach diesem langlebigen Cookie. Existiert es, und ist es in der Datenbank als gültiger String für einen User gespeichert, wird dieser automatisch so eingeloggt, wie es auch durch Username und Passwort geschehen würde. Andernfalls erscheint die normale Login-Seite.
Natürlich kann man das auch weiter an den Anfang des Besuchs rücken, und schon beim ersten Kontakt und einer (dann noch) leeren Session das Cookie suchen und ggf. den User sofort einloggen.
- Sven Rautenberg