FriendsOfREDAXO
Attribut "SameSite"
Das Cookie "iwcc" wird in Zukunft bald abgelehnt werden, da es für das Attribut "SameSite" entweder "None" oder einen ungültigen Wert angibt, ohne das "secure"-Attribut zu verwenden. Weitere Informationen zum "SameSite"-Attribut finden Sie unter https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite.
Sehe ich auch im Firefox (und zwar nur im FF, in keinem anderen Browser), kann mir aber keinen Reim drauf machen. Aktuell haben die Cookies SameSite:Lax und Secure:false. Wenn ich auf Secure:true umstelle (nur noch Cookies über https) kommt die Meldung trotzdem. In welchen Browsern siehst du die Meldung?
Sorry, hätte ich noch dazu schreiben können. Auch im Firefox und FirefoxDeveloper. Der meckert auch ein test-cookie von js-cookie an.
Ja, das wird ja mit den gleichen Einstellungen gesetzt wie das iwcc Cookie: https://github.com/FriendsOfREDAXO/iwcc/blob/master/assets/iwcc_frontend.js#L16 https://github.com/FriendsOfREDAXO/iwcc/blob/master/assets/iwcc_frontend.js#L113
Ich hab das auch in Firefox gesehen. wollte es ändern und hab dann festgestellt, dass das consent cookie nicht über php gesetzt wird (gibt keinerlei setcookie() ) , sondern offenbar über JS. Diese 3 sollten nach der Domain (expires, path, domain, gesetzt sein: 'secure' => true, // or false 'httponly' => true, // or false 'samesite' => 'strict' // None || Lax || Strict
also in php setcookie(expires, path, domain, true, true, 'strict')
dann klappt es. Hab ich mit einem anderen php-Cookie so gefixt.
In JS scheint das ähnlich zu funktionieren.
Die readme von js-cookie gibt einen Hinweis wie man das auch mit den Tool in JS umsetzen könnte.
Cookies.set('name', 'value', { secure: true })
Cookies.set('name', 'value', { sameSite: 'strict' })
Quelle: https://github.com/js-cookie/js-cookie/blob/master/README.md
Ich hab nach 3h hin und her testen die Lösung gefunden. Wichtig immer schöne überall die chaches löschen und auch die htaccess für js auf 0 setzen!
Tricky war, dass die js bei jedem Aufruf im debug-Modus das js vom Addon in assets kopiert wird. Nur - ziemlich verwirrend - leider nicht immer!
OK, so geht es: zu ändern ist die 'consent_manager_frontend.js' am besten im Addon/assets UND in assets/addons (!) Also an der Quelle der Kopie und am besten auch die Kopie.
Cache im Browser löschen (!) Sonst sieht man die Änderung nicht.
für den initialen Test-Cookie in Zeile 16:
von
Cookies.set('test', 'test', {path: '/', sameSite: 'Lax', secure: false});
ändern zu
Cookies.set('test', 'test', {path: '/', secure: true, sameSite: 'Strict'});
dann für das eigentliche Cookie in zeile 113/114
von
Cookies.set('consent_manager', JSON.stringify(cookieData), {expires: expires, path: '/', sameSite: 'Lax', secure: false});
ändern zu
Cookies.set('consent_manager', JSON.stringify(cookieData), {expires: expires, path: '/', secure: true, sameSite: 'Strict'});
Und schon wird es von Firefox richtig akzeptiert
Damit man nicht doch noch ein altes File galden hat, macht es auf jeden Fall Sinn nochmal zu prüfen, ob auch wirklich das neue File geladen wurde!
LG, Chris
Also wenn ich das versuche nachzustellen, wird im FF nur das "test" Cookie aus der js.cookie Library angemeckert. (Wenn man alle anderen Cookies im Browser löscht). Und das ja dann auch nur, bis das Cookie vom AddOn gespeichert wurde.
Denn wie Ingo schon sagte, die Cookies verwenden ja "sameSite: Lax" - da trifft die Hinweis-Meldung ja nicht zu.
Es lässt sich doch lösen, also warum nicht einfach machen? Zumal eine sichere Übertragung ohnehin per se besser ist. Ich hab schon eine Pull Request gestartet. Ist also keine Arbeit mehr.
Ich glaub der Fall ist inzwischen closed, doch vielleich hilft ja der Link nocheinmal zur objekktiven Aufklärung der Thematik: https://developer.mozilla.org/de/docs/Web/HTTP/Headers/Set-Cookie/SameSite.
Mozilla schreibt, dass ein Cookie mit "Lax" oder "None" künftig zwingend (!) "secure" gesetzt sein muss, oder ansonsten abgelehnt wird. Wenn es nicht "secure" gesetzt ist, muss es "Strict" sein.
Nein das steht da nicht.
- Nur ein Cookie mit "None" muss "secure" haben.
- Ohne "SameSite" wird es wie "Lax" behandelt (neuer default)
Und schon gar nicht steht da, dass "secure false" "strict" impliziert!
Ok, stimmt du hast recht ... hab ich tatsächlich falsch interpretiert, weil ich None mit Lax (welches None ja immer ersetzt) nach der Beschreibung fälschlicherweise gleichgesetzt habe.
Leider noch mal "nein" ;-) "None" wird nicht durch "Lax" ersetzt. "None" ist nach wie vor ein möglicher Wert. Nur wenn das "SameSite"-Attribut fehlt, wird neuerdings "Lax" angenommen (früher "None").