bugfix Subdomain-Probleme und WICHTIGER HINWEIS juristischer Art

[oioix]

Verwendete Versionen
REDAXO: 5.16.1
Browser: Firefox
AddOns: consent manager 4.2.0

Description / Beschreibung
Ich habe eine Seite auf einer TLD und eine auf einer Subdomain der gleichen TLD. Es sind zwei separate, aber ansonsten identisch konfigurierte REDAXO-Installationen.
Ich habe den Consent Manager kürzlich von einer ganz alten Version auf die aktuellste Version 4.2.0 umgestellt.
Die alte Version lief bei mir immer mit der Cookie Einstellung samesite strict und secure true (hatte ich im frontend js angepasst). Die Einträge in der DB Tabelle rex_consent_manager_consent_log Spalte Domain waren immer einwandfrei. D.h. die Subdomain wurde dort korrekt benannt.

Nach der Umstellung traten folgende Probleme auf

1. Bei beiden Installationen ging nach einiger Zeit immer wieder die Consent Manager Box auf, wie es schon in Issue Bei Subdomains geht der Cookiemanager immer wieder auf #299 beschrieben wurde. Und das obwohl das Ablaufdatum des Cookies völlig korrekt auf 1 Jahr festgelegt ist.

2. Subdomain-Installation: In der Tabelle rex_consent_manager_consent_log wurde nach dem Update nur noch die TLD nicht aber die Subdomain (Muster: SUB.TLD) aufgeführt. Also das in Consent-Log zeigt falsche Domain an #309 bereits beschriebene Problem.

3. Beide Installationen: Im Cookie constent_manager wurde bei beiden Installationen die Domain als Wildcard angegeben. D.h. statt TLD bzw. SUB.TLD stand dort .TLD
   Der vorangestellte Punkt soll bekanntlich dafür sorgen, dass das Cookie sowohl für die Hauptdomain, als auch für die Subdomain gilt.
   Das war in der alten Version des Consent Managers nicht so. In der alten Version wurde bei der Subdomain SUB.TLD angezeigt und bei der Hauptdomain TLD.

WICHTIG: JURISTISCHES DSGVO-PROBLEM
Ich sag es mal so: auch wenn du noch so attraktiv bist ... wenn eine Frau ein Kind von deinem Sohn will, heißt das noch lange nicht, dass sie auch eines von dir will.

Die Zustimmung in der Consent Manager Box kann dementsprechend nur für die gerade besuchte Website gelten. Wenn ich also die TLD besuche und dort Google Analytics zustimme, heißt das noch lange nicht, dass dich als Besucher, wenn ich später die Website der SUB.TLD besuchen sollte, mein Einverständnis dazu erklärt habe, dass auch dort Google Analytics geladen werden darf. Diese Cookie-Zustimmungen müssen also unbedingt jeweils separat erklärt werden. Hier gibt es also ein glasklares DSGVO-Problem.
Problem Nr. 3 muss also unbedingt gelöst werden.

BUG-FIX
Glücklicherweise lässt sich das alles leicht wie folgt lösen:

STEP 1:
a) in lib/consent_manager_util.php -> Funktion hostname() (ca. Zeile 57) von
return $dominfo['domain'];
zu
if($dominfo['subdomain']) return $dominfo['subdomain'].'.'.$dominfo['domain']; else return $dominfo['domain'];

Diese Änderung sorgt erstens dafür, dass Problem Nr. 1 gefixt wird, also die Subdomain wieder korrekt in die DB eingetragen wird ...
... und zweitens, dass die Subdomain auch im Cookie wieder korrekt ausgegeben wird (bis auf den noch immer vorangestellten Punkt).

STEP 2:
Nachdem STEP 1 durchgeführt ist, stimmt die Domain im Cookie noch nicht ganz, denn der vorangestellte Punkt ist noch vorhanden.
Um das zu fixen ganz am Anfang der beiden Dateien consent_manager_frontend.js und consent_manager_frontend.min.js muss der Eintrag
const cmCookieAPI = Cookies.withAttributes({ expires: cmCookieExpires, path: '/', domain: consent_manager_parameters.domain, sameSite: 'Lax', secure: false });
deshalb mindestens geändert werden zu:
const cmCookieAPI = Cookies.withAttributes({ expires: cmCookieExpires, path: '/', sameSite: 'Lax', secure: false });

Mit der vorgenannten Änderung werden sowohl die Subdomain in der Subdomain-Installation, als auch die Hauptdomain in der Hauptdomain-Installation im jeweiligen Cookie korrekt ohne den vorangestellten Punkt im Cookie ausgegeben.

Ich gehe davon aus, dass das Problem Nr. 1 dadurch verursacht wird, dass wenn man auf den beiden Seiten surft, die beiden verschiedenen Seiten im Cookie als Domain den Eintrag .TLD haben, der Browser (zumindest mein Firefox Mac) genau hier ins Straucheln kommt, wenn man die Seite wechselt und dort weiter surft und dann wieder wechselt und surft. Das ist also dann nicht nur ein juristisches Problem, sondern auch ein technisches.

MEINE EMPFEHLUNG zu STEP 2:
Wir haben wahrscheinlich alle aus Datenschutzgründen inzwischen eine https:// Seite.
Das consent_manager-Cookie gilt ja tatsächlich nur für die jeweilige Seite. Das wäre selbst dann so, wenn die Seite woanders in einem iFrame geladen werden würde.
Deshalb würde ich grundsätzlich immer sameSite: 'Strict', secure: true verwenden (mache ich schon ewig ohne Probleme).
Dann also würde der Eintrag stattdessen lauten:
const cmCookieAPI = Cookies.withAttributes({ expires: cmCookieExpires, path: '/', sameSite: 'Strict', secure: true });

FEATURE VORSCHLAG ZUM THEMA STEP 2:
Es wäre toll, wenn die sameSite- und secure-Einstellung im Addon als ein im Backend vom Betreiber einstellbares Feature aufgenommen werden würde oder wenn alternativ hierzu automatisch erkannt würde, ob es eine https-Seite ist und diesfalls dann die sichere Einstellung nimmt.

Über die consent_manager_parameters (consent_manager_frontend.php Zeile 145) müsste es ja möglich sein, die entsprechende steuernde Einstellungen an das consent_manager_frontend.js zu übergeben.

[aeberhard]

Hi Chris @oioix ,

Danke für deine ausführlichen Issues und auch gleich die Lösungen.
Ich werde versuchen dass in einem nächsten Release (4.4 voraussichtlich) zu übernehmen.

Gruß
Andreas

[oioix]

Hallo Andreas,
super, danke!

VG, Chris