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_Varien
classe, à 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_recv
fonction:
// 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:
la source
Réponses:
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 Management
si ce n'est pas déjà fait.Alternativement, il peut s'agir d'un bug dans le vernis.
la source
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
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 ).
la source