ALTCHA Spam-Schutz: Datenschutz
Datenschutz beim ALTCHA Spam-Schutz für OXID 7: welche Daten verarbeitet und gespeichert werden, die externe Anfrage an cdn.jsdelivr.net, Cookies, Aufbewahrung und die manuelle Bereinigung der Tabellen.
ALTCHA Spam-Schutz: Datenschutz
Live Demo: Teste dieses und weitere Plugins live — ohne Installation, ohne Risiko: demo.markus-michalski.net
Diese Seite beschreibt, was das Modul im Code tatsächlich verarbeitet. Sie ersetzt keine rechtliche Bewertung für deinen Shop.
Das Widget-Skript wird vom Browser der Besucher von
cdn.jsdelivr.netgeladen, einem Server eines Drittanbieters. Dabei erhält der Anbieter mindestens die IP-Adresse und den User-Agent des Besuchers. Das Modul ist deshalb nicht frei von Anfragen an Dritte.
Externe Anfrage: Widget-Skript
Das Modul bindet das ALTCHA-Widget über das Template layout/base.html.twig (Block base_js) so ein:
<script type="module" src="https://cdn.jsdelivr.net/npm/altcha@latest/dist/altcha.min.js"></script>
- Der Abruf erfolgt bei jedem Seitenaufruf im Apex-Theme, nicht nur auf Seiten mit Formular, solange "Spam-Schutz aktivieren" und "ALTCHA aktivieren" eingeschaltet sind.
- Die Datei wird nicht vom eigenen Server ausgeliefert, sondern vom CDN. Der Browser überträgt dabei seine IP-Adresse und seinen User-Agent an den CDN-Betreiber, je nach Browser auch den Referrer.
- Die Version ist nicht festgelegt (
altcha@latest). Welchen Code der Browser ausführt, bestimmt also der CDN-Inhalt zum Zeitpunkt des Abrufs, nicht dieses Modul. - Der serverseitige Code des Moduls (PHP) sendet selbst keine Anfragen an andere Server.
- Das Modul enthält keine Anbindung an ein Consent-Tool. Ob für den Abruf eine Einwilligung oder ein anderer Rechtsgrund nötig ist, bewertest du für deinen Shop selbst.
Wenn du das Skript nicht vom CDN laden möchtest, überschreibst du den Block base_js in deinem eigenen Theme oder Modul und lieferst die Datei selbst aus. Das Modul prüft nicht, woher das Skript stammt.
Welche Daten das Modul verarbeitet
| Daten | Wann | Was damit geschieht |
|---|---|---|
| IP-Adresse des Besuchers | Beim Abruf einer Challenge und beim Absenden eines geschützten Formulars | Wird ausgelesen und nur als HMAC-SHA256-Hash gespeichert, die Klartext-Adresse wird nicht abgelegt |
Aktion (contact_form, newsletter_subscribe, registration, challenge) und Zeitstempel |
Zusammen mit dem Hash der IP-Adresse | Eine Zeile pro Anfrage in mmd_altcha_rate_limit_log |
| Hash der gelösten Challenge | Nach erfolgreicher Prüfung der Lösung | SHA-256 der Challenge plus Ablaufzeit in mmd_altcha_used_challenges, ohne Personenbezug |
| Formularinhalte (Vorname, Nachname, E-Mail, Straße, Ort) | Bei der Inhaltsvalidierung | Werden nur im Arbeitsspeicher geprüft und vom Modul nicht gespeichert |
| Wert des Honeypot-Felds | Beim Absenden | Wird nur auf "leer oder nicht leer" geprüft und nicht gespeichert |
Der Hash der IP-Adresse wird aus dem Text ip: plus der Adresse mit dem HMAC-Geheimschlüssel des Moduls gebildet. Ohne diesen Schlüssel lässt sich die Adresse nicht aus dem Hash zurückrechnen. Je nach Bewertung gilt ein solcher Wert dennoch als pseudonymisierte personenbezogene Information, und dein Verarbeitungsverzeichnis sollte ihn berücksichtigen.
Client-Adresse hinter Proxy oder CDN
Das Modul liest die Adresse so aus: Ist der Header X-Forwarded-For vorhanden, gilt dessen erster Eintrag, sonst REMOTE_ADDR. Es gibt keine Liste vertrauenswürdiger Proxys.
Ein Besucher kann
X-Forwarded-Forselbst setzen, wenn davor kein Proxy steht, der den Header überschreibt. Damit lässt sich das Rate Limiting umgehen. Hinter einem Reverse-Proxy ohneX-Forwarded-Forteilen sich dagegen alle Besucher einen Zähler.
Cookies
Der Code des Moduls setzt keine Cookies und liest keine. Das Modul speichert auch sonst nichts im Browser. Davon unabhängig setzt OXID selbst eigene Cookies, zum Beispiel für die Session.
Aufbewahrung und Bereinigung
Das Modul löscht seine Daten nicht automatisch. Die Methoden zum Aufräumen (RateLimitService::cleanup(), RateLimitRepository::deleteOlderThan(), UsedChallengeRepository::deleteExpired()) existieren, werden aber von keinem Cronjob und keinem Hook aufgerufen. Beide Tabellen wachsen deshalb ohne Obergrenze.
Räume sie regelmäßig selbst auf, zum Beispiel per Cronjob mit diesen Statements:
DELETE FROM mmd_altcha_rate_limit_log WHERE requested_at < NOW() - INTERVAL 1 DAY;
DELETE FROM mmd_altcha_used_challenges WHERE expires_at < NOW();
Das Intervall im ersten Statement muss mindestens so lang sein wie dein größtes eingestelltes Zeitfenster (Standard: 60 Minuten), sonst fehlen dem Rate Limiting Einträge. Abgelaufene Challenges werden ohnehin abgelehnt, ihre Zeilen in mmd_altcha_used_challenges kannst du daher gefahrlos löschen.
Bei Deaktivierung und Deinstallation des Moduls bleiben beide Tabellen bestehen. Wenn du sie nicht mehr brauchst, löschst du sie manuell.