Eine verschwindende Session sieht aus wie ein Anmeldeproblem und ist es fast nie. Die Anmeldung hat geklappt; verloren ging der Beleg dafür, zwischen einer Anfrage und der nächsten.

1. Etwas räumt die Session-Dateien weg

Unter Debian und Ubuntu kehrt ein Timer die PHP-Session-Dateien nach einem eigenen Plan zusammen, nach der Vorstellung der DISTRIBUTION von der Lebensdauer - nicht nach der, die Ihre Seite mit ini_set setzt. Eine Seite, die gc_maxlifetime zur Laufzeit erhöht, ändert an diesem Kehren nichts.

systemctl list-timers | grep phpsessionclean
php -i | grep -E "session.save_path|session.gc_maxlifetime"

Die Abhilfe ist ein eigenes Session-Verzeichnis, das der Kehrer nicht anfasst, mit einer Lebensdauer, die in der Pool-Konfiguration steht und nicht zur Laufzeit.

php_admin_value[session.save_path] = /var/lib/php/sessions-mysite
php_admin_value[session.gc_maxlifetime] = 86400

2. Das Cookie kommt nicht zurück

session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax
cookie_secure auf einer Website, die auch über blankes http erreichbar ist, heißt, dass das Cookie nie zurückgeschickt wird und der Benutzer sofort abgemeldet ist, ohne irgendwo einen Fehler. Auf einer reinen https-Website ist es richtig, auf einer gemischten tödlich.

3. Zwei Server, eine Session

Hinter einem Loadbalancer landet Anfrage eins auf Server A und schreibt dort eine Session-Datei; Anfrage zwei landet auf B, wo es diese Datei nicht gibt. Der Benutzer wird zufällig abgemeldet - die am schwersten nachzustellende Variante.

  • Sessions in Redis oder in der Datenbank, von beiden geteilt.
  • Oder Sticky Sessions am Balancer - funktioniert, überlebt aber nicht, dass ein Server ersetzt wird.

Dabei zusehen

ls -la /var/lib/php/sessions/ | head
# log in, then look again: your file should be there and should stay
Existiert die Datei und der Benutzer ist trotzdem abgemeldet, ist es das Cookie. Verschwindet die Datei, ist es der Kehrer. Diese eine Beobachtung halbiert das Problem.