Friederich Loheide
61810eb050
Für Empfang, Lobby oder Tagungsraum lässt sich je Site eine öffentliche Seite anlegen (kiosk.php), die auf einem Bildschirm oder Tablet läuft: ein großer Knopf, ein Klick, ein Zugangscode mit QR-Code. Nach einer einstellbaren Anzeigedauer springt der Bildschirm zurück, damit der nächste Gast nicht den Code seines Vorgängers sieht. Verwaltung unter Administration → Display-Seiten: - Site und optionales Voucher-Profil (bestimmt Laufzeit, Geräte, QoS) - eigene Überschrift und Text für den Bildschirm - Codes pro Tag, Wartezeit zwischen zwei Codes, Anzeigedauer - geheimer Link zum Kopieren, als QR-Code anzeigbar und jederzeit erneuerbar (der alte Link gilt dann sofort nicht mehr) Absicherung: der Link ist der Zugang, deshalb Tageslimit und Wartezeit je Display, CSRF-Token am Formular, `noindex` im Kopf und ein Eintrag im Audit-Log für jeden ausgegebenen Code. Webhooks werden für Kiosk-Codes bewusst nicht ausgelöst – ein Empfangsdisplay würde den Kanal fluten. Technik: - neue Tabelle `kiosks`, `vouchers.kiosk_id` hält die Herkunft fest (Migration 0005, database.sql nachgezogen) - includes/Kiosk.php kapselt Token, Limits und Profil-Auflösung - includes/VoucherService.php bündelt die Voucher-Erstellung, die vorher in index.php lag und für den Kiosk ein zweites Mal nötig gewesen wäre - Startbildschirm zeigt zusätzlich einen QR auf sich selbst, damit Gäste die Seite am eigenen Handy öffnen können Tests: 9 neue Fälle für Token-Prüfung, Wartezeit, Tageslimit und Profil-Auflösung (38 Tests gesamt), PHPStan deckt Kiosk.php mit ab. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| migrations | ||
| storage | ||
| templates | ||
| AuditLogger.php | ||
| bootstrap.php | ||
| MigrationRunner.php | ||
| README.md | ||
| routes.php | ||
| UpdateController.php | ||
| UpdateManager.php | ||
| UpdaterFactory.php | ||
Updater (OpenVoucherTool)
Auto-Update-System nach dem OpenNIT-Modell: zieht Quellcode + DB-Migrationen aus einem zentralen Repository über einen HTTP-Update-Proxy nach.
[diese App] ←HTTPS→ [Update-Proxy] ←pull→ [Git-Repo]
- Versions-Identität: 40-stelliger Git-Commit-SHA in
updater/storage/.version - Channels:
stable→https://update.loheide.eu/openvouchertool,development→https://update.loheide.eu/openvouchertool-development - User-Agent:
OpenVoucherTool-Updater/1.0 - DB-Treiber: MySQL/MariaDB (Migrations-Tracking-Tabelle
_updater_migrations)
Aufruf
Admin-Oberfläche: /admin/update.php (nur für angemeldete Admins).
| Endpoint | Methode | Zweck |
|---|---|---|
admin/update.php |
GET | Admin-UI |
admin/update.php?action=check |
GET | Update-Prüfung (JSON) |
admin/update.php?action=progress |
GET | Fortschritt (JSON) |
admin/update.php?action=migrations |
GET | Migrations-Status (JSON) |
admin/update.php action=install |
POST | Update installieren (+csrf_token) |
admin/update.php action=set_channel |
POST | Channel wählen (+csrf_token) |
Optional: In der Admin-Navigation (
admin/index.php) einen Link zuupdate.phpergänzen, damit die Seite auffindbar ist. Das ist bewusst nicht automatisch geschehen (Isolations-Prinzip – siehe unten).
Isolation
Der Updater liegt vollständig in updater/ (eigener Namespace Updater\) plus
zwei dünne, klar markierte Anknüpfungen:
- Front-Controller-Hook in
index.php(Maintenance-Check, markiert mit// Updater maintenance hook). - Entry-Shim
admin/update.php(lädt nur Basis + Bootstrap, delegiert an den Controller).
Eigene Settings (updater/storage/updater-settings.json), eigener Autoloader
(updater/bootstrap.php), eigener AuditLogger (schreibt in die vorhandene
audit_log-Tabelle), eigenes Migrations-System (updater/migrations/ +
Tabelle _updater_migrations). Es werden keine Projekt-Klassen erweitert –
\Database und \Auth werden nur per Injection genutzt.
Geschützte Pfade (werden bei Updates nie überschrieben)
config.php, .htaccess, .env*, .git/, .gitignore, public/uploads/,
vendor/, composer.lock, updater/storage/.
Rückbau (restlos entfernen)
- In
index.phpden Block „Updater maintenance hook" (die Zeilen 2–8, beginnend mit$maintenanceFile = …bis zum schließenden}) entfernen. rm -r updater/rm admin/update.php- (optional) In der Datenbank:
DROP TABLE _updater_migrations; - (optional, falls vorhanden) Laufzeitdateien sind bereits in
updater/und damit mit Schritt 2 weg. Nichts liegt außerhalb.
Danach ist keine Spur des Updaters mehr im Bestandscode – der Beweis für die Isolation.
Smoke-Test
# 1) Syntax aller Updater-Dateien
php -l updater/UpdateManager.php
php -l updater/MigrationRunner.php
php -l updater/UpdateController.php
php -l updater/UpdaterFactory.php
php -l updater/AuditLogger.php
# 2) Admin-Seite aufrufen (eingeloggt als Admin):
# https://<host>/admin/update.php
# -> "Auf Updates prüfen" klicken. Erwartung: Proxy-Antwort oder klare
# Fehlermeldung (wenn Proxy/Channel nicht erreichbar).
# 3) Maintenance-Mode manuell testen:
touch updater/storage/.maintenance # index.php zeigt jetzt 503-Wartungsseite
rm updater/storage/.maintenance # wieder normal
Hinweis: Ein vollständiger Installations-Durchlauf (
action=install) setzt einen erreichbaren Update-Proxy unter den oben genannten URLs voraus.