Webhosting 2000: Session Cookie wird anscheinend serverseitig vor Ablauf gelöscht

  • Moin zusammen.


    ich habe in Problem mit einem Session-Cookie in Verbindung mit meinem Webhosting 2000.
    Die Session Standardwerte bei meinem Hosting sind:



    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 no value no value
    session.cookie_lifetime 0 0
    session.cookie_path / /
    session.cookie_samesite no value no value
    session.cookie_secure 0 0
    session.gc_divisor 1000 1000
    session.gc_maxlifetime 1440 1440
    session.gc_probability 0 0
    session.lazy_write On On
    session.name PHPSESSID PHPSESSID
    session.referer_check no value no value
    session.save_handler files files
    session.save_path /var/lib/php/sessions /var/lib/php/sessions
    session.serialize_handler php php
    session.sid_bits_per_character 4 4
    session.sid_length 32 32
    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 1 1
    session.use_only_cookies 1 1
    session.use_strict_mode 0 0
    session.use_trans_sid 0 0

    Nun habe ich per PHP eine Session gestartet und einer Session-Variablen einen Wert zugewiesen:


    Code
    ini_set('session.cookie_lifetime', '40000');ini_set('session.gc_maxlifetime', '40000');ini_set('session.gc_probability', '1');session_set_cookie_params(40000,"/");session_start([    'cookie_lifetime' => 40000,]);
     $_SESSION['login_user'] = $myemail;


    Später wird der Wert (z.B.) bei einem Reload wieder ausgelesen:


    Code
     if(!isset($_SESSION['login_user'])){
          header("location:login.php");
         die();
       }


    Laut den Einstellungen ist der Sessioncookie ja 40000 Sekunden gültig, dies wird mir auch im Browser angezeigt. Leider fliege ich jedoch nach einer unbestimmten Zeit (noch nicht gemessen, ca. 0,5-1 Stunde) wieder raus.
    Hier habe ich die Vermutung, dass die Session serverseitig (z.B. Garbage collection wegen shared Hosting) gelöscht wird.
    Ist das Problem bekannt, bzw. habe ich hier evtl einen Fehler gemacht?

    Danke im voraus.

  • Ich weiß nicht, wie es bei Plesk standardmäßig unter der Haube gehandhabt wird, aber bei Debian (das im Webhosting zum Einsatz kommt) werden dateibasierte Sessions im Standardordner normalerweise durch einen Cronjob gelöscht. Dieser Cronjob greift auf die systemweite Standard-php.ini zurück und weiß nicht, wie hoch Du diesen Wert gesetzt hast.


    Was Du versuchen könntest: Lass den session.save_path auf einen Ordner innerhalb Deines Webspaces zeigen. Dieser sollte natürlich nicht über HTTP erreichbar bzw. geschützt sein!


    Bei einem anderen Speicherort musst Du Dich aber selbst um die Bereinigung alter Sessiondateien kümmern. Ich habe damit noch keine Erfahrung gesammelt, aber die Konfigurationsoptionen session.gc_* sehen ganz vielversprechend aus. Notfalls tut es sicher auch ein Shellscript mit find als Cronjob.


    Wenn etwas unklar ist, einfach nachfragen… :)

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Das geht leider nicht. Sobald ich einen anderen path angebe, bekomme ich einen Error, da dies anscheinend nicht erlaubt ist.

  • Sobald ich einen anderen path angebe, bekomme ich einen Error, da dies anscheinend nicht erlaubt ist.

    Und der wäre? Der Pfad muss logischerweise innerhalb Deiner gewählten open_basedir Einstellung liegen.


    Bei mir funktioniert dieses Beispiel einwandfrei: https://wh-nclabs.fnx.li/session-test/ (Quellcode; Wayback Machine)


    Zum Löschen der alten Sessions sollte sich z.B. folgendes Bashscript als Cronjob eignen, das ist aber ungetestet!

    Bash
    #!/bin/bash
    
    # Nach frühestens 61 Minuten werden alte Sessiondateien gelöscht...
    # Wenn Du es erst einmal nur testen willst, ersetze -delete durch -print.
    find /path/to/your/sessions/ -maxdepth 1 -type f -name 'sess_*' -mmin +61 -delete
    
    exit $?

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Einmal editiert, zuletzt von KB19 () aus folgendem Grund: Links aktualisiert: wh8000-nc.fnx.li -> wh-nclabs.fnx.li

  • Im Plesk-Panel kannst du das nicht ändern, sofern im Dropdown keine alternativen Pfade angezeigt werden. Du könntest den session.save_path in einer .user.ini Datei setzen.

    Danke für den Hinweis. Nur zur Klarstellung:
    1) im Documentroot, also dort, wo ich die Seite aufrufe eine Datei namens .user.ini mit folgendem Inhalt anlegen:
    session.save_path = "sessions"
    2) einen Ordner sessions anlegen.
    3) natürlich sollte der Ordner nicht von außen erreichbar sein, also unterhalb des DocumentRoots liegen

    Das habe ich gemacht, es erscheinen aber keine Dateien im Ordner sessions.
    Habe ich was übersehen?

  • Ich denk mal man wird den absoluten Pfad zum session-Verzeichnis angeben müssen, zudem wird die .user.ini auch nur alle paar Minuten eingelesen und wirkt also nicht sofort.

    Es passiert leider gar nichts.
    Es wird auch leider keine Fehlermeldung ausgeben, obwohl error_reporting an ist.
    Wenn ich über

    echo session_save_path(); den Pfad ausgebe, steht dort immer noch /var/lib/php/sessions
    Ist es denn sichergestellt, dass man dies bei Netcup überhaupt ändern kann?

  • Also bei mir hat es eben bei einem Test auf Anhieb geklappt.

    Code
    $ cat /mysites/domain.de/www/test/.user.ini
    session.save_path = "/var/www/vhosts/hosting123456.axxxx.netcup.net/testsessionfolder"

    Test:


    pasted-from-clipboard.png


    Ggf. bist du in einem Verzeichnis verrutscht oder der (komplette!) Pfad stimmt nicht ganz?

    Ich glaube nicht, ich habe ebenfalls
    session.save_path = "/var/www/vhosts/hosting12345.yyyyf.netcup.net/httpdocs/sessions_bjhxxxxxxxxxxxd"
    in der .user.ini stehen. Das Verzeichnis existiert und hat 777.
    Gibt es in Plesk spezielle Einstellungen bezüglich der PHP-Version oder FastCGI/CGI o.ä.?

    Komischerweise hatte ich beim allerersten Aufruf der index.php in meinem DocRoot die Fehlermeldung, dass das Verzeichnis für session.save_path nicht existiert.
    Die Fehlermeldung war korrekt, da ich mich da tatsächlich vertippt hatte.
    Seitdem kam aber keine Fehlermeldung mehr, egal was ich dort als Pfad eingebe.
    Ich habe daher irgendwie das Gefühl, dass das Einlesen der .user.ini unterdrückt wird.

  • user_ini.filename und user_ini.cache_ttl sind die Einstellungen die festlegen, wie die ini-Datei heissen muss um berücksichtigt zu werden und wie lang die gelesenen Einstellungen gecacht werden, bevor die Datei erneut eingelesen wird. Bei meinen Webhostings steht da im phpinfo():

    Code
    user_ini.cache_ttl   300          300
    user_ini.filename    .user.ini    .user.ini

    Also muss die Datei .user.ini heissen und diese wird dann alle 300 Sekunden eingelesen. Ist kein Filename angegeben, dann wird auch keine Datei eingelesen.

    Du kannst dir ja mal im Plesk die phpinfo() deiner ausgewählten PHP-Version anzeigen lassen. Siehe auch https://www.php.net/manual/de/…uration.file.per-user.php

  • Ich habe es endlich zum Laufen bekommen, wenn auch nur über einen Eintrag in der PHP-Datei:

    ini_set("session.save_path","/var/www/vhosts/hosting123454.xxxx.netcup.net/httpdocs/10001/sessions_bjyyyyyyyd");

    Der Path war nicht innerhalb der open_basedir.
    Leider hat mir PHP dann keinen Error angezeigt.
    Der Path muss natürlich unterhalb der von außen erreichbaren Ordner liegen, aber im Prinzip klappt es schon mal.
    Danke für die Hilfe.

  • Wenn es innerhalb des open_basedir liegt, sollte es auch wieder über die .user.ini problemlos klappen.


    chmod 0777 würde ich übrigens nicht empfehlen. Schreib-/Leserechte braucht definitiv nur PHP: chmod 0700

    Der Path muss natürlich unterhalb der von außen erreichbaren Ordner liegen, aber im Prinzip klappt es schon mal.

    Man kann den open_basedir in Plesk zur Not auch so konfigurieren, dass der ganze Webspace darin enthalten ist.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)