was kann das Beenden der PHP-Session im Frontend auslösen?
Kunde ist eingelogged, legt Artikel in den Warenkorb und lässt den PC einfach so stehen. Es wird nicht daran gearbeitet. Wenn man 20 bis 30 Minuten später weitermachen möchte sieht es auf den ersten Blick “normal” aus, die Anzahl der Artikel im Warenkorb werden im Icon noch angezeigt. Klar, es wurde ja auch keine Seite neu geladen. Wenn nun ein weiterer Artikel in den Warenkorb gelegt wird ist der bestehende Warenkorb leer und nur der neue Artikel drin. Ein genauerer Bilck zeigt dass man nicht mehr angemeldet ist. Die gc_maxlifetime haben wir auf 28800 gesetzt, das sollten doch eigentlich 8 Stunden sein.
Ein Löschen des Cache im Backend des Shops scheint die PHP-Sessions mit angemeldeten Usern nicht zu beenden.
nun möchte ich an diesem Thema weitermachen. Habe immer noch die Beschwerden der User das nach ca. 20 bis 30 Minuten die Abmeldung erfolgt.
Hier die Timestamps:
Daraus kann ich erkennen, dass das expiry immer ca. die angesprochenen 20 bis 30 Min. sind und nicht die laut gc_maxlifetime eingestellten 8 Stunden.
Oder sehe ich da etwas falsch?
Müsste das expire nicht mit jedem modified-Zugriff automatisch erhöht werden?
Immer noch kein Erfolg, timeout bleibt bei ~ 24 Min.
Wenn ich mir die Funktion sCheckUser ansehe kann ich da nichts vom Schreiben in die s_core_sessions erkennen. Da ist für mich nur die s_user zu sehen. Evtl. habe ich ja was nicht kapiert.
Wann wird sCheckUser aufgerufen? Nur bei der Anmeldung oder auch zyklisch während der Benutzer angemeldet ist?
Mir ist noch eine andere Stelle aufgefallen:
PdoSessionHandler.php
/**
* {@inheritdoc}
*/
public function write($sessionId, $data)
{
$maxlifetime = (int) ini_get('session.gc_maxlifetime');
try {
// We use a single MERGE SQL query when supported by the database.
$mergeStmt = $this->getMergeStatement($sessionId, $data, $maxlifetime);
if (null !== $mergeStmt) {
$mergeStmt->execute();
return true;
}
$updateStmt = $this->pdo->prepare(
"UPDATE $this->table SET $this->dataCol = :data, $this->expiryCol = :expiry, $this->timeCol = :time WHERE $this->idCol = :id"
);
$updateStmt->bindParam(':id', $sessionId, \PDO::PARAM_STR);
$updateStmt->bindParam(':data', $data, \PDO::PARAM_LOB);
$updateStmt->bindValue(':expiry', time() + $maxlifetime, \PDO::PARAM_INT);
$updateStmt->bindValue(':time', time(), \PDO::PARAM_INT);
$updateStmt->execute();
Hier wird doch auf die gc_maxlifetime zugegriffen und ein timeout berechnet.
Wenn ich mir meine Systeminfo (weiter oben im Thread) ansehe steht da bei session.name = SHOPWAREBACKEND. Wird darüber das Timeout im FRONTEND gesteuert?
Sieht für mich eher so aus, wie wenn für die Frontend-Session der Masterwert von 1440 genutzt wird. Das würde der Zeit von 24 Min. entsprechen nach der der automatische Logout im Frontend erfolgt.
Mein Problem seinerzeit wurde in der 5.4.6 durch den oben von Moritz genannten Patch behoben.
Zumindestens hat der Kunde sich seither nicht mehr beklagt und ein Update von Shopware gab es bis heute dort nicht.
