PHP session.gc_maxlifetime wird nicht übernommen

[Schumiel]

Hallo,

ich habe in meiner php.ini bei session.gc_maxlifetime = 7200 stehen, doch leider löscht sich die Session willkürlich selbst oder es macht, was sie soll. Es ist teilweise Lotterie. Auch seitens meines Providers ist man ratlos.

Die Jahre zuvor hatte ich nie Probleme damit, nun seit einigen Monaten plötzlich, obwohl nichts in jüngster Vergangenheit irgendetwas geändert wurde.

Dadurch, dass ich in meinem Login-System mit Sessions arbeite, loggt es meine User regelmäßig zeitlich willkürlich aus. Ich weiß nicht mehr weiter ...

 

[Yuuri]

Was steht denn in der phpinfo unter local/master value? Besser wäre es allerdings du übernimmst das Session Handling selbst und schreibst in jedem Aufruf nen Wert/Timestamp in deiner Session neu und nutzt dies als Timeout. PHP nutzt nämlich die Modified Time der Session um die Laufzeit dieser zu ermitteln.

 

[Schumiel]

In beiden steht 7200 ...

Vor ein paar Minuten ist mir ein Lösungsvorschlag eingefallen. Da die Cookies aktiv sind/bleiben, kann ich diese doch bei einer leeren Session abfangen oder? Das heißt, ist Session (user-id) leer, fange ich das aktive Cookie dazu ab. Oder zu große Sicherheitslücke?

 

[Yuuri]

Das wird eigentlich alles automatisch über session_start() geregelt (Cookie setzen + Session auf dem Server initiieren bzw. eben die Alte laden). Was sagt session.cookie_lifetime? Hast du ne eigene Sessionverwaltung oder lässt du PHP das handeln? Und was passiert mit der Session ID im Cookie, wenn du mal nur ein Script mit dem Aufruf von session_start() mehrmals im Browser lädst?

 

[Schumiel]

session.cookie_lifetime ist auch auf 7200

Ich habe keine eigene Sessionverwaltung. Ich setze nur bestimmte Cookie-Werte, die ich u.a. für (nützliche) Popups nutze.

Deine letzte Frage verstehe ich leider nicht. Sorry.

Aber der Cookie ist ja noch aktiv. Geht man auf die Startseite meiner Seite, frage ich Cookies ab, so dass die User nur noch Login drücken brauchen.

 

[Yuuri]

Das Cookie Management in PHP wird quasi komplett über session_start() geregelt. Die Funktion setzt das Cookie mit der Session ID im Browser (deshalb muss die Funktion vor der ersten Ausgabe aufgerufen werden, damit die Header dafür gesetzt werden können) und speichert die Session lokal auf dem Server. Wenn diese ein Mal gesetzt ist, greift session_start() auf die ID im Cookie zurück, öffnet diese entsprechend vom Server und setzt mit den Daten in der jeweiligen Datei fort.

Öffne also mal nur eine PHP mit folgendem Inhalt auf dem Server (und ggf. auch in der bestehenden Seite nachprüfen):

<?php session_start();

Diese öffnest du mal im Browser und überprüfst die Session ID im Cookie. Theoretisch sollte sie über den gesetzten Zeitraum gleich sein. Falls sie sich ändert, ist irgendwas verquer. Wenn es dort einen Unterschied zwischen blankem Script und bestehender Seite gibt, kannst du davon ausgehen, dass die Seite irgendwas falsch macht. Wenn die Session ID aber auch im blanken Script geändert wird (außerhalb des Timeouts ist dies ja normal), dann stimmt irgendwas mit der Konfiguration von PHP oder dem Server nicht.

Ne Ausnahme ist hierbei allerdings ein Aufruf von session_regenerate_id(), da dies ne neue ID generiert und die alte verfallen lässt.

 

[Schumiel]

Die Session ID bleibt gleich. Das heißt, ich sollte die Session ID im Cookie speichern und dann bei jedem Seitenaufruf vergleichen? Ist sie unterschiedlich, läuft was quer? Ist diese Sache wirklich nützlich?

Hm, Fakt ist, dass die Session automatisch geleert wird. Nur warum?

 

[Daaron]

Du sollst keine Session ID in einem Cookie speichern. Das macht der Session Cookie, den du mit session_start() erzeugst, automatisch. Du sollst deine Login-Informationen in der Session speichern, so wie sich das gehört.

 

[Schumiel]

Daaron, dass mache ich. Doch die Session wird nicht nach 2 Std. (7200) geleert, sondern willkürlich zu einem früheren Zeitpunkt. Obwohl ich nichts an meinen Loginscripten oder Sessions geändert habe, stehe ich seit einige Zeit vor diesem Problem und suche nun hier nach Rat, weil jeder Lösungsversuch scheitert.

 

[Daaron]

Wie werden die Sessions auf dem Server gelagert? Ich vermute doch mal ganz stark, dass sie im Dateisystem liegen. Dann beobachte das Dateisystem auf Veränderungen. Oder liegen die Sessions im Memcache(d)? Glaube ich zwar nicht bei einem Shared Hoster, aber möglich ist alles...

Andererseits: Bei so endlos viel Paranoia im Netz haben die betroffenen User am Ende einfach laufend den Anonym-Modus ihres Browsers verwendet, dann lebt die Session auch nur, bis man den Browser schließt. DAsselbe gilt für die ganzen Anonymizer-Plugins, die angebliche Spuren im Netz entsorgen sollen.

Ansonsten: Mal suchen, ob du die Session irgendwo zerstörst... session_destroy() kann viel Schaden anrichten, noch mehr Schaden richtet aber setcookie() an.

 

[Schumiel]

1.Absatz: Hm. Da komme ich glaube nicht ran!? Ist doch der Pfad, der im session.save_path angegeben wird oder?
2.Absatz: Nein. Das passiert, wenn die User normal auf meinen Seiten herumklicken. Plötzlich werden sie mit dem nächsten Klick ausgeloggt.
3.Absatz: session_destroy nutze ich nur, wenn man den Logout-Button genutzt hat. Ob ich wirklich setcookie nutze, muss ich heute Abend mal zu Hause schauen. Ich setze zwar Cookies, ob ich da mit setcookie arbeite, weiß ich jetzt nicht.

 

[Schumiel]

@Yuuri: Ich habe nun paar Logs eingebaut. Und ja. Wenn die Session willkürlich "gelöscht" wird, ändert sich auch die session_id(). Und nun?


Hier mal meine php.ini dazu:

session.auto_start	Off	Off
session.cache_expire	180	180
session.cache_limiter	nocache	nocache
session.cookie_domain	no value	no value
session.cookie_httponly	Off	Off
session.cookie_lifetime	7200	7200
session.cookie_path	/	/
session.cookie_secure	Off	Off
session.entropy_file	/dev/urandom	/dev/urandom
session.entropy_length	32	32
session.gc_divisor	100	100
session.gc_maxlifetime	7200	7200
session.gc_probability	0	0
session.hash_bits_per_character	5	5
session.hash_function	0	0
session.name	PHPSESSID	PHPSESSID
session.referer_check	no value	no value
session.save_handler	files	files
session.save_path	/tmp	/tmp
session.serialize_handler	php	php
session.upload_progress.cleanup	On	On
session.upload_progress.enabled	On	On
session.upload_progress.freq	1%	1%
session.upload_progress.min_freq	1	1
session.upload_progress.name	PHP_SESSION_UPLOAD_PROGRESS	PHP_SESSION_UPLOAD_PROGRESS
session.upload_progress.prefix	upload_progress_	upload_progress_
session.use_cookies	On	On
session.use_only_cookies	On	On
session.use_trans_sid	0	0

noch mehr Schaden richtet aber setcookie() an.

Ich nutze setcookie(). Warum richtet das Schaden an?

 

[Daaron]

Ich nutze setcookie(). Warum richtet das Schaden an?

setcookie() KANN "Schaden" an der Session verursachen, da du damit den Session Cookie komplett entsorgen kannst. session_destroy() kann das hingegen nicht.

Im Zweifel hat dein Hoster was falsch konfiguriert und deine Session Files werden nicht korrekt gelöscht (also nach Ende ihrer Lifetime).

 

[Schumiel]

Ich habe gestern "session.save_path" auf einen für mich sichtbaren Ordner (absoluter Pfad) verwiesen. Seither hat kein User mehr Probleme geäußert. Vorher war "novalue" und danach "/tmp", dass nicht half, da ich das von Anfang als Ursache empfand, weil es zu meinem alten Provider als einziges anders konfiguriert war.

 

[Daaron]

Na solange du den Session Save Path jetzt nicht im Webroot liegen hast, wo jeder auf die Session Files zugreifen kann...

 

[Schumiel]

Nein. Ist mit htaccess und deny from all ...

 

[Daaron]

Wäre mir trotzdem zu unsicher. Es reicht schon, wenn dein Hoster von Apache auf nginx wechselt, und jeder kommt an deine Session Files. Selbst ein Upgrade von Apache 2.2 auf 2.4 kann deine Deny-Regel aushebeln, weil es da kleine aber hässliche Untershciede in der Syntax gibt.

 

[Schumiel]

Ok. Wie soll ich das sonst regeln? Der /tmp-Ordner wird regelmäßig gelöscht, ohne Berücksichtigung der Session-Lifetime.

 

[Daaron]

Moment... Ist dein Hoster so Banane drauf, dass er die Session-Files ALLER Kunden in einen gemeinsamen Ordner legt? Bei so etwas kratz ich mich echt am Kopf. Wie kann man eigentlich den PHP Garbage Collector so fehlerhaft konfigurieren? Das Ding läuft auf gängigen, aktuellen Distributionen in Standard-Konfiguration bereits absolut reibungslos...

Die ideale Lösung ist: Mit der Brieftasche abstimmen. Jemand anderes nimmt dein Geld sehr gerne, und bietet bessere Funktionalität & Sicherheit.

Alternativ:
Du hast doch sicher nicht nur Zugriff auf deinen Webroot, sondern auch auf einige Ordner, die parallel dazu liegen, z.B. ein eigener Log-Ordner. Pack dir da einen Ordner rein und verwende ihn als Session Save Path.


Du solltest definitiv mal schnüffeln, was dein Hoster alles für Leichen im Keller hat. Welches OS und welche Versionen kritischer Bauteile (PHP, Apache, MySQL, OpenSSL,...) werden verwendet? Mindestens PHP & Apache solltest du über phpinfo(); heraus finden können.
Wer so mies konfiguriert wie dein Hoster, der hat da noch viele andere Baustellen, die die dei Sicherheit deiner Daten (und damit dein Geld) stark gefährden.

 

[Schumiel]

Ja, ist session.save_path nicht gesetzt, werden alle Sessions der Kunden auf dem Server in /tmp gespeichert und dann regelmäßig gelöscht.

Danke für deine weiteren Infos. Leider habe ich nur Schreibrechte im Webroot-Ordner. Alles darunter keine. Ich habe jetzt meinen Hoster gebeten, mir einen Ordner anzulegen, der nicht regelmäßig gelöscht wird.