Unifi-Voucher-Tool/tools
Friederich Loheide 61810eb050 Display-Seiten: Gäste holen sich den Zugang selbst
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>
2026-09-23 16:51:50 +00:00
..
demo Display-Seiten: Gäste holen sich den Zugang selbst 2026-09-23 16:51:50 +00:00
runner Einrichtung für einen Forgejo-Actions-Runner beilegen 2026-09-23 15:06:19 +00:00
.htaccess Sicherheits-Header, Werkzeuge und Dokumentation 2026-09-23 06:49:14 +00:00
README.md Einrichtung für einen Forgejo-Actions-Runner beilegen 2026-09-23 15:06:19 +00:00
screenshots.py Display-Seiten: Gäste holen sich den Zugang selbst 2026-09-23 16:51:50 +00:00

Werkzeuge

Demo-Instanz (tools/demo/build.py)

Baut aus dem Projekt eine lauffähige Kopie ohne Datenbank: Database und Auth werden durch Stubs mit festen Beispieldaten ersetzt (tools/demo/overlay/). Das Original bleibt unverändert.

python3 tools/demo/build.py /tmp/uvt-demo
php -S 127.0.0.1:8123 -t /tmp/uvt-demo

Nützlich für:

  • Screenshots für die Dokumentation immer mit denselben Daten
  • Smoke-Test jede Seite einmal rendern, ohne MySQL aufzusetzen

Demo-spezifische Zustände werden über Query-Parameter erreicht:

Parameter Wirkung
?demo=result / ?demo=bulk Voucher-Ergebnis bzw. Bulk-Liste auf index.php
?demo=new frisch erzeugter Schlüssel auf admin/api_keys.php
?anon=1 nicht angemeldet (für die Login-Seite)
?theme=dark erzwingt den Dark Mode
?brand=custom / ?brand=nopanel Beispiel-Branding der Login-Seite

Screenshots (tools/screenshots.py)

Rendert die Bilder aus docs/screenshots/ neu. Voraussetzung ist ein headless Chromium; der Pfad kommt aus $CHROME_BIN oder wird in den üblichen Verzeichnissen gesucht.

python3 tools/demo/build.py /tmp/uvt-demo
php -S 127.0.0.1:8123 -t /tmp/uvt-demo &
CHROME_BIN=/usr/bin/chromium python3 tools/screenshots.py

Actions-Runner (tools/runner/)

Compose-Datei und Anleitung, um einen Forgejo-Actions-Runner einzurichten. Ohne Runner bleiben ci.yml und release.yml in der Warteschlange stehen. Details: tools/runner/README.md.

Die Skripte sind Hilfsmittel für die Entwicklung im Betrieb werden sie nicht benötigt und sind per .htaccess nicht über HTTP erreichbar.