PHP Session dauerhaft halten bis Browser geschlossen wird

leicht-debil

Neu angemeldet
Registriert
13 Aug. 2013
Beiträge
57
Ort
Kassel
Hallo Leute!

Ich habe eine kleine browserbasierte Anwendung, bei der sich User mit Benutzername und Passwort anmelden. Vereinfacht:

[src=php]<?php
session_start();
if($username == "passt" && $passwort == "passt") {
$_SESSION["angemeldet"] = 1;
}
?>[/src]

fortan wird immer so geprüft (vereinfachte Darstellung):

[src=php]<?php
session_start();
if(isset($_SESSION["angemeldet"]) && $_SESSION["angemeldet"] == 1) {
// Alles ok
}
else {
header("Location: http://example.com/timeout");
exit(0);
}
?>[/src]

Mein Problem ist nun das, dass die Sitzungsdauer gefühlt willkürlich erfolgt. Mal fliegt man nach 10 Minuten aus dem System, ein anderes mal erst nach 3 Stunden - egal ob aktiv oder inaktiv. Ich würde das ganze gerne so einrichten, dass die Session jedoch solange aktiv ist, bis der User den Webbrowser schließt. Kurz: Die Session soll in Härtefall nicht automatisch enden, sondern bei Bedarf ewig laufen.

In der .htaccess steht derzeit folgendes:

php_value session.cookie_lifetime 9600
php_value session.gc_maxlifetime 9600

Gemäß phpinfo() werden die Werte auch übernommen:

session.gc_maxlifetime 9600 (Local Value) 1440 (Master Value)

Dennoch scheint es so, als würden die 9600 Sekunden (160 Minuten) nicht effektiv greifen. Wie bereits gesagt: Das ganze wirkt sehr willkürlich.
Kann mir jemand sagen, wie ich die SESSION dauerhaft bestehen lassen kann und ggf. noch mal eine kurze Erläuterung zum Handling geben?
 
hmm wie wäre es mit javascript?
zwei Möglichkeiten vom Browser aus:
1. der Browser verschickt alle 2min eine Anfrage zum Server.
2. Du kannst feststellen wann ein Browser-Fenster bzw Tab geschlossen wird. Dann verschickst du eine Anfrage zum Server und lässt die Sitzung zerstören
 
Wieso sollte hier eine Javascript-Lösung nötig sein?

Wenn du willst, dass die Session bis zum schließen des Browsers anhält, dann reicht es laut , session.cookie_lifetime auf 0 zu setzen.

Zum Debuggen bei Session-Problemen hilft es hierbei auch zu schauen wie die Cookies aussehen. Für Firefox gibt es z.B. das Web Developer Addon.
 
Kurz: Die Session soll in Härtefall nicht automatisch enden, sondern bei Bedarf ewig laufen.
Davon rate ich ab. Der Server kann nicht verlässlich wissen, ob der Browser geschlossen wurde. Ja mit JavaScript kann man da was basteln, was meistens greift, aber Garantien gibt es keine.
Beispiel: Benutzer wird vom Netz getrennt und schließt den Browser. Ohne Internet keine "bin jetzt weg" Nachricht.
Wenn du langfristige Sessions erlauben willst, ok, aber eine Obergrenze sollte dennoch sein. Ein Benutzer, der tagelang nicht aktiv war, wird sich nicht darüber wundern, dass seine Session weg ist.

Aus Perspektive der Sicherheit würde ich dir sogar von Tagen abraten. Halbe Stunde keine Aktivität = Logout.

Ist dir Sicherheit aber zugunsten von convenience völlig Wurst, gibt es da andere Varianten, die nicht auf der Session basieren:
Du kannst zum Beispiel in der DB Tabelle für die Benutzer ein "AuthToken" Feld haben: Beim Login wird das Token in einen Cookie und in die DB geschrieben. Dadurch ist es dauerhaft gelagert und skaliert gut, da jeder User jederzeit nur exakt ein solches Feld hat und sich nicht immer mehr Sessions anhäufen können.

Mal fliegt man nach 10 Minuten aus dem System
Die PHP Session maxlifetime ist eigentlich sehr zuverlässig. Das Manual gibt da allerdings einen Hinweis: Teilen sich mehrere Scripte den Speicherort für ihre Sessions, so ist die maxlifetime die kürzeste aus allen Scripten. D.h. wenn es ein solches gibt und es eine "10 Minuten inaktiv = Logout" Regelung hat, dann hast du die auch. Das würde insbesondere das scheinbar zufällige Verhalten erklären: Das andere Script wurde bei den "haltbaren" Sessions nicht ausgeführt (oder nur so selten, dass der GC nicht getriggert hat).
 
Zuletzt bearbeitet:


Weil ich mich auch mal in das Thema eingelassen habe zwei Links zu Sessions in einer Datenbank, hier mySQL:



zurück zum Thema:

Ich speichere zum Beispiel einen Zeitstempel und vergleiche den mit der akutellen Uhrzeit, ist der Cookie älter als X Stunden, wird der Benutzer beim Besuch der Seite automatisch ausgeloggt um seine Sitzung zu erneuern/sich wieder einzuloggen.

Im weiteren erneuere ich diesen Zeitstempel, sobald Aktivität auf der Seite ist.

Keine Ahnung wie praktikabel das ist, aber es funktioniert soweit, so fern der Cookie nicht manipuliert wurde, das die Sitzungen nicht älter als X sein dürfen und der Nutzer sich neu anmelden muß.

Man kann auch soweit gehen und in der Datenbank vermerken wann der letztem Login/letzter Aktivität des Nutzers gewesen ist und dann entsprechend prüfen ob der letzte Login älter als X ist und rausschmeißen wenn dies der Fall ist. Wobei man der Wert mit der letzten Aktivität verknüpfen sollte um dann die Session gegebenenfalls zu entwerten.
 
Zuletzt bearbeitet:
@theSplit: Ich weiß schon, wie man Sessions über eine Datenbank verwalten kann.
Mir ging es eher um die erste bzw. zweite Aussage von Shodan, nämlich, dass Sessions aus Sicherheitsgründen nicht länger als x laufen sollten.


Dem Nutzer würde ich nur eine Session ID via Cookie liefern das macht PHP übrigens auch, sofern der Nutzer das Setzen von Cookies nicht verbietet.
Serverseitig speicherst du dir (SessionID, NutzerID, Zeitmarke), wobei die Zeitmarke die ist, bis zu der die Session gültig ist:
Zeitmarke = NOW() + "Gültigkeitsdauer"

Der Nutzer braucht dann nur seinen NutzerID und seine SessionID (in einem Cookie).
Ob eine Session gültig ist, entscheidet sich, daran, ob ein (SessionID, NutzerID, *) in der Datenbank übereinstimmt und Zeitmarke >= NOW()
Bei Nutzerinteraktion updated man die Zeitmarke. Je nach Design kann man entweder gleich "outdated" Einträge verwerfen oder man lässt z.B. nachts um 3 einen Cron laufen, der die Datenbank aufräumt.

Man kann aber auch noch weitere Daten zu der Session erfassen, etwa einen Fingerprint des Browsers, geo Informationen etc.
Dann kann man zumindest heuristisch herausfinden, ob der Nutzer gerade seinen Standort gewechselt hat oder ob etwa das Cookie abgefangen wurde.

Ob man nur einen Eintrag pro Nutzer zulässt, hängt vom Anwendungsfall ab. Ggf. sollte ein Nutzer mehrere gleichzeitig geöffnete Sessions haben können. (z.B. bei facebook). In anderen Szenarien kann es sinnvoll sein, dass ein Nutzer über mehrere Geräte hinweg eine Session "mitnehmen" kann. So dass ein Login ohne Cookie dem Nutzer noch mal die gleiche SessionID zuweist, wie die letzte, die im System gespeichert wurde.
 
Zurück
Oben