Hey Patrick!
Danke für die Info. Also wird das Plugin erst nach dem release von 5.6.3 rauskommen ?
mfg
Marc
Denke, dass es etwa zeitgleich sein wird.
Kann man sich schon aus dem Fenster lehnen und sagen, dass es nächste Woche released wird?
[@Patrick Stahl](http://forum.shopware.com/profile/1869/Patrick Stahl „Patrick Stahl“) : Wie sieht es denn aus, wenn ein Plugin nur in JavaScript einen Cookie setzt/loescht? Das wuerde den ConsentManager ja umgehen, oder?
Wie waere denn da das konkrete Vorgehen, den Cookie zu setzen? Bzw. erst nach Einwilligung zu setzen?
VG
Und nicht den local- / session-storage vergessen - das ganze Regelwerk differenziert da nämlich nicht 
[@Patrick Stahl](http://forum.shopware.com/profile/1869/Patrick Stahl „Patrick Stahl“) : Wie sieht es denn aus, wenn ein Plugin nur in JavaScript einen Cookie setzt/loescht? Das wuerde den ConsentManager ja umgehen, oder?
Wie waere denn da das konkrete Vorgehen, den Cookie zu setzen? Bzw. erst nach Einwilligung zu setzen?
VG
Hallo,
es wurde ja schon mehrfach erwähnt, das Shopware automatisch alle Cookies zu Beginn blockiert - also auch Cookies, die (nachträglich) über JavaScript gesetzt werden. Wie man auf die Auswahl im Shopware Consent Tool in JavaScript reagiert, steht ja in der Dokumentation: Register a cookie to the cookie consent manager (speziell: $.getCookiePreference(cookieName) ). Darüber kann man dann ja problemlos steuern, ob man seinen Cookie über JavaScript setzen darf oder nicht.
Zum Thema localStorage: localStorage - Inhalte werden ja wie der Name schon sagt, lokal auf dem eigenen Rechner gespeichert - somit nicht im Browser und dies dürfte somit auch nicht in die Regel fallen und wäre somit auch nicht relevant (denn wie es das Thema schon sagt, geht es um Cookies, die im Browser gespeichert werden und somit im Prinzip Rückschlüsse auf das Kaufverhalten etc. geben könnten). Natürlich ist dies keine Rechtsberatung .
Grüße
Sebastian
Danke @sschreier für die schnelle Antwort 
. So 100%ig überzeugt bin ich noch nicht.
es wurde ja schon mehrfach erwähnt, das Shopware automatisch alle Cookies zu Beginn blockiert - also auch Cookies, die (nachträglich) über JavaScript gesetzt werden.
Dazu kann ich nichts finden. Ich sehe nur, wie sie auf PHP-Basis gelöscht werden (Code). Das löscht aber nicht durch JS gesetzte Cookies.
speziell: $.getCookiePreference(cookieName) ). Darüber kann man dann ja problemlos steuern, ob man seinen Cookie über JavaScript setzen darf oder nicht.
Den Artikel habe ich zwar gelesen, aber ganz anders verstanden:
We’re aware of the fact, that some plugins need to react properly once their cookie got activated or de-activated. For this reason, we also implemented a javascript event, which can be used to react on changes made to the customer’s preferences.
Das klingt für mich eher so: „Wir haben im Consent-Manager Javascript-Plugin noch ein paar Funktionen eingebaut, damit man die Kunden warnen kann, was passiert, wenn sie den Cookie blockieren.“ - Aber nicht, dass dein JS Cookie gelöscht wird.
Die von dir genannte Funktion getCookiePreference hätte ich eher so interpretiert, dass man damit dem Kunden dann durchgehend einen Hinweis einblenden kann „Geht nicht, weil der Cookie blockiert ist“. Allerdings kann man damit natürlich auch im Plugin prüfen, ob man den Cookie in erster Instanz überhaupt setzen darf. Aber soweit ich es sehe: Von JS gesetze Cookies werden nicht automatisch entfernt. Falls ich falsch liege, aber besten den entsprechenden Code zeigen, wo solche Cookies gelöscht werden.
Danke und VG
Das Gesetz unterscheidet nicht zwischen Cookie, local storage, oder fingerprinting
Hallo,
hier löscht es die Cookies: https://github.com/shopware/shopware/blob/4bb2df84d21f30b2fffd7084162c20ee3e69f135/engine/Shopware/Components/Privacy/CookieRemoveSubscriber.php#L134 . Auch JavaScript - Cookies landen am Ende dort, spätestens beim nächsten (Server-)Request, siehe dazu auch: „But what happens now when a plugin introduces a new cookie in Shopware? If you’re using the „Technically necessary cookies only“ mode, each cookie that is not known to Shopware 5.6.3, will automatically be deleted with every server response.“. Oder auch: „Cookies sind in RFC 2109 – HTTP State Management Mechanism definiert, stammen aus der CGI-Programmierung und können neben CGI und Javascript auch von PHP gesetzt und gelesen werden.“ ( https://www.mediaevent.de/javascript/cookies.html oder http://w3schools.invisionzone.com/topic/43768-php-cookies-vs-javascript-cookies/?tab=comments#comment-242601 ).
Wie bereits oben erwähnt: über $.getCookiePreference(cookieName) steuert man im JavaScript, ob man setCookie bei seinem Cookie machen darf oder nicht, da diese ja die Information beinhaltet, ob der Kunde den Cookie erlaubt hat oder nicht.
Grüße
Sebastian
hier löscht es die Cookies: https://github.com/shopware/shopware/blob/4bb2df84d21f30b2fffd7084162c20ee3e69f135/engine/Shopware/Components/Privacy/CookieRemoveSubscriber.php#L134 . Auch JavaScript - Cookies landen am Ende dort, spätestens beim nächsten (Server-)Request, siehe dazu auch: „But what happens now when a plugin introduces a new cookie in Shopware? If you’re using the „Technically necessary cookies only“ mode, each cookie that is not known to Shopware 5.6.3, will automatically be deleted with every server response.“.
Du hast dir meinen Beitrag nicht mal richtig durchgelesen. Die gleiche Codestelle habe ich auch verlinkt:
Dazu kann ich nichts finden. Ich sehe nur, wie sie auf PHP-Basis gelöscht werden (Code). Das löscht aber nicht durch JS gesetzte Cookies.
Genau die gleiche! xD
Und nein, das löscht keine JS Cookies. Nur weil diese nicht mehr zurückgesendet werden, löscht der Browser diese nicht. Google-Analytics-Cookies werden ja auch nicht von Shopware wieder zurückgeschickt. Die werden auch vom Browser deswegen nicht gelöscht.
Nimm dir doch etwas mehr Zeit für die Beiträge und lese meine zuvor in Ruhe durch.
VG
Hallo,
nur weil man nicht deine Meinung oder Ansicht vertritt, heißt das nicht, das man Beiträge nicht in Ruhe liest oder richtig. Du hast ja meinen scheinbar auch nicht korrekt gelesen, siehe die Verlinkungen (siehe: http://w3schools.invisionzone.com/topic/43768-php-cookies-vs-javascript-cookies/?tab=comments#comment-242601 und https://www.php.net/manual/de/function.header-remove.php bzw. „This function will remove all headers set by PHP, including cookies, session and the X-Powered-By headers.“). Du wolltest die Stelle, die hab ich genannt - da es die gleiche ist, kann ich wohl kaum eine andere nennen. Aber Hauptsache sinnlose Kommentare hinterlassen.
Und zum Schluss wohl das entscheidenste: hast du deine ganzen Behauptungen und Vermutungen auch mal getestet, dir also Shopware Version 5.6.3 mal eingespielt? Ich dagegen schon, und wenn ich über das Cookie Consent Tool von Shopware den Cookie erlaube, wird der JavaScript - Cookie des Plugins gesetzt (manuell selbst im Plugin mit setCookie(…) und der Prüfung auf $.getCookiePreference(cookieName)). Wenn ich nun wieder den Cookie die Erlaubnis über das Cookie Consent Tool von Shopware entziehe und die Seite neu lade, ist der JavaScript - Cookie des Plugins wieder weg (siehe Browser - Konsole von Google Chrome). Und das ohne das der JavaScript - Cookie durch das eigene Plugin gelöscht wurde oder ähnliches. Nun stellt sich am Ende die Frage wer recht hat, derjenige der es am Livesystem geprüft hat oder der, der Behauptungen und Vermutungen aufstellt.
Grüße
Sebastian
Jedes Plugin muss die Funktion unterstützen, es gibt zahlreiche Möglichkeiten Cookies zu setzen, gerade wenn die nicht die eigene Domain betreffen, kann man diese ohnehin nicht automatisiert löschen. Somit ist das erstmal nur ein Fallback, der Plugin-Hersteller dazu zwingt etwas zu ändern. Am besten sollte ein Plugin seinen Cookie nur setzen, wenn es auch erlaubt ist. Dazu gibt es ja die jeweiligen Javascript-Events.
Den Local Storage werden wir im ersten Wurf nicht automatisch löschen - generell kann aber auch das Schreiben des Local Storage durch jedes Plugin wie im Beitrag beschrieben abgehandelt werden. Eine Cleanup-Methode werden wir hier im zweiten Anlauf nochmal prüfen. Aber auch hier ist wieder zwischen technisch notwendigen Einträgen zu unterscheiden. Wenn personalisierte Inhalte, die eindeutig einem User zugeordnet werden können (DSGVO) im Local Storage stehen, dann muss das Plugin entsprechend auch auf die Javascript Events reagieren.
1 „Gefällt mir“
Moin zusammen!
Falls ich mich hier nochmal einhängen darf:
Der Cookie Consent Manager löscht definitiv auch die von JS gesetzten Cookies, aber eben erst mit der nächstbestem Response.
Wie passiert das?
Eben durch die von euch verlinkte Stelle.
Dazu kurz zur Erläuterung:
Hier werden die Cookies wieder entfernt, die mit dieser Response überhaupt erst gesetzt werden würden.
Es wird also verhindert, dass jemand via PHP Cookies schreiben will, die aber garnicht erlaubt sind. Beim Client kommt dieser Cookie nie an.
Nun zu dem für euch interessanten Teil:
Hier werden alle Cookies iteriert, die vom Client kamen, also bereits gesetzt sind. Sei es via Javascript, sei es via PHP, vollkommen gleich.
Jetzt sieht das natürlich aus, als würde hier ein weiterer Cookie gesetzt werden - wird es auch!
Einen Cookie löscht man, indem man den selben Cookie neu schreibt, mit dem selben Namen und dem selben Pfad, jedoch mit einem Expiry-Date in der Vergangenheit.
Das übernimmt die Response Klasse hier für uns, wenn man als 3. Parameter „0“ angibt, was so viel heißt wie „Läuft in 0 Sekunden aus“.
TL;DR: Von JS gesetzte Cookies werden mit der nächstbesten Response wieder gelöscht.
Übrigens:
Um in JS reagieren zu können, hast du zwei Möglichkeiten:
- Den von sschreier genannten Weg über die Methode $.getCookiePreference(), über die du zu jedem Zeitpunkt schauen kannst, ob dein Cookie erlaubt ist.
Hier wäre bspw. auch ein Loop möglich, der alle X Sekunden prüft, was der Zustand ist, und entsprechend darauf reagiert. - Gibt es das in der Doku genannte Event, welches auf’s Speichern reagiert, falls du wirklich sofort und live mit der Erlaubnis deines Cookies direkt reagieren willst.
Ich hoffe das hilft ein bisschen Licht ins Dunkle zu bringen.
Bzgl. LocalStorage hat ja Moritz schon einen Teil geschrieben.
Lieben Gruß
Patrick Stahl 
1 „Gefällt mir“
[@Patrick Stahl](http://forum.shopware.com/profile/1869/Patrick Stahl “Patrick Stahl”)
ich glaube das Problem welches @simkli hat, ist ein anderes.
Wie geht das denn, wenn ich rein über Javascript ein Cookie setze? So ein Cookie kann ich im ConsentManager ja nicht registrieren oder?
Oder was, wenn ich ein YouTube-Video über iFrame einbinde? YouTube setzt dann ein Cookie. Müsste ich das auch irgendwie registrieren? Ein Plugin dafür gibt es nicht, denn YouTube macht das automatisch sobald ich in der Artikelbeschreibung oder Einkaufswelt ein Video einbinde
Dann musst du dir ein Plugin schreiben, was einen Pseudo-Cookie dort registriert, darum wirst du nicht drum herum kommen, dann kannst du auch wieder darauf per Javascript reagieren. Diese neue Richtlinie bedarf ja immer einen größeren Aufwand bei der Implementierung.
1 „Gefällt mir“
Dann musst du dir ein Plugin schreiben, was einen Pseudo-Cookie dort registriert, darum wirst du nicht drum herum kommen, dann kannst du auch wieder darauf registrieren. Das bedingt ja zwangsweise, dass man als Entwickler Mehraufwand hat.
Und wie soll das der 08/15 Shopbetreiber bewerkstelligen, der kein Entwickler-Knowhow hat und einfach nur Produktvideos von YouTube oder Vimeo oder von so sonstwo zeigen will?
No Offense! Mir ist schon klar, dass es Programmierer gibt die man beauftragen kann und die sowas dann gegen Bezahlung machen.
Aber sooo speziell und ungewöhnlich ist diese Anforderung doch nicht. Also der Fall dass YouTube-Videos in Shops verwendet werden. Kann man das nicht in der kommenden Standardlösung schon berücksichtigen? So dass nicht jeder Shopbetreiber nochmal per Individualprogrammierung eines weiteren Plugins nachbessern muss?
Dann musst du dir ein Plugin schreiben, was einen Pseudo-Cookie dort registriert, darum wirst du nicht drum herum kommen, dann kannst du auch wieder darauf registrieren. Das bedingt ja zwangsweise, dass man als Entwickler Mehraufwand hat.
Und wie soll das der 08/15 Shopbetreiber bewerkstelligen, der kein Entwickler-Knowhow hat und einfach nur Produktvideos von YouTube oder Vimeo oder von so sonstwo zeigen will?
No Offense! Mir ist schon klar, dass es Programmierer gibt die man beauftragen kann und die sowas dann gegen Bezahlung machen.
Aber sooo speziell und ungewöhnlich ist diese Anforderung doch nicht. Also der Fall dass YouTube-Videos in Shops verwendet werden. Kann man das nicht in der kommenden Standardlösung schon berücksichtigen? So dass nicht jeder Shopbetreiber nochmal per Individualprogrammierung eines weiteren Plugins nachbessern muss?
Naja, der Shopbetreiber musste das bisher auch schon über eine 2-Klick Lösung lösen. Denn es war auch vorher schon nicht korrekt einfach so ein Youtube Video einzubinden. 2-Klick Lösungen gibt es ja im Internet zu Hauf. Darüber muss man sich natürlich gedanken machen.
Grundsätzlich ist es aber auch der Falsche Ansatz ein Optin für Youtube.com auf der eigenen Seite einzuholen, wenn das Video per Iframe geladen wird. Das muss eigentlich im Video selbst erfolgen, da hier klar ist, dass man eine andere Seite einbindet. Man kann das programmatisch lösen oder muss halt Youtube über eine solche 2-Klick Lösung einbinden.
[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski „Moritz Naczenski“) aber auch diese 2-Klick-Lösung für YouTube wird für „normale“ Shopbetreiber ohne Knowhow nicht zu bewerkstelligen sein…
1 „Gefällt mir“
[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski „Moritz Naczenski“) aber auch diese 2-Klick-Lösung für YouTube wird für „normale“ Shopbetreiber ohne Knowhow nicht zu bewerkstelligen sein…
Aber das hat mit dem Consent-Tool ja nichts zu tun. Man kann ja über ein Feature sprechen, was eine solche Einbindung in Zukunft erleichern würde - der Consent Manager hat aber nichts mit der Einbindung der Videos zu tun. Da ist ja eine komplett andere Anforderung „Als Shopbetreiber möchte ich Youtube Videos gerne rechtskonform einbinden“, die aber auch ohne den Consent Manager genau so lauten würde. An dem Sachverhalt ändert sich davor und danach nichts - auch an der Sachlage, dass ich die so einbinden muss nicht.
Das war vor einem Jahr eine Templateanpassung und ist weiterhin eine Templateanpassung. Warum sollte ein Tool zum verwalten von Cookies etwas an der Einbindung von Videos ändern? Für mich ein typischer Feature-Request, den ihr gerne mal einstellen könnt.
Die große Gefahr besteht ja darin, dass Shopbetreiber die sowohl juristisch als auch technisch nur ein grobes Halbwissen haben, sich womöglich in Sicherheit wähnen und guten Glaubens sind mit der Einrichtung des Consent-Tools alles Nötige und Richtige getan zu haben.
Wer diese Forendiskussion nicht mitverfolgt, erfährt ja womöglich dann auch nicht von den Stolpersteinen und nachbesserungsbedürftigen Lücken.
Viele wissen ja nicht was ein iFrame ist oder wie ein YouTube Video technisch eingebunden ist. Die nehmen den EMBED-Code und knallen den rein, fertig. Und da sie ja ein Cookie-Consent-Tool installiert haben, gehen sie (irrtümlich) davon aus, dass dieses die Cookies dann schon gesetzeskonform regelt.