Lack und Terpentin


9

Ich stelle fest, dass ich bei jedem Neustart von Varnish auf meinem Server meine Sitzungen für meine Benutzer verliere.

Dies führt dazu, dass meine Kunden ihre Einkaufswagen verlieren.

Ist das normales Verhalten für Lack oder ist meine VCL schuld? Es scheint, dass es nicht ist


Weitere Informationen.

Bei weiteren Untersuchungen scheint dieses Problem mit Problem Nr. 725 auf GitHub zu zusammenhängen.

Meine Magento-Installation ist Version 1.9.1.0. Es sollte auch gesagt werden, dass mein gesamtes Frontend unter https ausgeführt wird. Ich verwende Pound vor Varnish, um SSL zu beenden.

Es scheint, dass das Standardverhalten von Magento in dieser Version darin besteht, ein sekundäres Frontend-Cookie zu erstellen, das normalerweise als "frontend_cid" bezeichnet wird, um gegen MITM-Angriffe zu testen.

Es sieht so aus, als würde die von Terpentine generierte VCL-Datei dieses Cookie nicht weitergeben, was zu ungültigen Sitzungen führt.

Kann jemand erklären, wie die VCL-Datei die von Magento gesetzten Cookies an den Client weitergibt?


Ich habe dies auf Varnish eingegrenzt, ohne die erforderlichen Cookies zu generieren.

Ab Magento 1.9.1.0 wurde ein 'frontend_cid'-Cookie eingeführt, um MITM-Angriffe zu blockieren.

Dies finden Sie in der Mage_Core_Model_Session_Abstract_VarienKlasse in Zeile 135

if (Mage::app()->getFrontController()->getRequest()->isSecure() && empty($cookieParams['secure'])) {
    // secure cookie check to prevent MITM attack
    $secureCookieName = $sessionName . '_cid';
    if (isset($_SESSION[self::SECURE_COOKIE_CHECK_KEY])
        && $_SESSION[self::SECURE_COOKIE_CHECK_KEY] !== md5($cookie->get($secureCookieName))
    ) {
        session_regenerate_id(false);
        $sessionHosts = $this->getSessionHosts();
        $currentCookieDomain = $cookie->getDomain();
        foreach (array_keys($sessionHosts) as $host) {
            // Delete cookies with the same name for parent domains
            if (strpos($currentCookieDomain, $host) > 0) {
                $cookie->delete($this->getSessionName(), null, $host);
            }
        }
        $_SESSION = array();
    }
    if (!isset($_SESSION[self::SECURE_COOKIE_CHECK_KEY])) {
        $checkId = Mage::helper('core')->getRandomString(16);
        $cookie->set($secureCookieName, $checkId, null, null, null, true);
        $_SESSION[self::SECURE_COOKIE_CHECK_KEY] = md5($checkId);
    }
}

Um sichere Verbindungen für Kunden bereitzustellen, muss Varnish ein Frontend-Cookie generieren, mit dem Magento später diesen bestimmten Kunden identifiziert. Bisher scheint dies in Ordnung zu sein. Es sieht jedoch so aus, als ob ab Magento 1.9.1.0 jetzt auch das Cookie 'frontend_cid' generiert werden muss.

Varnish muss dies tun, da durch das Zwischenspeichern der Antwort auch der Antwortheader zwischengespeichert wird, der die Frontend-Cookies enthält.

Daher sprengt Varnish standardmäßig alle Cookies, mit denen das Backend antwortet, wenn es die Bedingungen für die Suche oder das Bestehen behandelt. Auf diese Weise wird verhindert, dass mehreren Benutzern dasselbe zwischengespeicherte Frontend-Cookie ausgestellt wird (dies würde die Sitzungen der Benutzer gefährden).

Jedes Mal, wenn Lack die Anfrage mit 'pipe' bearbeitet, kann Magento die erforderlichen Cookies erstellen und sie an den Browser des Benutzers anhängen. Dies führt dazu, dass das System die Erstvalidierung nicht besteht, dem Benutzer dann jedoch eine neue Sitzung bereitstellt. Dieses Symptom äußert sich in einem Verlust des Einkaufswagens oder in der Unfähigkeit, Produkte zum Einkaufswagen hinzuzufügen.

Die Terpentin-VCL leitet alle Anforderungen weiter, die NICHT vom Methodentyp GET oder HEAD sind, wie in diesem Code in der vcl_recvFunktion dargestellt:

// We only deal with GET and HEAD by default
// we test this here instead of inside the url base regex section
// so we can disable caching for the entire site if needed
if (!true || req.http.Authorization ||
    req.request !~ "^(GET|HEAD)$" ||
    req.http.Cookie ~ "varnish_bypass=1") {
    return (pipe);
}

Daher tritt das Symptom am deutlichsten auf, wenn der Benutzer versucht, einen Artikel in den Warenkorb zu legen, oder wenn er zum ersten Mal versucht, zur Kasse zu gehen.


Wie repariert man?

Ich glaube, die Lösung für dieses Problem besteht darin, dass die Terpentine VCL auch ein 'frontend_cid'-Cookie für eingehende Besucher erstellt und das Terpentinmodul dieses Cookie dann zur aktuellen Sitzung hinzufügt, wie dies jetzt für das' Frontend'-Cookie der Fall ist.

Also ... wie setzen wir das um?

Vorsichtsmaßnahme: Ich könnte mich irren, ich bin sehr neu in Varnish, aber ich habe jetzt viele Stunden damit verbracht, und das ist es, was ich sehe. Jede Unterstützung im Moment wäre sehr dankbar.

ENDGÜLTIGES UPDATE UND MEIN AUSGEWÄHLTES FIX - 2015 10 30

Es ist unmöglich, ein 'frontend_cid'-Cookie in Lack zu erstellen, da das Cookie von Magento zufällig auf dem Server erstellt und in der Kundensitzung als MD5-Hash gespeichert wird. Dies verhindert, dass Sie außerhalb der Kundensitzung extern erstellen.

Die beste Lösung, die ich zu diesem Problem gefunden habe, besteht darin, stattdessen die Art und Weise zu überschreiben, wie Magento Kundensitzungen behandelt.

Derzeit behandelt Magento ungültige Sitzungen wie folgt:

IF
    The requested session by the customer is flagged as invalid
THEN
    Stop processing request
    Redirect to the appropriate page

Meine neue Logik lautet wie folgt:

IF
    The requested session by the customer is flagged as invalid
THEN
    Create a new session
    Complete the requested task
    Redirect to the appropriate page

Mein neuer Ansatz ermöglicht es lackiert, die Kundenreaktion bereits beim ersten Besuch zu verarbeiten. So funktioniert die neueste Implementierung von Terpentin nicht.


Meine Ausgabe, Ausgabe # 829 - / nexcess / magento-terpentine / issue / 829 auf GitHub. Eine Kopie meiner VCL finden Sie hier.


Mein Problem auf GitHub wurde geschlossen, da es sich um ein Duplikat eines viel älteren Problems handelt, das hier zu finden ist:

Problem Nr. 345


1
Ich habe gesehen, dass Sie gerade eine Ausgabe auf GitHub geöffnet haben. Ich werde sie morgen früh überprüfen. In der Zwischenzeit können Sie github.com/nexcess/magento-turpentine/issues/90 und github.com/nexcess/magento-turpentine/issues/92 überprüfen .
Mbalparda

Dies ist unmöglich, Sitzungen werden in Magento und im Browser des Benutzers gespeichert, Lack hat nichts damit zu tun. wahrscheinlich ist etwas falsch konfiguriert.

Antworten:


4

Dies kann daran liegen, dass Sie Ihren Cookie-Pfad nicht richtig eingestellt haben.

Versuchen Sie, Ihre Cookie-Einstellungen in festzulegen, Admin->Configuration->Web->Session Cookie Managementfalls dies noch nicht geschehen ist.

Alternativ kann es sich um einen Lackfehler handeln.


Vielen Dank an @performadigital, ich habe einige weitere Untersuchungen durchgeführt und aktualisiere meine Frage.
Peter A

1

Ich vermute, dass Ihr Problem durch ein kürzlich veröffentlichtes Terpentine-Update behoben wurde: https://github.com/nexcess/magento-turpentine/commit/66615b7cc987854e8671911ab6c3aa22afb808a2

Sitzungsgenerierung entfernt Behebt die Probleme Nr. 806, Nr. 345 und viele andere im Zusammenhang mit zusätzlichen Sitzungen, leeren Wagen usw.

Bewirkt, dass der Lack beim Laden der ersten Seite für neue Sitzungen umgangen wird.

Varnish muss also nicht mehr versuchen, das Sitzungscookie zu fälschen (auf Kosten der Tatsache, dass es nicht möglich ist, vom Cache auf die Anforderung der ersten Seite zu antworten).

Wir haben festgestellt, dass diese Änderung dieses Problem für eine Reihe unserer Magento-Kunden behoben hat (wir betreiben www.section.io ).


1
Danke @mattnthat, mir ist die vorgeschlagene Lösung bekannt, aber ich finde sie nicht akzeptabel. Am Ende habe ich eine andere Lösung implementiert. Ich ließ Magento prüfen, ob die Sitzung gültig war, und wenn dies nicht der Fall war, ließ ich eine neue Sitzung initialisieren und die Anforderung abschließen, anstatt das Skript zu beenden.
Peter A
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.