PHP 7 - STORE_SESSIONS mysql funktioniert nicht

[Volker Strähle]

Konnte das jetzt auf 2 Rechnern (PHP 7.03 und 7.04) testen. Bei Einstellung StoreSession mysql kommte eine weiße Seite. Speichert man die Session im Dateisystem funktioniert der Shop.

Interessant ist folgender Error von Apache auf meinem Xampp 7.04:

[Fri Mar 11 09:18:56.402670 2016] [mpm_winnt:notice] [pid 16816:tid 492] AH00428: Parent: child process 25200 exited with status 3221225725 -- Restarting.
[Fri Mar 11 09:18:57.551677 2016] [ssl:warn] [pid 16816:tid 492] AH01909: www.example.com:443:0 server certificate does NOT include an ID which matches the server name
[Fri Mar 11 09:18:57.589698 2016] [mpm_winnt:notice] [pid 16816:tid 492] AH00455: Apache/2.4.18 (Win32) OpenSSL/1.0.2e PHP/7.0.4 configured -- resuming normal operations

Was das mit ssl zu tun hat erschließt sich mir noch nicht.

[INETvisio]

Hallo,

Ich müsste in der Funktion bei mir irgendwelche Abfragen ändern: _sess_read
Bei mir hat die Funktion eine Endlos-Schleife produziert.

Ich bin mir unsicher, ob das der Fix sogar gewesen ist:

     if (!isset($value['value'])) {
        return '';
      }
      if ($value['value'] != '') {
        return base64_decode($value['value']);
      }

Vielleicht wird es euch weiter helfen.

Gruß
Jürgen H.

[Volker Strähle]

Kann kurz bestätigen, dass das mit diesem Code (includes/functions/sessions.php) funktioniert:

     //if (isset($value['value']) && $value['value']!='') {
        //return base64_decode($value['value']);
      //}
      // PHP7 - Session-Fix - Start
	   if (!isset($value['value'])) {
        return '';
      }
      if ($value['value'] != '') {
        return base64_decode($value['value']);
      }

[Volker Strähle]

Es gibt wohl auch noch ein Problem mit PHP 5.6, welches auch Problem hat wenn die Session in der DB gespeichert wird: ​Nach Datenbank update keine Anmeldung möglich

[Gerhard Waldemair]

In 9793:

fix #798

[Volker Strähle]

Beim Aktualisieren der Session wird kein Update des Users in der Tabelle whois_online durchgeführt. Das passiert erst nach Redirect durch die application_top.

Zugriffe auf login_admin.php werden überhaupt nicht in whois_online geschrieben.

Generell ist die sessions.php so wichtig, dass nicht notwendige Operation dort nur abgesichert ausgeführt werden sollen um im Fehlerfall die weitere Ausführung sicherzustellen.

try{
	xtc_db_query("DELETE FROM ".TABLE_CUSTOMERS." WHERE customers_id = '".(int)$customers['customer_id']."'");
	xtc_db_query("DELETE FROM ".TABLE_ADDRESS_BOOK." WHERE customers_id = '".(int)$customers['customer_id']."'");
	xtc_db_query("DELETE FROM ".TABLE_CUSTOMERS_INFO." WHERE customers_info_id = '".(int)$customers['customer_id']."'");
	xtc_db_query("DELETE FROM ".TABLE_CUSTOMERS_IP." WHERE customers_id = '".(int)$customers['customer_id']."'");
}
catch (Exception $e) {
	trigger_error($e->getMessage());
}

und

// update whos_online
try{
    xtc_db_query("UPDATE " . TABLE_WHOS_ONLINE . "
            SET session_id = '".xtc_db_input($new_session_id)."' 
            WHERE session_id = '".xtc_db_input($old_session_id)."'"); 
}
catch (Exception $e) {
    trigger_error(  $e->getMessage());
}

[Gerhard Waldemair]

SQL Fehler werden bereits getriggert. Daher sehe ich keine Notwendigkeit hier doppelt Fehler zu catchen.

Die login.php wurde bereits erweitert und bei einem Login über die login_admin.php wird auch der Eintrag in die Whos Online Tabelle gemacht.