Zauważyłem, że za każdym razem, gdy ponownie uruchamiam Varnish na moim serwerze, tracę sesje dla moich użytkowników.
To z kolei powoduje, że moi klienci tracą koszyki.
Czy to normalne zachowanie lakieru, czy to moja wina VCL? Wydaje się, że tak nie jest
Dalsze informacje
Po dalszym dochodzeniu wydaje się, że problem ten dotyczy problemu nr 725 w serwisie GitHub.
Moja instalacja Magento to wersja 1.9.1.0. Należy również powiedzieć, że cały mój frontend działa pod https. Używam funta przed Varnish do zakończenia SSL.
Wygląda na to, że domyślnym zachowaniem Magento w tej wersji jest utworzenie pomocniczego pliku cookie frontonu, zwykle zwanego „frontend_cid”, w celu przetestowania pod kątem ataków MITM.
Wygląda na to, że wygenerowany plik VCL firmy Turpentine nie przekazuje tego pliku cookie, co powoduje nieprawidłowe sesje.
Czy ktoś może wyjaśnić, w jaki sposób plik VCL przekazuje pliki cookie, które Magento przekazuje klientowi?
Zawęziłem to do Varnish, nie generując wymaganych plików cookie.
Od Magento 1.9.1.0 wprowadzono plik cookie „frontend_cid”, aby blokować ataki MITM.
Można to znaleźć w Mage_Core_Model_Session_Abstract_Varienklasie, w linii 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);
}
}Aby zapewnić bezpieczne połączenia dla klientów, Varnish musi wygenerować plik cookie „frontend”, którego Magento użyje później do zidentyfikowania tego konkretnego klienta. Jak dotąd wydaje się, że robi to dobrze. Wygląda jednak jak w Magento 1.9.1.0, teraz musi również wygenerować plik cookie „frontend_cid”.
Lakier musi to zrobić, ponieważ buforując odpowiedź, buforuje również nagłówek odpowiedzi, który zawiera pliki cookie „frontend”.
Dlatego domyślnie Varnish usuwa wszystkie pliki cookie, na które backend reaguje, gdy obsługuje warunki „wyszukiwania” lub „przejścia”. Robi to, aby zapobiec sytuacji, w której wielu użytkowników otrzyma ten sam buforowany plik cookie nakładki (co zagroziłoby sesjom użytkowników).
Za każdym razem, gdy lakier obsługuje zapytanie „potokiem”, Magento jest w stanie utworzyć wymagane pliki cookie i dołączyć je do przeglądarki użytkownika. Powoduje to, że system nie powiedzie się podczas początkowej weryfikacji, ale następnie zapewnia nową sesję użytkownikowi. Ten objaw objawia się utratą wózka lub niemożnością dodania produktów do koszyka.
Turpentine VCL „potokuje” każde żądanie, które NIE JEST typu metody GET lub HEAD, jak widać w tym kodzie w vcl_recvfunkcji:
// 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);
}Dlatego objaw jest najbardziej zauważalny, gdy użytkownik próbuje dodać element do koszyka lub po raz pierwszy realizuje transakcję.
Jak naprawić?
Wierzę, że rozwiązaniem tego problemu jest utworzenie Turpentine VCL również pliku cookie „frontend_cid” dla przybywających gości, a następnie moduł terpentyny dodaje ten plik cookie do bieżącej sesji, tak jak teraz w przypadku pliku cookie „frontend”.
Więc ... jak to zrealizujemy?
Zastrzeżenie: Mogę się mylić, jestem bardzo nowy w Varnish, ale spędziłem teraz na tym wiele godzin i właśnie to widzę, każda pomoc w tej chwili byłaby bardzo mile widziana.
OSTATECZNA AKTUALIZACJA I MOJA WYBRANA POPRAWKA - 2015 10 30
Niemożliwe jest utworzenie pliku cookie „frontend_cid” w lakierze, ponieważ plik cookie jest tworzony losowo na serwerze przez Magento i przechowywany jako skrót MD5 w sesji klienta. To powstrzymuje cię przed tworzeniem się poza sesją klienta.
Najlepszym rozwiązaniem, jakie wymyśliłem w tej sprawie, jest zastąpienie sposobu, w jaki Magento obsługuje sesje klientów.
Obecnie Magento obsługuje nieprawidłowe sesje takie jak to:
IF
The requested session by the customer is flagged as invalid
THEN
Stop processing request
Redirect to the appropriate pageMoja nowa logika wygląda następująco:
IF
The requested session by the customer is flagged as invalid
THEN
Create a new session
Complete the requested task
Redirect to the appropriate pageMoje nowe podejście pozwala lakierowi obsługiwać reakcje klientów już przy pierwszej wizycie. Nie tak działa najnowsza implementacja terpentyny.
Mój problem, numer 829 - / nexcess / magento-turpentine / Issues / 829 w serwisie GitHub. Kopię mojego VCL można znaleźć tutaj.
Mój problem na GitHub został zamknięty, ponieważ jest to duplikat znacznie starszego problemu znalezionego tutaj: