Modul zur Alters- und Identitätsprüfung für ausgewählte Versandarten via MRZ-Scan oder Dokumenten-Upload.
Caution
Wurde nur mit Prestashop 9.1.4 und PHP Version 8.3.31 getestet!
- Modulname:
internautenav - Unterstützte Dokumenttypen im Checkout:
- MRZ-Scan: CH ID (TD1, 3 Zeilen), CH Pass / EU Pass (TD3, 2 Zeilen)
- Dokumenten-Upload: Bild des Ausweises hochladen (JPG, JPEG, PNG – max. 10 MB, serverseitig re-encodiert)
- Pflichtprüfung nur für ausgewählte Versandarten (Konfiguration im Backoffice)
- Verifikation von Geburtsdatum, Name/Vorname gegen Lieferadresse, Alter >= 18 (MRZ)
- Verifikation wird gespeichert:
- Registrierte Kunden: In DB per
id_customer, warenkorbunabhängig – bei Folgebestellungen und nach CC-Abbruch/neuem Warenkorb nicht mehr erforderlich - Gäste: Session, gebunden an
carrier_reference(nicht mehr an Warenkorb-ID)
- Registrierte Kunden: In DB per
- Admin-Panel in der Bestellübersicht zeigt hochgeladene Dokumente mit Vorschau-Modal (Bildvorschau direkt im Browser)
- Admin kann Prüfung manuell als bestanden oder abgelehnt markieren – löscht Dokumente sofort DSGVO-konform
- Status-Badge oben auf der Bestellseite zeigt den aktuellen Prüfungsstatus auf einen Blick
- DSGVO-konformer Upload-Retention-Cleanup (90 Tage Aufbewahrung)
- Automatischer GitHub-Release bei Tag-Push (
vX.Y.Z) inkl. ZIP-Artefakt ausinternautenav/ - Datenschutzerklärung im Checkout verknüpfbar: konfigurierbare CMS-Seite mit Fallback auf Modul-Beispielseite
Der Workflow liegt unter .github/workflows/release-on-tag.yml.
Bei jedem Push eines Tags im Format v1.0.0 wird automatisch ein GitHub-Release erstellt.
- Trigger:
pushauf Tags nach Musterv*.*.* - Release-Titel:
Release vX.Y.Z - Release-Text:
- Commit-Liste zwischen letztem Tag und aktuellem Tag (inkl. Commit-Subject und Commit-Body)
- Zusätzlich automatisch generierte GitHub Release Notes
- Release-Asset: ZIP-Datei
internautenav-vX.Y.Z.zipaus dem Unterverzeichnisinternautenav/
git tag v1.0.0
git push origin v1.0.0- Ordner
internautenavin den PrestaShop-Ordnermodules/kopieren. - Modul im Backoffice installieren.
- Unter Modul-Konfiguration die Versandarten auswählen, die Altersverifikation erfordern.
- Optional: Datenschutzerklärung als CMS-Seite hinterlegen (siehe unten).
Im Checkout-Formular wird ein Link zur Datenschutzerklärung angezeigt. Dieser Link kann im Modul-Backend konfiguriert werden.
Im Backoffice unter Module → Internautenav AV → Konfiguration findest du das Dropdown „Datenschutzerklärung (CMS-Seite)":
| Auswahl | Verhalten |
|---|---|
| — Modul-Beispielseite verwenden — | Link zeigt auf die integrierte Beispielseite des Moduls |
| CMS-Seite #ID – Titel | Link zeigt direkt auf die gewählte PrestaShop CMS-Seite |
Unterhalb des Dropdowns wird ein Statusindikator eingeblendet:
| Farbe | Bedeutung |
|---|---|
| grün | CMS-Seite gültig und aktiv |
| rot | CMS-Seite nicht gefunden oder inaktiv – Fallback auf Beispielseite |
| grau | Keine CMS-Seite gewählt – Beispielseite aktiv |
Das Modul enthält eine integrierte Beispiel-Datenschutzseite unter:
modules/internautenav/views/templates/front/privacy.tpl
Sie ist über den Modul-Frontcontroller erreichbar:
https://shop.example.com/module/internautenav/privacy
Die Seite dient nur als Platzhalter für die Entwicklung. Für den Produktivbetrieb bitte eine eigene CMS-Seite im PrestaShop-Backend anlegen und dort im Modul verknüpfen.
- Im PrestaShop-Backend unter Design → Seiten eine neue CMS-Seite mit der finalen Datenschutzerklärung anlegen.
- Im Modul-Backend die neue CMS-Seite im Dropdown auswählen.
- Speichern – der Statusindikator wechselt auf grün, der Checkout-Link zeigt ab sofort auf die CMS-Seite.
Hochgeladene Dokumente werden nach 90 Tagen automatisch gelöscht. Der Cleanup-Mechanismus läuft auf zwei Wegen:
Das Modul registriert den Hook actionCronJob. Wenn das offizielle PS-Cronjobs-Modul installiert ist, wird der Cleanup täglich über dessen Cron-Aufruf ausgelöst.
Die genaue Cron-URL inkl. Token findest du im Backoffice unter:
Module → InternautenAV → Konfiguration → DSGVO Upload-Cleanup → Cron-URL
Eintragen solltest du sie unter dem Benutzer www-data:
sudo crontab -u www-data -eWebserver (wget/curl, täglich um 03:00 Uhr):
0 3 * * * wget -q "https://shop.example.com/modules/internautenav/cron.php?token=TOKEN" -O /dev/nullPHP-CLI:
0 3 * * * php /var/www/html/modules/internautenav/cron.php --token=TOKENDer Token basiert auf
_COOKIE_KEY_und ändert sich nicht, solange der PS-Sicherheitsschlüssel gleich bleibt.
Fallback: Solange kein Cron eingerichtet ist, läuft der Cleanup gedrosselt (max. alle 6 Stunden) beim Seitenaufruf durch Kunden mit.
Unter Modul-Konfiguration → DSGVO Upload-Cleanup stehen zwei Buttons zur Verfügung:
- Cleanup jetzt ausführen – löscht alle Uploads älter als 90 Tage
- Alle Dateien ohne Altersprüfung löschen – löscht alle Uploads, die keiner abgeschlossenen Bestellung zugeordnet sind
Oben auf jeder Bestellseite im Backoffice wird automatisch ein farbiges Status-Badge eingeblendet:
| Badge | Farbe | Wann |
|---|---|---|
| ✓ Prüfung automatisch bestanden | grün | MRZ oder Upload wurde automatisch validiert |
| ✓ Prüfung manuell bestanden | grün | Admin hat „Prüfung bestanden" geklickt |
| ⚠ Prüfung manuell erledigen | gelb | Dokument hochgeladen, aber noch keine Admin-Entscheidung |
| ✗ Prüfung abgelehnt | rot | Admin hat „Prüfung abgelehnt" geklickt |
| ? Keine Prüfung vorhanden | grau | Versandart ist pflichtig, aber kein Eintrag gefunden |
| 🚚 Prüfung bei Übergabe | blau | Verwendete Versandart erfordert keine Online-Prüfung |
In der Backoffice-Bestellansicht erscheint unterhalb der Dokumenten-Liste ein Entscheidungsbereich mit zwei Buttons:
- ✓ Prüfung bestanden – loggt die Entscheidung, trägt den Kunden als verifiziert in
customer_verificationein (nur bei registrierten Kunden, sodass bei Folgebestellungen keine erneute Prüfung erforderlich ist) und löscht alle Dokumente sofort DSGVO-konform - ✗ Prüfung abgelehnt – loggt die Ablehnung, löscht alle Dokumente sofort DSGVO-konform (kein Eintrag in
customer_verification)
Beide Aktionen sind token-gesichert und erfordern eine Bestätigung via Browser-Dialog.
Die Präsentation ist vollständig von der Business-Logik getrennt. Alle Hooks rendern ihre Ausgabe über dedizierte Smarty-Templates:
| Template | Hook | Zweck |
|---|---|---|
payment_gate.tpl |
displayPaymentTop |
Checkout-Formular mit MRZ/Upload-Modal |
customer_account.tpl / customer_account_fontawesome.tpl |
displayCustomerAccount |
Link zum Prüfungsprotokoll (Material Icons / Font Awesome) |
admin_customers_protocol.tpl |
displayAdminCustomers |
Kundenverwaltung: Status-Badge + Prüfungsprotokoll |
order_verification_log_panel.tpl |
hookDisplayAdminOrderTop |
Bestelldetail: Verifikations-Log-Tabelle |
admin_order_main_bottom.tpl |
hookDisplayAdminOrderMainBottom |
Bestelldetail: Dokumenten-Tabelle + Preview-Modal |
backoffice_config.tpl |
getContent() |
Backoffice: Träger- und CMS-Seiten-Auswahl |
backoffice_cleanup.tpl |
getContent() |
Backoffice: DSGVO Upload-Cleanup Panel |
order_status_badge.tpl |
renderOrderStatusBadge() |
Status-Badge-Rendering (Web + Admin) |
order_status_badge_pdf.tpl |
renderOrderStatusBadgeForPdf() |
Status-Badge im PDF (Rechnung/Lieferschein) |
- CSS:
views/css/checkout.css,views/css/admin_order_main_bottom.css - JavaScript:
views/js/checkout.js,views/js/admin_order_main_bottom.js
One-time Loading Flags verhindern doppelte Asset-Einbindung:
INTERNAUTENAV_CHECKOUT_CSS_LOADED/INTERNAUTENAV_CHECKOUT_JS_LOADEDINTERNAUTENAV_ADMIN_ORDER_CSS_LOADED/INTERNAUTENAV_ADMIN_ORDER_JS_LOADED
Das Modul erstellt/verwaltet 3 Tabellen:
| Tabelle | Zweck |
|---|---|
internautenav_customer_verification |
Persistierte Verifikationen (ID-Kunden) – gibt es ab 18 Jahren |
internautenav_verification_log |
Log aller Verifikationsversuche (MRZ/Upload/Manuell) |
internautenav_uploaded_documents |
Hochgeladene Dokumente (max. 90 Tage, dann DSGVO-Cleanup) |
- Refaktorierung: Alle inline HTML/JS/CSS aus PHP-Hooks in Smarty-Templates ausgelagert (Separation of Concerns)
- Backoffice-Liste Gespeicherte Verifikationen auf PrestaShop-
HelperListmit Filter, Sortierung und Pagination umgestellt. - Backoffice-Liste Verifikations-Log ebenfalls auf
HelperListumgestellt: Filter nach Timestamp-Bereich, Referenz, Kundennamen, Dokumenttyp, Ergebnis und Nachricht möglich. - Filterauslese robust gemacht (unterstützt unterschiedliche Request-Key-Varianten der
HelperList, inkl. Alias-Felder). - Reset-Button beider Listen korrigiert: führt jetzt auf eine saubere Modul-URL ohne Filterparameter zurück.
- Datumsfilter
verified_atundchecked_atkorrigiert:Datum abfiltert per>= YYYY-MM-DD 00:00:00Datum bisfiltert per<= YYYY-MM-DD 23:59:59- damit werden bei
Datum abauch neuere Einträge korrekt angezeigt.
-
Konfiguration prüfen:
- Im Backoffice unter Module > Internautenav AV
- Mindestens eine Versandart auswählen und speichern
-
Debug-Information:
- Aufruf:
http://dein-shop.de/modules/internautenav/debug.php - Zeigt Modul-Status, Konfiguration und Carrier
- Aufruf:
-
Checkout-Anforderungen:
- Versandart muss in der Konfiguration ausgewählt sein
- Funktioniert für: registrierte Kunden UND Gäste
- Registrierte Kunden: Verifikation wird nur einmalig pro Kunde geprüft
- Gäste: Verifikation wird pro Gast-Bestellung geprüft (Session-basiert)
-
Datenbankprüfung:
- Tabellen
internautenav_customer_verification,internautenav_verification_logundinternautenav_uploaded_documentsmüssen existieren - Falls nicht: Modul neu installieren
- Tabellen
- Kompatibel ab PrestaShop
1.7.8.0 - Registrierte Hooks:
actionFrontControllerSetMedia– JS/CSS ladendisplayPaymentTop– Modal-Anzeige im CheckoutactionCarrierProcess/actionValidateStepComplete– MRZ/Upload-PrüfungactionValidateOrder– Upload-Datei der Bestellung zuordnendisplayAdminOrderMainBottom/displayAdminOrder– Upload-Panel im BackofficedisplayAdminOrderTop– Status-Badge oben auf der BestellseiteactionCronJob– DSGVO-Cleanup via PS-Cronjobs-Modul
- Dateispeicherung:
modules/internautenav/uploads/(abgeschlossen) bzw.uploads/pending/(temporär bis Bestellabschluss) - Download-Links sind token-gesichert (kein Employee-Session-Zugriff erforderlich)
Damit die Container bei jedem neuen Modul nicht jedesmal neu erstellt werden müssen, versuchen wir es mit Symlinks.
Voraussetzungen: im Compose hat es unter volumes einen Eintrag - /home/youruser/internauten:/internauten
-
Bash ins WSL2 und holen des Repos aus dem Fork:
cd ~/internauten git clone https://github.com/yourgithub/InternautenAV.git
-
Owner, Group und Rights setzen:
sudo chmod -R g+s . sudo chgrp -R www-data . sudo setfacl -R -d -m g:www-data:rwx . sudo setfacl -R -m g:www-data:rwx . oder cd ~/internauten/InternautenAV/internautenav/controllers sudo chown -R www-data:www-data .
-
Bash in den Container und Symlink erstellen:
ln -s /internauten/InternautenAV/internautenav /var/www/html/modules/internautenav chown -h www-data:www-data /var/www/html/modules/internautenav
-
Modul im PrestaShop-Backoffice unter Modul-Manager installieren und konfigurieren.
Falls der Cleanup als System-Cron eingerichtet wird, helfen die folgenden Kurzerklaerungen:
sudofuehrt den Befehl mit erweiterten Rechten auscrontabbearbeitet die Cronjobs eines Benutzers-u www-datameint: bearbeite den Cron des Benutzerswww-data-eoeffnet den Cronjob-Editor
Der Benutzer www-data ist auf Debian/Ubuntu-Systemen ueblicherweise der Webserver-Benutzer. Der Cronjob laeuft damit mit denselben Dateirechten wie PrestaShop.
Das ist der Zeitplan im Cron-Format und bedeutet: taeglich um 03:00 Uhr.
Die fuenf Felder von links nach rechts sind:
┌ Minute
│ ┌ Stunde
│ │ ┌ Tag im Monat
│ │ │ ┌ Monat
│ │ │ │ ┌ Wochentag
│ │ │ │ │
0 3 * * *
0bei Minute: zur Minute 03bei Stunde: um 3 Uhr nachts*bei Tag im Monat: an jedem Tag des Monats*bei Monat: in jedem Monat*bei Wochentag: an jedem Wochentag
Das ist Shell-Syntax fuer die Umleitung von Fehlerausgaben:
1iststdout, also normale Ausgabe2iststderr, also Fehlermeldungen>> logfilehaengt die normale Ausgabe an eine Datei an2>&1leitet die Fehlerausgabe auf dasselbe Ziel wie die normale Ausgabe um
Beispiel:
0 3 * * * PS_ROOT_DIR=/path/to/prestashop /usr/bin/php /path/to/prestashop/modules/internautenav/cron.php --token=DEIN_TOKEN >> /path/to/prestashop/var/logs/internautenav-cron.log 2>&1Damit landen sowohl normale Ausgaben als auch Fehlermeldungen in derselben Logdatei.
Wenn die Cron-Ausgabe in eine Datei geschrieben wird, kann Ubuntu sie mit logrotate automatisch bereinigen. Eine passende Vorlage fuer diesen Server liegt als Beispiel unter:
deploy/logrotate/internautenav-cron
Auf dem Server aktivierst du sie einmalig mit dem mitgelieferten Script:
sudo bash deploy/setup-logrotate.shDas Script legt /etc/logrotate.d/internautenav-cron an, setzt die Rechte und fuehrt direkt einen Dry-Run aus, um die Konfiguration zu pruefen. Die Regel rotiert internautenav-cron.log und prestashop-search-reindex.log monatlich, behaelt 12 komprimierte Staende und rotiert bei Bedarf frueher, falls eine Datei groesser als 5 MB wird.
PrestaShop erzeugt oft datierte Tages-Logs (z.B. mit YYYY-MM-DD im Namen). Diese sollten nicht erneut mit logrotate rotiert werden. Stattdessen nutzt das Setup-Script eine Hybrid-Strategie:
- Nicht-datierte Logs: Rotation ueber
logrotate(monatlich, komprimiert) - Datierte Logs: taeglicher Cleanup per
findund Loeschung nach 30 Tagen
Installierte Bestandteile:
/etc/logrotate.d/internautenav-cron
/usr/local/sbin/prestashop-dated-logs-cleanup
/etc/cron.daily/prestashop-log-cleanup
Vorlagen im Repository:
deploy/logrotate/internautenav-cron
deploy/cleanup/prestashop-dated-logs-cleanup.sh
deploy/cleanup/prestashop-log-cleanup.cron.daily
sudo logrotate -d /etc/logrotate.conf
sudo logrotate -d /etc/logrotate.d/internautenav-cron
sudo /usr/local/sbin/prestashop-dated-logs-cleanup /path/to/prestashop/var/logs 30This project is licensed under the MIT License. See details LICENSE.
Copyright (c) 2026 die.internauten.ch GmbH