Vernis et térébenthine


9

Je constate que chaque fois que je redémarre Varnish sur mon serveur, je perds mes sessions pour mes utilisateurs.

C'est à mon tour de faire perdre à mes clients leurs paniers d'achat.

Est-ce un comportement normal pour Varnish ou est-ce ma VCL à blâmer? Il semblerait que ce ne soit pas


Plus d'infos.

Après une enquête plus approfondie, il semble que ce problème soit lié au problème n ° 725 sur GitHub.

Mon installation Magento est la version 1.9.1.0. Il convient également de dire que l'ensemble de mon frontend est exécuté sous https. J'utilise Pound devant Varnish pour mettre fin à SSL.

Il semble que le comportement par défaut de Magento dans cette version consiste à créer un cookie frontal secondaire, généralement appelé «frontend_cid», dans une tentative de test contre les attaques MITM.

Il semble que le fichier VCL généré par Turpentine ne transmette pas ce cookie, ce qui provoque des sessions non valides.

Quelqu'un peut-il expliquer comment le fichier VCL transmet les cookies que Magento fait au client?


J'ai réduit cela à Varnish ne générant pas les cookies requis.

Depuis Magento 1.9.1.0, un cookie 'frontend_cid' a été introduit pour bloquer les attaques MITM.

Cela peut être trouvé dans la Mage_Core_Model_Session_Abstract_Varienclasse, à la ligne 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);
    }
}

Afin de fournir des connexions sécurisées aux clients, Varnish doit générer un cookie «frontal», que Magento utilisera plus tard pour identifier ce client particulier. Jusqu'à présent, cela semble très bien le faire. Cependant, il semble qu'à partir de Magento 1.9.1.0, il doit maintenant également générer le cookie 'frontend_cid'.

Varnish doit le faire car, en mettant en cache la réponse, il met également en cache l'en-tête de réponse, qui contient les cookies «frontaux».

Par conséquent, par défaut, Varnish supprime tous les cookies auxquels le backend répond lors de sa gestion des conditions de «recherche» ou de «réussite». Cela permet d'empêcher que plusieurs utilisateurs ne reçoivent le même cookie frontal mis en cache (ce qui compromettrait les sessions des peuples).

Chaque fois que le vernis traite la demande avec 'pipe', Magento est capable de créer les cookies requis et de les attacher au navigateur des utilisateurs. Il en résulte que le système échoue à la validation initiale, mais fournit ensuite une nouvelle session à l'utilisateur. Ce symptôme se manifeste par une perte de panier ou l'incapacité d'ajouter des produits au panier.

Le Turpentine VCL 'canalisera' toute demande qui N'EST PAS du type de méthode GET ou HEAD comme le montre ce code dans la vcl_recvfonction:

// 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);
}

Par conséquent, le symptôme est plus visible lorsque l'utilisateur tente d'ajouter un article à son panier ou tente de passer la caisse pour la première fois.


Comment réparer?

Je pense que la solution à ce problème consiste à faire en sorte que Turpentine VCL crée également un cookie `` frontend_cid '' pour les visiteurs entrants, puis que le module térébenthine ajoute ce cookie à la session en cours comme il le fait maintenant pour le cookie `` frontend ''.

Alors ... comment mettons-nous cela en œuvre?

Mise en garde: je peux me tromper, je suis très nouveau dans Varnish, mais j'ai passé beaucoup d'heures là-dessus maintenant et c'est ce que je vois, tout support en ce moment serait grandement apprécié.

MISE À JOUR FINALE ET MON CORRECTION CHOISIE - 2015 10 30

Il est impossible de créer un cookie 'frontend_cid' en vernis car le cookie est créé au hasard sur le serveur par Magento et stocké en tant que hachage MD5 dans la session clients. Cela vous empêche de créer en externe en dehors de la session clients.

La meilleure solution que j'ai trouvée sur ce problème est de remplacer la manière dont Magento gère les sessions client.

Actuellement, Magento gère des sessions non valides comme celle-ci:

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

Ma nouvelle logique va comme suit:

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

Ma nouvelle approche permet au vernis de gérer la réponse des clients dès la première visite. Ce n'est pas ainsi que fonctionne la dernière mise en œuvre de la térébenthine.


My Issue, Issue # 829 - / nexcess / magento-turpentine / issues / 829 sur GitHub. Une copie de ma VCL peut être trouvée ici.


Mon problème sur GitHub a été fermé car il s'agit d'un doublon d'un problème beaucoup plus ancien trouvé ici:

Numéro 345


1
J'ai vu que vous veniez d'ouvrir un problème sur GitHub, je le vérifierai demain matin. En attendant, vous pouvez consulter github.com/nexcess/magento-turpentine/issues/90 et github.com/nexcess/magento-turpentine/issues/92 .
mbalparda

c'est impossible, les sessions sont stockées dans magento et le navigateur des utilisateurs, le vernis n'y est pour rien. quelque chose est probablement mal configuré.

Réponses:


4

Cela peut être dû au fait de ne pas définir correctement votre chemin d'accès aux cookies.

Essayez de définir vos paramètres de cookies Admin->Configuration->Web->Session Cookie Managementsi ce n'est pas déjà fait.

Alternativement, il peut s'agir d'un bug dans le vernis.


Merci @performadigital, j'ai fait une enquête plus approfondie et je mets à jour ma question.
Peter A

1

Je soupçonne que votre problème aura été résolu par une récente mise à jour de Térébenthine: https://github.com/nexcess/magento-turpentine/commit/66615b7cc987854e8671911ab6c3aa22afb808a2

Suppression de la génération de sessions Résout les problèmes # 806, # 345 et bien d'autres liés aux sessions supplémentaires, aux chariots vides, etc.

Provoque le contournement de Varnish lors du premier chargement de page pour les nouvelles sessions.

Ainsi, Varnish n'a plus à essayer de simuler le cookie de session (au prix de ne pas pouvoir répondre du cache à la demande de première page)

Nous avons constaté que ce changement a résolu ce problème pour un certain nombre de nos clients Magento (nous exécutons www.section.io ).


1
Merci @mattnthat, je connais la solution proposée mais je ne la trouve pas acceptable. J'ai fini par implémenter une solution différente. J'ai fait vérifier à Magento si la session était valide, et si elle ne l'était pas, plutôt que de terminer le script, je lui ai fait initialiser une nouvelle session et terminer la demande.
Peter A
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.