Problemy z ciasteczkami w PrestaShop: Sesje, RODO i wydajność

Jak PrestaShop wykorzystuje ciasteczka

Każdy sklep PrestaShop polega na ciasteczkach, aby funkcjonować. Utrzymują one sesje klientów, zapamiętują zawartość koszyka, przechowują preferencje językowe i walutowe, śledzą status zalogowania i umożliwiają panelowi administracyjnemu uwierzytelnianie administratorów. Bez ciasteczek sklep PrestaShop nie może utrzymać stanu pomiędzy załadowaniami stron, co oznacza brak koszyka, brak logowania klienta i brak dostępu do panelu administracyjnego.

PrestaShop używa dwóch głównych ciasteczek. Ciasteczko front office, zazwyczaj nazwane według Twojego sklepu (np. PrestaShop-abc123), obsługuje wszystko, czego potrzebuje strona skierowana do klienta. Ciasteczko back office, o podobnym wzorcu nazewnictwa, ale innym zakresie, obsługuje uwierzytelnianie administratorów. Oba ciasteczka przechowują zserializowane dane bezpośrednio w wartości ciasteczka, co jest decyzją projektową mającą istotne konsekwencje dla wydajności, bezpieczeństwa i zgodności z RODO.

Struktura i zawartość ciasteczek PrestaShop

W przeciwieństwie do wielu aplikacji internetowych, które przechowują w ciasteczku jedynie identyfikator sesji, a wszystkie dane sesji trzymają na serwerze, PrestaShop przechowuje znaczną ilość danych bezpośrednio w samym ciasteczku. Ciasteczko front office zawiera pola obejmujące identyfikator klienta, imię i adres e-mail klienta, informację o tym, czy klient jest zalogowany, identyfikator koszyka, wybrany język, wybraną walutę, ostatnio odwiedzaną kategorię, ostatnio odwiedzany produkt, etap realizacji zamówienia oraz różne inne informacje o stanie.

Dane te są serializowane przy użyciu własnej klasy ciasteczek PrestaShop (Cookie.php w katalogu classes). Wartość ciasteczka jest zaszyfrowana kluczem wywodzącym się ze stałej _COOKIE_KEY_ w pliku config/settings.inc.php (PrestaShop 1.6/1.7) lub app/config/parameters.php (PrestaShop 8.x). To szyfrowanie zapobiega manipulacji i chroni wrażliwe dane, takie jak identyfikator klienta i adres e-mail, przed odczytaniem w przeglądarce.

Dlaczego PrestaShop przechowuje dane w ciasteczku

Historycznym powodem tej decyzji projektowej jest wydajność. Przechowując dane sesji w ciasteczku, PrestaShop unika wyszukiwania sesji po stronie serwera przy każdym zapytaniu. Nie ma potrzeby odczytu z pliku sesji, odpytywania bazy danych ani łączenia się z serwerem sesji. Dane przychodzą wraz z zapytaniem, już dostępne.

Jednak to podejście ma wady, które stają się bardziej istotne w miarę rozwoju sklepu. Rozmiar ciasteczka rośnie wraz z ilością przechowywanych danych, a każde zapytanie HTTP (w tym zapytania o obrazy, CSS i pliki JavaScript) wysyła pełne ciasteczko do serwera. Ciasteczko o rozmiarze 4 KB wysyłane z 30 zapytaniami o zasoby na każde załadowanie strony oznacza 120 KB niepotrzebnego pasma przesyłania na jedno załadowanie strony. Ten narzut jest mierzalny na połączeniach mobilnych i przy dużej skali.

Rozmiar ciasteczka i wpływ na wydajność

Ciasteczka przeglądarki mają praktyczny limit rozmiaru wynoszący około 4096 bajtów na jedno ciasteczko. Ciasteczko front office PrestaShop może zbliżyć się do tego limitu lub go przekroczyć, zwłaszcza gdy moduły dodają własne dane do ciasteczka za pośrednictwem hooka hookActionBeforeSubmitAccount lub bezpośrednio modyfikując obiekt ciasteczka.

Pomiar wpływu rozmiaru ciasteczka

Aby zobaczyć, jak ciasteczka wpływają na wydajność Twojego sklepu, otwórz narzędzia deweloperskie przeglądarki i przejdź do zakładki Sieć. Spójrz na nagłówki zapytania dla dowolnego zapytania do Twojej domeny. Nagłówek Cookie pokazuje wszystkie wysyłane ciasteczka. Zwróć uwagę na jego rozmiar. Teraz spójrz na nagłówki zapytania dla zasobu statycznego (obrazu lub pliku CSS) w tej samej domenie. Te same ciasteczka są wysyłane z tym zapytaniem, dodając narzut bez żadnego powodu.

Redukcja narzutu ciasteczek dla zasobów statycznych

Najskuteczniejszym sposobem eliminacji narzutu ciasteczek dla plików statycznych jest serwowanie ich z innej domeny (domeny bez ciasteczek). W PrestaShop możesz skonfigurować serwery mediów w back office w sekcji Zaawansowane parametry > Wydajność. Gdy ustawisz serwer mediów jak static.twojadomena.com, PrestaShop serwuje obrazy, CSS i JavaScript z tej domeny. Ponieważ ciasteczka są specyficzne dla domeny, żadne ciasteczka nie są wysyłane z zapytaniami do domeny mediów.

Alternatywnie, CDN taki jak Cloudflare, Fastly lub CloudFront może serwować Twoje zasoby statyczne. Serwery brzegowe CDN zazwyczaj usuwają ciasteczka z cachowanych odpowiedzi, więc nawet jeśli ciasteczka są wysyłane w zapytaniu, odpowiedź pochodzi z cache bez narzutu podróży w obie strony do serwera źródłowego.

Rozdęcie ciasteczek przez moduły

Moduły firm trzecich czasami dodają dane do ciasteczka PrestaShop bez uwzględnienia konsekwencji rozmiaru. Każdy moduł, który przechowuje wartość w ciasteczku, zwiększa jego rozmiar i narzut przy każdym zapytaniu. Jeśli Twoje ciasteczko jest niezwykle duże, sprawdź, jakie dane dodały moduły, badając odszyfrowaną zawartość ciasteczka lub przeglądając kod modułów w poszukiwaniu wywołań $this->context->cookie->mymodule_value = ....

Dobrze zaprojektowane moduły używają przechowywania po stronie serwera (bazy danych lub cache) i przechowują w ciasteczku co najwyżej mały identyfikator. Źle zaprojektowane moduły zrzucają pełne struktury danych do ciasteczka, nadmiernie zwiększając jego rozmiar. Jeśli zidentyfikujesz problematyczny moduł, skontaktuj się z deweloperem lub zastąp przechowywanie w ciasteczku przechowywaniem opartym na bazie danych z wykorzystaniem identyfikatora sesji.

Obsługa sesji: pliki, baza danych i Redis

Chociaż PrestaShop przechowuje niektóre dane bezpośrednio w ciasteczkach, PHP utrzymuje również własny system sesji. Back office PrestaShop w większym stopniu polega na sesjach PHP niż front office. Obsługa sesji określa, gdzie dane sesji są przechowywane po stronie serwera.

Sesje oparte na plikach (domyślne)

Domyślnie PHP przechowuje sesje jako pliki w katalogu session.save_path (zazwyczaj /tmp lub /var/lib/php/sessions). Każda sesja tworzy plik. Dla sklepu z tysiącami aktywnych sesji oznacza to tysiące małych plików. Sesje oparte na plikach działają dobrze dla małych i średnich sklepów, ale mogą powodować problemy przy dużej skali.

Typowe problemy z sesjami opartymi na plikach obejmują wolne czyszczenie sesji (garbage collection), gdy katalog sesji zawiera zbyt wiele plików, blokowanie plików, które może powodować serializację zapytań (dwa zapytania z tej samej sesji nie mogą być przetwarzane jednocześnie), oraz środowiska hostingu współdzielonego, w których katalog sesji się zapełnia lub ma restrykcyjne uprawnienia.

Sesje w bazie danych

PrestaShop obsługuje przechowywanie sesji w bazie danych. Jest to konfigurowane w ustawieniach PHP lub przez obsługę sesji PrestaShop. Sesje w bazie danych eliminują problemy systemu plików, ale dodają zapytanie do bazy danych przy każdym zapytaniu HTTP. Dla sklepów, które już mają duże obciążenie bazy danych, może to pogorszyć wydajność. Jednak sesje w bazie danych mają tę zaletę, że są współdzielone między wieloma serwerami WWW w konfiguracji z load balancerem.

Sesje w Redis lub Memcached

Dla sklepów PrestaShop o dużym ruchu, Redis jest optymalnym backendem do przechowywania sesji. Redis przechowuje dane sesji w pamięci, zapewniając czasy dostępu poniżej milisekundy. Obsługuje automatyczne wygasanie (timeout sesji), a dane sesji są współdzielone między wszystkimi instancjami serwerów WWW.

Aby skonfigurować PHP do używania Redis dla sesji, ustaw session.save_handler = redis i session.save_path = "tcp://127.0.0.1:6379" w pliku php.ini lub konfiguracji puli PHP-FPM. Jeśli instancja Redis wymaga uwierzytelniania, dodaj hasło do ścieżki zapisu: "tcp://127.0.0.1:6379?auth=twojehaslo".

PrestaShop już obsługuje Redis do cachowania obiektów (konfigurowane w back office w sekcji Zaawansowane parametry > Wydajność). Używanie tej samej instancji Redis zarówno dla sesji, jak i cachowania obiektów upraszcza infrastrukturę, zapewniając jednocześnie doskonałą wydajność dla obu zastosowań.

Atrybuty SameSite, Secure i HttpOnly

Nowoczesne przeglądarki wymuszają atrybuty bezpieczeństwa ciasteczek, które bezpośrednio wpływają na zachowanie ciasteczek PrestaShop. Nieprawidłowo skonfigurowane atrybuty ciasteczek powodują błędy logowania, utracone koszyki i problemy z przetwarzaniem płatności.

Atrybut SameSite

Atrybut SameSite kontroluje, czy ciasteczko jest wysyłane z zapytaniami między witrynami. Ma trzy możliwe wartości:

SameSite=Strict oznacza, że ciasteczko nigdy nie jest wysyłane z zapytaniami między witrynami. Jest to zbyt restrykcyjne dla PrestaShop, ponieważ klienci klikający link do Twojego sklepu z e-maila lub mediów społecznościowych nie mieliby wysyłanego ciasteczka sesji, co skutecznie wylogowałoby ich.

SameSite=Lax jest domyślną wartością w nowoczesnych przeglądarkach. Ciasteczko jest wysyłane z nawigacjami najwyższego poziomu (kliknięcie linku), ale nie z zapytaniami podrzędnymi między witrynami (obrazy, iframe, AJAX). Działa to dobrze dla ciasteczka front office PrestaShop w większości przypadków.

SameSite=None oznacza, że ciasteczko jest zawsze wysyłane, w tym z zapytaniami między witrynami. Musi to być połączone z atrybutem Secure. Jest to potrzebne, gdy Twój sklep jest osadzony w iframe na innej witrynie lub gdy bramki płatności firm trzecich muszą przekierować z powrotem do Twojego sklepu z nienaruszoną sesją.

Problemy z bramkami płatności

Wiele problemów z płatnościami w PrestaShop jest spowodowanych problemami z ciasteczkami SameSite. Typowy scenariusz wygląda następująco: klient realizuje zamówienie, jest przekierowywany na stronę bramki płatności, dokonuje płatności i jest przekierowywany z powrotem do Twojego sklepu. Jeśli ciasteczko sesji ma SameSite=Lax, może nie zostać wysłane przy przekierowaniu z bramki płatności, w zależności od sposobu implementacji przekierowania. Jeśli bramka używa przekierowania POST (typowe dla 3D Secure), polityka Lax blokuje ciasteczko, a PrestaShop traci sesję. Klient widzi pusty koszyk lub ogólną stronę błędu zamiast potwierdzenia zamówienia.

Rozwiązaniem jest ustawienie ciasteczka PrestaShop na SameSite=None; Secure. W PrestaShop 1.7.7+ i 8.x można to skonfigurować w ustawieniach ciasteczek. Dla starszych wersji może być konieczna modyfikacja klasy Cookie lub dodanie nagłówków przez konfigurację serwera WWW. Zawsze testuj przepływy płatności po zmianie ustawień SameSite.

Atrybut Secure

Atrybut Secure zapewnia, że ciasteczko jest wysyłane tylko przez połączenia HTTPS. Jeśli Twój sklep działa na HTTPS (co powinien), ten atrybut zapobiega przesyłaniu ciasteczka przez nieszyfrowane połączenie, chroniąc je przed przechwyceniem. PrestaShop ustawia ten atrybut, gdy sklep wykrywa połączenie HTTPS.

Typowy problem występuje przy mieszanych konfiguracjach HTTP/HTTPS. Jeśli back office działa na HTTPS, ale niektóre strony front office na HTTP, ciasteczka oznaczone jako Secure nie zostaną wysłane na stronach HTTP, przerywając sesję. Rozwiązaniem jest wymuszenie HTTPS wszędzie, co i tak powinieneś robić ze względów bezpieczeństwa i SEO.

Atrybut HttpOnly

Atrybut HttpOnly zapobiega dostępowi JavaScript do ciasteczka przez document.cookie. Jest to kluczowy środek bezpieczeństwa przeciwko atakom cross-site scripting (XSS). Jeśli atakujący wstrzyknie złośliwy JavaScript do Twojego sklepu (na przykład przez podatny moduł), atrybut HttpOnly zapobiega kradzieży ciasteczek sesji przez ten kod.

PrestaShop domyślnie ustawia flagę HttpOnly na swoich ciasteczkach. Nie wyłączaj tego, chyba że masz bardzo konkretny powód i rozumiesz konsekwencje bezpieczeństwa.

Debugowanie problemów z sesjami i ciasteczkami

Problemy z ciasteczkami i sesjami objawiają się tajemniczymi symptomami: losowe wylogowywanie klientów, koszyki, które same się opróżniają, sesje administracyjne wygasające natychmiast, procesy zamówienia kończące się cichym niepowodzeniem. Systematyczne debugowanie wymaga sprawdzenia kilku warstw.

Narzędzia deweloperskie przeglądarki

Otwórz zakładkę Application (Chrome) lub Storage (Firefox) i przejdź do Cookies. Znajdź domenę swojego sklepu i zbadaj wszystkie ciasteczka. Sprawdź kolumny Name, Value, Domain, Path, Expires, Size, HttpOnly, Secure i SameSite. Szukaj ciasteczek, które są nieoczekiwanie duże, mają nieprawidłowe ustawienia domeny (ciasteczko dla www.example.com nie zostanie wysłane do example.com) lub brakuje im atrybutów bezpieczeństwa.

Weryfikacja sesji po stronie serwera

Jeśli sesje są przechowywane w plikach, sprawdź katalog sesji pod kątem obecności i wieku plików sesji. Jeśli klient zgłasza wylogowanie, znajdź plik sesji (nazwa pliku to identyfikator sesji z ciasteczka PHPSESSID) i sprawdź, kiedy został ostatnio zmodyfikowany. Jeśli plik nie istnieje, sesja została albo wyczyszczona przez garbage collector, albo nigdy nie została prawidłowo utworzona.

Dla sesji Redis użyj redis-cli, aby sprawdzić, czy klucz sesji istnieje: EXISTS PHPREDIS_SESSION:session_id. Sprawdź TTL, aby zobaczyć, czy wkrótce wygaśnie: TTL PHPREDIS_SESSION:session_id.

Typowe przyczyny losowych wylogowań

Zmiana _COOKIE_KEY_. Jeśli ten klucz się zmieni (podczas nieprawidłowo skonfigurowanego wdrożenia, nadpisania pliku ustawień lub aktualizacji), wszystkie istniejące ciasteczka stają się nieczytelne, ponieważ zostały zaszyfrowane starym kluczem. Każdy klient jest efektywnie wylogowany. Rozwiązaniem jest przywrócenie oryginalnego klucza z kopii zapasowej.

Zbyt agresywne czyszczenie sesji. Parametr PHP session.gc_maxlifetime określa, jak długo (w sekundach) plik sesji jest uznawany za ważny. Jeśli jest ustawiony zbyt nisko (domyślnie 1440 sekund, czyli 24 minuty), sesje klientów przeglądających sklep wolno są usuwane. Dla sklepu ustaw to na co najmniej 3600 (1 godzinę) lub więcej.

Load balancer bez koligacji sesji. Jeśli Twój sklep działa na wielu serwerach WWW za load balancerem, a sesje są przechowywane w plikach, każdy serwer ma własny katalog sesji. Klient, którego zapytania na przemian trafiają do różnych serwerów, traci sesję przy każdym przełączeniu. Rozwiązaniem jest albo koligacja sesji (sticky sessions) na load balancerze, albo współdzielone przechowywanie sesji za pomocą Redis lub bazy danych.

Niezgodność domeny ciasteczka. Jeśli Twój sklep jest dostępny zarówno pod www.example.com, jak i example.com, ale domena ciasteczka jest ustawiona na www.example.com, klienci uzyskujący dostęp do witryny bez prefiksu www nie będą mieli ciasteczka. Zapewnij spójne użycie domeny za pomocą przekierowania i zweryfikuj domenę ciasteczka w ustawieniach PrestaShop.

Zgodność ciasteczek z RODO

Ogólne rozporządzenie o ochronie danych (RODO) oraz dyrektywa ePrivacy wymagają świadomej zgody przed ustawieniem nieistotnych ciasteczek w przeglądarce użytkownika. Sklepy PrestaShop muszą przestrzegać tych przepisów, a ich nieprzestrzeganie może skutkować znacznymi karami finansowymi.

Ciasteczka istotne vs nieistotne

RODO rozróżnia ciasteczka, które są ściśle niezbędne do funkcjonowania witryny, od ciasteczek, które służą innym celom, takim jak analityka, marketing czy personalizacja. Ciasteczko sesji PrestaShop jest istotne, ponieważ sklep nie może funkcjonować bez niego. Klient nie może dodać produktów do koszyka ani zakończyć zakupu bez ciasteczka sesji. Ciasteczka istotne nie wymagają zgody na mocy RODO.

Jednak wiele innych ciasteczek powszechnie spotykanych w sklepach PrestaShop jest nieistotnych i wymaga wyraźnej zgody przed ich ustawieniem. Obejmują one ciasteczka śledzenia Google Analytics (_ga, _gid), ciasteczka Facebook Pixel, ciasteczka reklamowe z platform remarketingowych, ciasteczka widżetów czatu na żywo, ciasteczka przycisków udostępniania w mediach społecznościowych oraz wszelkie ciasteczka ustawiane przez moduły firm trzecich do celów śledzenia lub personalizacji.

Implementacja zgody na ciasteczka

PrestaShop nie zawiera wbudowanego mechanizmu zgody na ciasteczka, który spełnia wymagania RODO. Potrzebujesz albo modułu PrestaShop zaprojektowanego do zgody na ciasteczka, albo integracji z platformą zarządzania zgodami (CMP) firm trzecich, taką jak Cookiebot, Osano czy Usercentrics.

Prawidłowa implementacja zgody na ciasteczka musi przedstawić użytkownikowi jasny wybór przed ustawieniem jakichkolwiek nieistotnych ciasteczek. Musi umożliwić użytkownikowi akceptację lub odrzucenie poszczególnych kategorii ciasteczek (analityka, marketing itd.), a nie oferować tylko wybór wszystko albo nic. Musi zapamiętać wybór użytkownika i nie pytać ponownie do momentu wygaśnięcia zgody. Musi faktycznie zapobiegać ustawieniu zablokowanych ciasteczek, a nie tylko rejestrować preferencję, nadal ładując kody śledzenia.

Ostatni punkt jest kluczowy i często nieprawidłowo obsługiwany. Baner zgody, który się wyświetla, ale i tak ładuje Google Analytics niezależnie od wyboru użytkownika, nie zapewnia żadnej ochrony prawnej. Implementacja musi warunkowo ładować zasoby śledzenia i marketingu na podstawie zgody użytkownika.

Techniczna implementacja zgody

Techniczne podejście do zarządzania ciasteczkami opartego na zgodzie polega na opakowaniu nieistotnego kodu w kontrole zgody. Dla wbudowanego JavaScript, który ustawia ciasteczka lub ładuje piksele śledzenia, należy zastąpić bezpośrednie wykonanie ładowaniem warunkowanym zgodą. Kod śledzenia jest przechowywany, ale nie wykonywany, dopóki użytkownik nie wyrazi zgody.

Dla modułów firm trzecich, które ustawiają ciasteczka, implementacja jest bardziej złożona. Niektóre moduły oferują hooki lub opcje konfiguracji do integracji ze zgodami. Inne ładują swoje ciasteczka bezwarunkowo i muszą być zmodyfikowane lub zastąpione. Przeanalizuj każdy moduł w swoim sklepie pod kątem użycia ciasteczek i określ, które z nich ustawiają nieistotne ciasteczka.

Zgoda na ciasteczka a cachowanie

Cachowanie pełnych stron tworzy konflikt ze zgodą na ciasteczka. Jeśli strona jest cachowana z załadowanym Google Analytics i serwowana użytkownikowi, który nie wyraził zgody, naruszasz RODO. Istnieją dwa podejścia do rozwiązania tego problemu.

Pierwsze podejście polega na cachowaniu strony bez żadnych nieistotnych zasobów i dynamicznym wstrzykiwaniu ich przez JavaScript po sprawdzeniu zgody. Działa to dobrze z systemem CCC (Combine, Compress, Cache) PrestaShop i z Varnish lub innymi reverse proxy cache.

Drugie podejście polega na niechachowaniu stron dla użytkowników, którzy jeszcze nie dokonali wyboru zgody (odwiedzający po raz pierwszy). Pogarsza to wydajność dla nowych odwiedzających, ale zapewnia zgodność. Większość platform zarządzania zgodami stosuje pierwsze podejście, ponieważ zachowuje korzyści z cachowania.

Kwestie bezpieczeństwa związane z ciasteczkami

Poza już omówionymi atrybutami HttpOnly i Secure, istnieją dodatkowe kwestie bezpieczeństwa dotyczące ciasteczek PrestaShop.

Kradzież ciasteczek i przejęcie sesji

Jeśli atakujący uzyska ważne ciasteczko sesji PrestaShop, może podszyć się pod klienta lub administratora. Główna ochrona to HTTPS wszędzie (zapobiega przechwyceniu), ciasteczka HttpOnly (zapobiega kradzieży przez XSS) i atrybut Secure (zapobiega przesyłaniu przez HTTP). PrestaShop w niektórych konfiguracjach wiąże również sesje z adresami IP, co zapewnia dodatkową warstwę ochrony, ale może powodować problemy dla użytkowników, których adresy IP się zmieniają (użytkownicy mobilni, użytkownicy VPN).

Bezpieczeństwo klucza ciasteczka

_COOKIE_KEY_ w konfiguracji PrestaShop to główny klucz do szyfrowania ciasteczek. Jeśli ten klucz zostanie skompromitowany, atakujący może odszyfrować dowolne ciasteczko PrestaShop i sfałszować ważne ciasteczka sesji. Chroń ten klucz, ograniczając dostęp do plików konfiguracyjnych, nigdy nie commitując go do publicznych repozytoriów i nigdy nie udostępniając go w zgłoszeniach wsparcia.

Zapobieganie utrwalaniu sesji

Ataki typu session fixation polegają na tym, że atakujący ustawia znany identyfikator sesji w przeglądarce ofiary, zanim ofiara się zaloguje. Gdy ofiara się loguje, wcześniej ustawiony identyfikator sesji atakującego staje się uwierzytelniony. PrestaShop łagodzi ten problem, regenerując identyfikator sesji przy logowaniu. Upewnij się, że regeneracja identyfikatora sesji działa prawidłowo i nie została wyłączona przez żaden moduł ani zmianę konfiguracji.

Rozwiązywanie typowych problemów z ciasteczkami

Pętla logowania panelu administracyjnego

Objaw polega na wprowadzeniu prawidłowych danych logowania w back office PrestaShop, krótkim zobaczeniu pulpitu nawigacyjnego i przekierowaniu z powrotem na stronę logowania. Jest to niemal zawsze problem z ciasteczkiem. Sprawdź, czy domena ciasteczka jest prawidłowa, czy nazwa katalogu administracyjnego nie uległa zmianie, czy HTTPS jest prawidłowo skonfigurowany (mieszana zawartość może zapobiec wysłaniu ciasteczka Secure) oraz czy katalog przechowywania sesji jest zapisywalny przez serwer WWW.

Opróżnianie koszyka przy nawigacji po stronach

Jeśli koszyk się opróżnia, gdy klient przechodzi na inną stronę, ciasteczko sesji nie jest utrzymywane. Typowe przyczyny obejmują brakujące lub nieprawidłowe ustawienie domeny ciasteczka, nieprawidłowo skonfigurowany session.cookie_lifetime w PHP (ustawienie 0 oznacza, że ciasteczko wygasa po zamknięciu przeglądarki, co jest poprawne, ale niektóre konfiguracje ustawiają to na bardzo krótki czas), lub warstwa CDN lub cachowania, która usuwa nagłówek Set-Cookie z odpowiedzi.

Niepowodzenie realizacji zamówienia po płatności

Gdy klienci realizują płatność, ale widzą błąd lub pusty koszyk po powrocie do Twojego sklepu, polityka ciasteczek SameSite jest zazwyczaj przyczyną, jak opisano w sekcji dotyczącej bramek płatności powyżej. Przetestuj pełny przepływ realizacji zamówienia z otwartymi narzędziami deweloperskimi przeglądarki, obserwując ciasteczka na każdym etapie, aby zidentyfikować, gdzie sesja jest tracona.

Wiele sklepów w tej samej domenie

Jeśli prowadzisz wiele instalacji PrestaShop w tej samej domenie (na przykład w podkatalogach), ich ciasteczka mogą wchodzić w konflikt. Każda instalacja używa podobnej nazwy ciasteczka, a jeśli ścieżka ciasteczka jest ustawiona na /, ciasteczko jednego sklepu nadpisuje ciasteczko drugiego. Ustaw unikalne nazwy ciasteczek dla każdej instalacji poprzez _COOKIE_KEY_ (co wpływa na nazwę ciasteczka) lub skonfiguruj ścieżkę ciasteczka, aby pasowała do podkatalogu każdej instalacji.

Optymalizacja konfiguracji ciasteczek pod kątem wydajności

Dobrze zoptymalizowana konfiguracja ciasteczek PrestaShop minimalizuje narzut przy zachowaniu funkcjonalności. Użyj domeny bez ciasteczek lub CDN dla zasobów statycznych, aby uniknąć wysyłania ciasteczek z zapytaniami o obrazy, CSS i JavaScript. Utrzymuj mały rozmiar ciasteczka, zapobiegając przechowywaniu niepotrzebnych danych przez moduły. Ustaw odpowiednie timeouty sesji, które balansują bezpieczeństwo (krótsze jest bezpieczniejsze) z doświadczeniem użytkownika (dłuższe oznacza mniej ponownych logowań). Użyj Redis do przechowywania sesji, aby połączyć szybki dostęp ze współdzielonym stanem między instancjami serwera. Włącz atrybuty Secure i HttpOnly, aby chronić integralność ciasteczek bez wpływu na wydajność. Wdróż prawidłową zgodę na ciasteczka, aby uniknąć ładowania niepotrzebnych ciasteczek śledzenia, które dodają narzut i ryzyko prawne.

Każda z tych optymalizacji jest indywidualnie niewielka, ale razem tworzą znaczącą poprawę zarówno wydajności, jak i zgodności. Zarządzanie ciasteczkami nie jest efektowną pracą, ale stanowi podstawę każdej interakcji między Twoim sklepem a Twoimi klientami, co sprawia, że warto zrobić to dobrze.