Aus meiner Sicht gäbe es sehr gute Gründe dafür, dass JTL das originär verbauen sollte.
Nur der auf dem Server laufenden Anwendung selbst ist es sauber und zuverlässig möglich ist, die Cookie Request Anfragen zu blockieren oder freizugeben.
Der entsprechende Quellcode enthält zunächst keine Cookies außer dem einen Cookie, dass die Cookie Steuerung enthält.
Deshalb macht Microsoft ab VS 2019 das hier: Die Webanwendung (hier wäre das der
Shop) wird zunächst geladen mit nur einem Cookie namens CookieAccept, dass den Status
CookiesAcceptet per default auf
false setzt. Alle anderen Cookies werden also zunächst nicht einmal mehr geladen.
Erst nach dem Klick auf
Cookies erlaubt wird der Wert
CookiesAcceptet auf
true gesetzt und damit die anderen Cookies in den Quellcode der Website nachgeladen.
Die anderen Lösungen sind deshalb - aus meiner Sicht - allenfalls Workarounds, weil sie extern gesteuert werden und es funktionale Probleme gibt, wenn der User Drittanbieter-Cookies untersagt, also das extern laufende Steuerungs-Cookie gar nicht richtig gelesen werden kann.
Das verdeckte öffnen einer Datenverbindung (zum Beispiel "Matomo ohne Cookie" oder "Piwik ohne Cookie" oder wie sie alle heißen) ist definitiv noch verbotener als das nachvollziehbare Öffnen der Verbindungen. Es gaukelt vor keine Daten zu senden, in Wirklichkeit erfolgt dann doch eine Datenübertragung per Bulk-Abgleich.
Es ist nicht meine Absicht jemand zu ärgern, aber irgendwie ist das Thema noch nicht befriedigend durch
.
Ich persönlich würde mich jedenfalls sehr freuen, wenn das JTL Team das Abmahnrisiko für uns durch eine native Cookie-Steuerung aus der Welt schaffen würde.