PrestaShop Cookie-Probleme: Sitzungsfehler, DSGVO und Leistung

Wie PrestaShop Cookies verwendet

Jeder PrestaShop-Shop ist auf Cookies angewiesen, um zu funktionieren. Sie verwalten Kundensitzungen, merken sich Warenkorbinhalte, speichern Sprach- und Währungspräferenzen, verfolgen den Anmeldestatus und ermöglichen es dem Back-Office, Administratoren zu authentifizieren. Ohne Cookies kann ein PrestaShop-Shop keinen Zustand zwischen Seitenaufrufen aufrechterhalten, was bedeutet: kein Warenkorb, keine Kundenanmeldung und kein Admin-Zugriff.

PrestaShop verwendet zwei primäre Cookies. Das Front-Office-Cookie, das typischerweise nach Ihrem Shop benannt ist (wie PrestaShop-abc123), verwaltet alles, was die kundenseitige Oberfläche benötigt. Das Back-Office-Cookie mit einem ähnlichen Benennungsmuster, aber anderem Geltungsbereich, verwaltet die Administrator-Authentifizierung. Beide Cookies speichern serialisierte Daten direkt im Cookie-Wert, was eine Designentscheidung ist, die erhebliche Auswirkungen auf Leistung, Sicherheit und DSGVO-Konformität hat.

PrestaShop-Cookie-Struktur und Inhalte

Anders als viele Webanwendungen, die nur eine Sitzungs-ID im Cookie speichern und alle Sitzungsdaten auf dem Server halten, speichert PrestaShop umfangreiche Daten direkt im Cookie selbst. Das Front-Office-Cookie enthält Felder einschließlich der Kunden-ID, des Kundennamens und der E-Mail, ob der Kunde angemeldet ist, der Warenkorb-ID, der ausgewählten Sprache, der ausgewählten Währung, der zuletzt besuchten Kategorie, des zuletzt besuchten Produkts, des Checkout-Schritts und verschiedener anderer Zustandsinformationen.

Diese Daten werden mit PrestaShops eigener Cookie-Klasse (Cookie.php im Verzeichnis classes) serialisiert. Der Cookie-Wert wird mit einem Schlüssel verschlüsselt, der aus Ihrer _COOKIE_KEY_-Konstante in config/settings.inc.php (PrestaShop 1.6/1.7) oder app/config/parameters.php (PrestaShop 8.x) abgeleitet wird. Diese Verschlüsselung verhindert Manipulation und schützt sensible Daten wie die Kunden-ID und E-Mail davor, im Browser lesbar zu sein.

Warum PrestaShop Daten im Cookie speichert

Der historische Grund für dieses Design ist die Leistung. Durch die Speicherung von Sitzungsdaten im Cookie vermeidet PrestaShop eine serverseitige Sitzungsabfrage bei jeder Anfrage. Es ist kein Lesen aus einer Sitzungsdatei, keine Datenbankabfrage und keine Verbindung zu einem Sitzungsserver erforderlich. Die Daten kommen mit der Anfrage und sind sofort verfügbar.

Dieser Ansatz hat jedoch Nachteile, die mit wachsenden Shops relevanter werden. Die Cookie-Größe nimmt mit der Menge der gespeicherten Daten zu, und jede HTTP-Anfrage (einschließlich Anfragen für Bilder, CSS- und JavaScript-Dateien) sendet das vollständige Cookie an den Server. Ein 4 KB großes Cookie, das mit 30 Asset-Anfragen pro Seite gesendet wird, bedeutet 120 KB unnötige Upload-Bandbreite pro Seitenaufruf. Dieser Overhead ist bei mobilen Verbindungen und im großen Maßstab messbar.

Cookie-Größe und Leistungsauswirkungen

Browser-Cookies haben ein praktisches Größenlimit von etwa 4.096 Bytes pro Cookie. PrestaShops Front-Office-Cookie kann sich diesem Limit nähern oder es überschreiten, insbesondere wenn Module ihre eigenen Daten zum Cookie hinzufügen, sei es über den hookActionBeforeSubmitAccount oder durch direkte Änderung des Cookie-Objekts.

Messung der Cookie-Größen-Auswirkung

Um zu sehen, wie Cookies die Leistung Ihres Shops beeinflussen, öffnen Sie die Entwicklertools Ihres Browsers und gehen Sie zum Tab Netzwerk. Schauen Sie sich die Anfrage-Header für jede Anfrage an Ihre Domain an. Der Cookie-Header zeigt alle gesendeten Cookies. Notieren Sie die Größe. Schauen Sie sich nun die Anfrage-Header für eine statische Ressource (ein Bild oder eine CSS-Datei) auf derselben Domain an. Dieselben Cookies werden auch mit dieser Anfrage gesendet und erzeugen Overhead ohne Grund.

Reduzierung des Cookie-Overheads für statische Ressourcen

Der effektivste Weg, den Cookie-Overhead für statische Dateien zu eliminieren, ist, sie von einer anderen Domain (einer cookielosen Domain) auszuliefern. In PrestaShop können Sie Medienserver im Back-Office unter Erweiterte Einstellungen > Leistung konfigurieren. Wenn Sie einen Medienserver wie static.ihredomain.de einrichten, liefert PrestaShop Bilder, CSS und JavaScript von dieser Domain aus. Da Cookies domainspezifisch sind, werden keine Cookies mit Anfragen an die Medien-Domain gesendet.

Alternativ kann ein CDN wie Cloudflare, Fastly oder CloudFront Ihre statischen Ressourcen ausliefern. CDN-Edge-Server entfernen typischerweise Cookies aus zwischengespeicherten Antworten, sodass selbst wenn Cookies in der Anfrage gesendet werden, die Antwort aus dem Cache kommt, ohne den Overhead eines Roundtrips zu Ihrem Ursprungsserver.

Cookie-Aufblähung durch Module

Drittanbieter-Module fügen manchmal Daten zum PrestaShop-Cookie hinzu, ohne die Größenauswirkungen zu berücksichtigen. Jedes Modul, das einen Wert im Cookie speichert, erhöht dessen Größe und den Overhead bei jeder Anfrage. Wenn Ihr Cookie ungewöhnlich groß ist, prüfen Sie, welche Daten Module hinzugefügt haben, indem Sie den entschlüsselten Cookie-Inhalt untersuchen oder den Modulcode auf Aufrufe wie $this->context->cookie->mymodule_value = ... überprüfen.

Gut konzipierte Module verwenden serverseitigen Speicher (Datenbank oder Cache) und speichern höchstens einen kleinen Identifikator im Cookie. Schlecht konzipierte Module laden vollständige Datenstrukturen in das Cookie und blähen es auf. Wenn Sie ein problematisches Modul identifizieren, wenden Sie sich an den Entwickler oder ersetzen Sie die Cookie-Speicherung durch datenbankgestützten Speicher mit einer Sitzungskennung.

Sitzungsverwaltung: Dateien, Datenbank und Redis

Während PrestaShop einige Daten direkt in Cookies speichert, unterhält PHP auch sein eigenes Sitzungssystem. PrestaShops Back-Office ist stärker auf PHP-Sitzungen angewiesen als das Front-Office. Der Sitzungs-Handler bestimmt, wo Sitzungsdaten auf der Serverseite gespeichert werden.

Dateibasierte Sitzungen (Standard)

Standardmäßig speichert PHP Sitzungen als Dateien im Verzeichnis session.save_path (typischerweise /tmp oder /var/lib/php/sessions). Jede Sitzung erstellt eine Datei. Für einen Shop mit Tausenden aktiver Sitzungen bedeutet dies Tausende kleiner Dateien. Dateibasierte Sitzungen funktionieren gut für kleine bis mittlere Shops, können aber bei Skalierung Probleme verursachen.

Häufige Probleme mit dateibasierten Sitzungen umfassen eine langsame Sitzungs-Garbage-Collection, wenn das Sitzungsverzeichnis zu viele Dateien enthält, Dateisperren, die eine Serialisierung von Anfragen verursachen können (zwei Anfragen derselben Sitzung können nicht gleichzeitig verarbeitet werden), und Shared-Hosting-Umgebungen, in denen das Sitzungsverzeichnis voll wird oder restriktive Berechtigungen hat.

Datenbank-Sitzungen

PrestaShop unterstützt das Speichern von Sitzungen in der Datenbank. Dies wird in den PHP-Einstellungen oder über PrestaShops Sitzungs-Handler konfiguriert. Datenbank-Sitzungen beseitigen die Dateisystemprobleme, fügen aber jeder Anfrage eine Datenbankabfrage hinzu. Für Shops mit bereits hoher Datenbankbelastung kann dies die Leistung verschlechtern. Datenbank-Sitzungen haben jedoch den Vorteil, dass sie über mehrere Webserver in einem lastverteilten Setup gemeinsam genutzt werden können.

Redis- oder Memcached-Sitzungen

Für PrestaShop-Shops mit hohem Traffic ist Redis der optimale Sitzungsspeicher-Backend. Redis speichert Sitzungsdaten im Arbeitsspeicher und bietet Zugriffszeiten unter einer Millisekunde. Es unterstützt automatisches Ablaufen (Sitzungs-Timeout), und Sitzungsdaten werden über alle Webserver-Instanzen hinweg gemeinsam genutzt.

Um PHP für die Verwendung von Redis für Sitzungen zu konfigurieren, setzen Sie session.save_handler = redis und session.save_path = "tcp://127.0.0.1:6379" in Ihrer php.ini oder PHP-FPM-Pool-Konfiguration. Wenn Ihre Redis-Instanz eine Authentifizierung erfordert, fügen Sie das Passwort zum Speicherpfad hinzu: "tcp://127.0.0.1:6379?auth=ihrpasswort".

PrestaShop unterstützt bereits Redis für Objekt-Caching (konfiguriert im Back-Office unter Erweiterte Einstellungen > Leistung). Die Verwendung derselben Redis-Instanz für Sitzungen und Objekt-Caching vereinfacht Ihre Infrastruktur und bietet gleichzeitig hervorragende Leistung für beides.

SameSite-, Secure- und HttpOnly-Attribute

Moderne Browser erzwingen Cookie-Sicherheitsattribute, die direkt beeinflussen, wie PrestaShop-Cookies funktionieren. Falsch konfigurierte Cookie-Attribute verursachen Anmeldefehler, verlorene Warenkörbe und Fehler bei der Zahlungsabwicklung.

SameSite-Attribut

Das SameSite-Attribut steuert, ob ein Cookie mit Cross-Site-Anfragen gesendet wird. Es hat drei mögliche Werte:

SameSite=Strict bedeutet, dass das Cookie niemals mit Cross-Site-Anfragen gesendet wird. Dies ist zu restriktiv für PrestaShop, da Kunden, die einen Link zu Ihrem Shop aus einer E-Mail oder einem Social-Media-Beitrag anklicken, ihr Sitzungs-Cookie nicht gesendet bekommen und somit effektiv abgemeldet werden.

SameSite=Lax ist der Standard in modernen Browsern. Das Cookie wird mit Top-Level-Navigationen (Klick auf einen Link) gesendet, aber nicht mit Cross-Site-Unteranfragen (Bilder, Iframes, AJAX). Dies funktioniert in den meisten Fällen gut für PrestaShops Front-Office-Cookie.

SameSite=None bedeutet, dass das Cookie immer gesendet wird, auch mit Cross-Site-Anfragen. Dies muss mit dem Secure-Attribut kombiniert werden. Es wird benötigt, wenn Ihr Shop in einem Iframe auf einer anderen Website eingebettet ist oder wenn Zahlungsgateways von Drittanbietern mit intakter Sitzung zu Ihrem Shop zurückleiten müssen.

Zahlungsgateway-Probleme

Viele PrestaShop-Zahlungsprobleme werden durch SameSite-Cookie-Probleme verursacht. Das typische Szenario ist: Ein Kunde geht zur Kasse, wird zur Website des Zahlungsgateways weitergeleitet, schließt die Zahlung ab und wird zu Ihrem Shop zurückgeleitet. Wenn das Sitzungs-Cookie SameSite=Lax hat, wird es bei der Rückleitung vom Zahlungsgateway möglicherweise nicht gesendet, abhängig davon, wie die Weiterleitung implementiert ist. Wenn das Gateway eine POST-Weiterleitung verwendet (üblich bei 3D Secure), blockiert die Lax-Richtlinie das Cookie, und PrestaShop verliert die Sitzung. Der Kunde sieht einen leeren Warenkorb oder eine generische Fehlerseite anstelle der Bestellbestätigung.

Die Lösung besteht darin, das PrestaShop-Cookie auf SameSite=None; Secure zu setzen. In PrestaShop 1.7.7+ und 8.x kann dies in den Cookie-Einstellungen konfiguriert werden. Für ältere Versionen müssen Sie möglicherweise die Cookie-Klasse ändern oder Header über Ihre Webserver-Konfiguration hinzufügen. Testen Sie immer die Zahlungsabläufe nach der Änderung der SameSite-Einstellungen.

Secure-Attribut

Das Secure-Attribut stellt sicher, dass das Cookie nur über HTTPS-Verbindungen gesendet wird. Wenn Ihr Shop über HTTPS läuft (was der Fall sein sollte), verhindert dieses Attribut, dass das Cookie über eine unverschlüsselte Verbindung übertragen wird und schützt es vor Abfangen. PrestaShop setzt dieses Attribut, wenn der Shop eine HTTPS-Verbindung erkennt.

Ein häufiges Problem tritt bei gemischten HTTP/HTTPS-Konfigurationen auf. Wenn Ihr Back-Office auf HTTPS läuft, aber einige Front-Office-Seiten auf HTTP, werden als Secure markierte Cookies auf HTTP-Seiten nicht gesendet und die Sitzung wird unterbrochen. Die Lösung ist, HTTPS überall zu erzwingen, was Sie ohnehin aus Sicherheits- und SEO-Gründen tun sollten.

HttpOnly-Attribut

Das HttpOnly-Attribut verhindert, dass JavaScript über document.cookie auf das Cookie zugreifen kann. Dies ist eine wichtige Sicherheitsmaßnahme gegen Cross-Site-Scripting (XSS)-Angriffe. Wenn ein Angreifer bösartiges JavaScript in Ihren Shop injiziert (z. B. über ein anfälliges Modul), verhindert das HttpOnly-Attribut, dass dieser Code Sitzungs-Cookies stehlen kann.

PrestaShop setzt das HttpOnly-Flag standardmäßig auf seine Cookies. Deaktivieren Sie dies nicht, es sei denn, Sie haben einen sehr spezifischen Grund und verstehen die Sicherheitsimplikationen.

Fehlersuche bei Sitzungs- und Cookie-Problemen

Cookie- und Sitzungsprobleme äußern sich durch mysteriöse Symptome: Kunden werden zufällig abgemeldet, Warenkörbe leeren sich von selbst, Admin-Sitzungen laufen sofort ab, Checkout-Prozesse scheitern still. Systematische Fehlersuche erfordert die Überprüfung mehrerer Ebenen.

Browser-Entwicklertools

Öffnen Sie den Tab Anwendung (Chrome) oder Speicher (Firefox) und navigieren Sie zu Cookies. Finden Sie die Domain Ihres Shops und untersuchen Sie alle Cookies. Prüfen Sie die Spalten Name, Wert, Domain, Pfad, Ablaufdatum, Größe, HttpOnly, Secure und SameSite. Achten Sie auf Cookies, die unerwartet groß sind, falsche Domain-Einstellungen haben (ein Cookie für www.beispiel.de wird nicht an beispiel.de gesendet) oder denen Sicherheitsattribute fehlen.

Serverseitige Sitzungsüberprüfung

Wenn Sitzungen in Dateien gespeichert werden, prüfen Sie das Sitzungsverzeichnis auf Vorhandensein und Alter der Sitzungsdateien. Wenn ein Kunde berichtet, abgemeldet worden zu sein, finden Sie seine Sitzungsdatei (der Dateiname ist die Sitzungs-ID aus dem PHPSESSID-Cookie) und prüfen Sie, wann sie zuletzt geändert wurde. Wenn die Datei fehlt, wurde die Sitzung entweder durch die Garbage Collection bereinigt oder nie korrekt erstellt.

Für Redis-Sitzungen verwenden Sie redis-cli, um zu prüfen, ob der Sitzungsschlüssel existiert: EXISTS PHPREDIS_SESSION:session_id. Prüfen Sie die TTL, um zu sehen, ob sie bald abläuft: TTL PHPREDIS_SESSION:session_id.

Häufige Ursachen für zufällige Abmeldungen

Der _COOKIE_KEY_ hat sich geändert. Wenn sich dieser Schlüssel ändert (bei einer fehlkonfigurierten Bereitstellung, einem Überschreiben der Einstellungsdatei oder einem Upgrade), werden alle vorhandenen Cookies unlesbar, da sie mit dem alten Schlüssel verschlüsselt wurden. Jeder Kunde wird effektiv abgemeldet. Die Lösung besteht darin, den ursprünglichen Schlüssel aus einem Backup wiederherzustellen.

Die Sitzungs-Garbage-Collection ist zu aggressiv. PHPs session.gc_maxlifetime bestimmt, wie lange (in Sekunden) eine Sitzungsdatei als gültig betrachtet wird. Wenn dieser Wert zu niedrig eingestellt ist (der Standard ist 1440 Sekunden oder 24 Minuten), werden Sitzungen für Kunden, die langsam browsen, gelöscht. Für einen Shop sollten Sie diesen Wert auf mindestens 3600 (1 Stunde) oder höher setzen.

Load Balancer ohne Sitzungsaffinität. Wenn Ihr Shop auf mehreren Webservern hinter einem Load Balancer läuft und Sitzungen in Dateien gespeichert werden, hat jeder Server sein eigenes Sitzungsverzeichnis. Ein Kunde, dessen Anfragen zwischen Servern alternieren, verliert bei jedem Wechsel seine Sitzung. Die Lösung ist entweder Sitzungsaffinität (Sticky Sessions) auf dem Load Balancer oder gemeinsamer Sitzungsspeicher über Redis oder eine Datenbank.

Cookie-Domain-Nichtübereinstimmung. Wenn Ihr Shop sowohl unter www.beispiel.de als auch unter beispiel.de erreichbar ist, aber die Cookie-Domain auf www.beispiel.de gesetzt ist, haben Kunden, die die Seite ohne das www-Präfix aufrufen, das Cookie nicht. Stellen Sie eine konsistente Domain-Nutzung mit einer Weiterleitung sicher und überprüfen Sie die Cookie-Domain in den PrestaShop-Einstellungen.

DSGVO-Cookie-Konformität

Die Datenschutz-Grundverordnung (DSGVO) und die ePrivacy-Richtlinie erfordern eine informierte Einwilligung, bevor nicht-essentielle Cookies im Browser eines Nutzers gesetzt werden. PrestaShop-Shops müssen diese Vorschriften einhalten, und Nichteinhaltung kann zu erheblichen Bußgeldern führen.

Essentielle vs. nicht-essentielle Cookies

Die DSGVO unterscheidet zwischen Cookies, die für die Funktion der Website streng notwendig sind, und Cookies, die anderen Zwecken dienen, wie Analysen, Marketing oder Personalisierung. PrestaShops Sitzungs-Cookie ist essentiell, da der Shop ohne es nicht funktionieren kann. Ein Kunde kann keine Produkte zum Warenkorb hinzufügen oder einen Kauf abschließen, ohne ein Sitzungs-Cookie. Essentielle Cookies erfordern keine Einwilligung nach der DSGVO.

Viele andere Cookies, die häufig in PrestaShop-Shops zu finden sind, sind jedoch nicht-essentiell und erfordern eine ausdrückliche Einwilligung, bevor sie gesetzt werden. Dazu gehören Google Analytics Tracking-Cookies (_ga, _gid), Facebook-Pixel-Cookies, Werbe-Cookies von Remarketing-Plattformen, Live-Chat-Widget-Cookies, Social-Media-Sharing-Button-Cookies und alle Cookies, die von Drittanbieter-Modulen für Tracking oder Personalisierung gesetzt werden.

Implementierung der Cookie-Einwilligung

PrestaShop enthält keinen eingebauten Cookie-Einwilligungsmechanismus, der den DSGVO-Anforderungen entspricht. Sie benötigen entweder ein PrestaShop-Modul, das für die Cookie-Einwilligung konzipiert ist, oder die Integration mit einer Consent-Management-Plattform (CMP) wie Cookiebot, Osano oder Usercentrics.

Eine ordnungsgemäße Cookie-Einwilligungs-Implementierung muss dem Nutzer eine klare Wahl präsentieren, bevor nicht-essentielle Cookies gesetzt werden. Sie muss dem Nutzer ermöglichen, einzelne Cookie-Kategorien (Analyse, Marketing usw.) zu akzeptieren oder abzulehnen, und nicht nur eine Alles-oder-Nichts-Wahl anbieten. Sie muss die Wahl des Nutzers speichern und nicht erneut fragen, bis die Einwilligung abläuft. Und sie muss tatsächlich verhindern, dass die blockierten Cookies gesetzt werden, anstatt nur die Präferenz aufzuzeichnen und trotzdem Tracking-Codes zu laden.

Der letzte Punkt ist entscheidend und wird häufig falsch gehandhabt. Ein Einwilligungsbanner, das angezeigt wird, aber unabhängig von der Wahl des Nutzers trotzdem Google Analytics lädt, bietet keinen rechtlichen Schutz. Die Implementierung muss das Laden von Tracking- und Marketing-Ressourcen konditional auf der Grundlage der Einwilligung des Nutzers steuern.

Technische Implementierung der Einwilligung

Der technische Ansatz für einwilligungsbasiertes Cookie-Management umfasst das Einbetten von nicht-essentiellem Code in Einwilligungsprüfungen. Für Inline-JavaScript, das Cookies setzt oder Tracking-Pixel lädt, wird die direkte Ausführung durch einen einwilligungsgesteuerten Loader ersetzt. Der Tracking-Code wird gespeichert, aber erst ausgeführt, wenn der Nutzer seine Einwilligung gibt.

Für Drittanbieter-Module, die Cookies setzen, ist die Implementierung komplexer. Einige Module bieten Hooks oder Konfigurationsoptionen für die Einwilligungsintegration. Andere laden ihre Cookies bedingungslos und müssen modifiziert oder ersetzt werden. Prüfen Sie jedes Modul in Ihrem Shop auf Cookie-Nutzung und bestimmen Sie, welche nicht-essentielle Cookies setzen.

Cookie-Einwilligung und Caching

Ganzseiten-Caching erzeugt einen Konflikt mit der Cookie-Einwilligung. Wenn eine Seite mit geladenem Google Analytics zwischengespeichert und einem Nutzer ausgeliefert wird, der keine Einwilligung gegeben hat, verstoßen Sie gegen die DSGVO. Es gibt zwei Ansätze, um damit umzugehen.

Der erste Ansatz besteht darin, die Seite ohne nicht-essentielle Ressourcen zwischenzuspeichern und sie dynamisch per JavaScript nach der Einwilligungsprüfung zu injizieren. Dies funktioniert gut mit PrestaShops CCC-System (Combine, Compress, Cache) und mit Varnish oder anderen Reverse-Proxy-Caches.

Der zweite Ansatz besteht darin, Seiten für Nutzer, die noch keine Einwilligungsentscheidung getroffen haben (Erstbesucher), nicht zwischenzuspeichern. Dies beeinträchtigt die Leistung für neue Besucher, stellt aber die Konformität sicher. Die meisten Consent-Management-Plattformen verwenden den ersten Ansatz, da er die Caching-Vorteile erhält.

Cookie-bezogene Sicherheitsbedenken

Über die bereits besprochenen HttpOnly- und Secure-Attribute hinaus gibt es zusätzliche Sicherheitsaspekte für PrestaShop-Cookies.

Cookie-Diebstahl und Sitzungsübernahme

Wenn ein Angreifer ein gültiges PrestaShop-Sitzungs-Cookie erhält, kann er den Kunden oder Administrator imitieren. Der primäre Schutz besteht aus HTTPS überall (verhindert Abfangen), HttpOnly-Cookies (verhindert XSS-Diebstahl) und dem Secure-Attribut (verhindert Übertragung über HTTP). PrestaShop bindet Sitzungen in einigen Konfigurationen auch an IP-Adressen, was eine zusätzliche Schutzschicht bietet, aber Probleme für Nutzer verursachen kann, deren IP-Adressen sich ändern (mobile Nutzer, VPN-Nutzer).

Cookie-Schlüsselsicherheit

Der _COOKIE_KEY_ in Ihrer PrestaShop-Konfiguration ist der Hauptschlüssel für die Cookie-Verschlüsselung. Wenn dieser Schlüssel kompromittiert wird, kann ein Angreifer jedes PrestaShop-Cookie entschlüsseln und gültige Sitzungs-Cookies fälschen. Schützen Sie diesen Schlüssel, indem Sie den Zugriff auf Ihre Konfigurationsdateien einschränken, ihn nie in öffentlichen Repositories committen und ihn nie in Supportanfragen teilen.

Cookie-Fixierung-Prävention

Sitzungsfixierungsangriffe beinhalten, dass ein Angreifer eine bekannte Sitzungs-ID im Browser des Opfers setzt, bevor das Opfer sich anmeldet. Wenn sich das Opfer anmeldet, wird die vom Angreifer voreingestellte Sitzungs-ID authentifiziert. PrestaShop mindert dies, indem die Sitzungs-ID bei der Anmeldung neu generiert wird. Stellen Sie sicher, dass die Sitzungs-ID-Neugenerierung korrekt funktioniert und nicht durch ein Modul oder eine Konfigurationsänderung deaktiviert wurde.

Fehlerbehebung häufiger Cookie-Probleme

Admin-Panel Anmelde-Schleife

Das Symptom ist die Eingabe gültiger Anmeldedaten im PrestaShop Back-Office, kurzes Sehen des Dashboards und Weiterleitung zurück zur Anmeldeseite. Dies ist fast immer ein Cookie-Problem. Prüfen Sie, ob die Cookie-Domain korrekt ist, ob sich der Admin-Verzeichnisname geändert hat, ob HTTPS korrekt konfiguriert ist (Mixed Content kann verhindern, dass das Secure-Cookie gesendet wird) und ob das Sitzungsspeicherverzeichnis vom Webserver beschreibbar ist.

Warenkorb leert sich bei Seitennavigation

Wenn sich der Warenkorb leert, wenn der Kunde zu einer anderen Seite navigiert, wird das Sitzungs-Cookie nicht aufrechterhalten. Häufige Ursachen sind eine fehlende oder falsche Cookie-Domain-Einstellung, eine fehlkonfigurierte session.cookie_lifetime in PHP (der Wert 0 bedeutet, dass das Cookie abläuft, wenn der Browser geschlossen wird, was korrekt ist, aber einige Konfigurationen setzen ihn auf eine sehr kurze Zeit) oder ein CDN oder eine Caching-Schicht, die den Set-Cookie-Header aus Antworten entfernt.

Checkout-Fehler nach Zahlung

Wenn Kunden die Zahlung abschließen, aber beim Zurückkehren zu Ihrem Shop einen Fehler oder leeren Warenkorb sehen, ist die SameSite-Cookie-Richtlinie in der Regel die Ursache, wie im Abschnitt zu Zahlungsgateways oben beschrieben. Testen Sie den gesamten Checkout-Ablauf mit geöffneten Browser-Entwicklertools und beobachten Sie die Cookies in jedem Schritt, um festzustellen, wo die Sitzung verloren geht.

Mehrere Shops auf derselben Domain

Wenn Sie mehrere PrestaShop-Installationen auf derselben Domain betreiben (z. B. in Unterverzeichnissen), können deren Cookies in Konflikt geraten. Jede Installation verwendet einen ähnlichen Cookie-Namen, und wenn der Cookie-Pfad auf / gesetzt ist, überschreibt das Cookie eines Shops das des anderen. Setzen Sie eindeutige Cookie-Namen für jede Installation über den _COOKIE_KEY_ (der den Cookie-Namen beeinflusst) oder konfigurieren Sie den Cookie-Pfad so, dass er dem Unterverzeichnis jeder Installation entspricht.

Optimierung der Cookie-Konfiguration für Leistung

Eine gut optimierte PrestaShop-Cookie-Konfiguration minimiert den Overhead bei Erhaltung der Funktionalität. Verwenden Sie eine cookielose Domain oder ein CDN für statische Ressourcen, um das Senden von Cookies mit Bild-, CSS- und JavaScript-Anfragen zu vermeiden. Halten Sie die Cookie-Größe klein, indem Sie verhindern, dass Module unnötige Daten darin speichern. Setzen Sie angemessene Sitzungs-Timeouts, die Sicherheit (kürzer ist sicherer) mit Benutzererfahrung (länger bedeutet weniger erneute Anmeldungen) in Einklang bringen. Verwenden Sie Redis für den Sitzungsspeicher, um schnellen Zugriff mit gemeinsamem Zustand über Server-Instanzen hinweg zu kombinieren. Aktivieren Sie die Secure- und HttpOnly-Attribute, um die Cookie-Integrität zu schützen, ohne die Leistung zu beeinträchtigen. Implementieren Sie eine ordnungsgemäße Cookie-Einwilligung, um das Laden unnötiger Tracking-Cookies zu vermeiden, die Overhead und rechtliches Risiko hinzufügen.

Jede dieser Optimierungen ist für sich genommen klein, aber zusammen ergeben sie eine deutliche Verbesserung sowohl der Leistung als auch der Konformität. Cookie-Management ist keine glamouröse Arbeit, aber es liegt jeder Interaktion zwischen Ihrem Shop und Ihren Kunden zugrunde und ist es daher wert, richtig gemacht zu werden.