TLS-Gate v3.10.1: Admin-Dienste nicht als Angebot im Dashboard normaler User

Von: Branko → OZMAI
Stand: 7. Oktober 2026
Typ: EXTERNAL_SOURCE (Inbox-Regel §3 — keine automatische Geltung, kein Brain-Status)
Charakter: STAND + NACHTRAG (kurz). Setzt 2026-10-07_TLS-GATE-V3-10-0-EXPORT-BUTTON-PRODUKTLISTE-UND-IMPORT-NACHTRAG_BRANKO.md fort. Ersetzt eine Aussage der Datei zu v3.8.0 (und deren Fortsetzung zu v3.9.0): Dort steht, die Produktkacheln zeigten „je aktive Freigabe der eigenen Gruppe“. Seit v3.10.1 gilt das nicht mehr für Produkte der Achse access (siehe §1). Alles andere gilt unverändert.
Quelle: Repo TLS-Gate-Mock-Pipeline (git.crumbforest.org). Tag v3.10.1 = Commit 43b7ab2 (Vorgänger v3.10.0 = 943a5e6).
Belege: tests/test_bookings.sh (78), docker_vm/tests/run.sh (86), test_dashboard_tiles.sh (29).

Legende: ✅ real/gebaut · 🧪 gebaut, getestet, nicht live · 🛠 spezifiziert · ⬜ OPEN · ❓ UNKNOWN

Keine Zugangsdaten, keine Kunden-Domains, keine Reseller-IDs.

1. Befund und Fix

  • ✅ Befund: Beim Durchsehen der Dashboard-Seiten der Klicktest-Instanz zeigte der Abschnitt „Produkte und Freigaben“ für user01 (Rolle user) das Angebot Postgres, obwohl ein User es nicht buchen kann (nur_admin). Ebenso betroffen: VPN und Gitea, also alle Produkte, deren Kategorien ausschließlich der Achse access (Kategorie admin) angehören. Das Modell der Buchungen (v3.9.0) lehnte die Buchung korrekt ab; nur die Anzeige war zu weit.
  • 🧪 Fix: Tiles::products blendet Produkte aus, deren Kategorien alle zur Achse access gehören, außer für Konten mit Rolle admin. Produkte ohne Kategorie (Altbestand, Demo) bleiben für alle sichtbar. group_admin zählt hier wie user (er kann access-Kategorien nach den Buchungsregeln ebenfalls nicht buchen).
  • 🧪 Test (test_bookings.sh): Admin sieht Postgres, User nicht; Storage und SSL sieht der User; ohne den Filter ist der Test rot.

2. Wie es auffiel

Branko schickte das gerenderte HTML zweier Dashboard-Seiten (Admin von ozm03; ein group_admin der Demo-Gruppe) mit dem Urteil „sieht gut aus“. Der Fehler stand nicht in diesen Seiten, sondern wurde beim Gegenlesen mit der Rolle user gefunden und gegen die MariaDB der VM nachgerechnet (Modell, nicht gerenderte Seite). Das ist ein Fund aus dem Gegenprüfen mit einer anderen Rolle, nicht aus dem Test der gezeigten Rolle.

3. Einordnung als Prüffall (Branko, nicht OZMAI-Geltung)

Eine Anzeige, die ein Angebot zeigt, das die Fachregel ablehnt, ist eine Aussage über Möglichkeiten, die nicht besteht. Dass die Regel an der richtigen Stelle (Buchung) hielt, ersetzt nicht, dass die Darstellung dieselbe Grenze zieht. Die Sicht-Regeln (access nur für admin) stehen jetzt an beiden Stellen und werden in einem Test gegeneinander gehalten.

4. Offene Punkte (unverändert aus der v3.10.0-Datei)

  • ⬜ Den Export-Button auf der echten Instanz drücken; Feldnamen und SSL-4-Frage prüfen.
  • ⬜ Domains, domain_orders, Import der Systemakten, SQL-Statement gegen den parallelen Bestand (Schema liegt nicht vor).
  • ⬜ Bereitschaft, Monitor, Alarm; Kette als Sperre; Weiterleitung nach dem Login auf das Dashboard.
  • ❓ Browser-Optik des Dashboards nicht geprüft; MySQL-8-Pfad der Migrationen ungetestet.