Der verborgene Zugang stand im Quelltext UND in den Daten

Angefangen hat es bei einem roten Lauf aus dem Nachtlauf, nicht bei
einer Suche: `pruef-modi-wortleck` meldete drei Fundstellen des
Rollennamens in Dateien, die JEDER ausgeliefert bekommt.

  assets/css/reaktion.css   .beitrag__rolle[data-rolle="modi"]
  assets/js/meldung.js      "... und die Modis."
  assets/js/reaktion.js     modi: ['Modi', 'modi']

BEIM NACHSEHEN, WIE DER NAME DORTHIN KAM, kam das Groessere heraus:
`/workspace/api/reaktion/chat` waehlte `rolle` aus der Tabelle und gab
sie unveraendert heraus. Eine Chatnachricht eines Modis trug damit
`"rolle":"modi"` an JEDEN im Saal -- auch an Creator und Scouts, vor
denen der Zugang verborgen sein soll. Ein Blick in die Netzwerkspur
genuegte, im Quelltext war nichts zu sehen.

Die Wortleck-Pruefung KANN das nicht finden: Sie durchsucht Dateien,
nicht Antworten. Und `pruef-modi-verborgen`, die Nutzlasten prueft,
kannte den Live-Chat nicht (0 Treffer auf "reaktion/chat").

GELOEST, INDEM DIE OBERFLAECHE DIE ROLLE NICHT MEHR BRAUCHT. Sie tat
damit genau zwei Dinge: ein Abzeichen malen und "gehoert zum Team"
setzen. Beides entscheidet jetzt der Server (CHAT_ABZEICHEN) und
schickt Wort plus Farbkennung fertig mit -- an EINER Stelle, benutzt
von beiden Ausgaengen (Liste und Ereignisstrom).

DAS WORT "Modi" GEHT WEITER MIT, und das ist kein Rest: Es steht
sichtbar auf dem Abzeichen, weil Filipe das ausdruecklich wollte
("die modis, linke hand und rechte hand soll im chat extra aussehen"),
und das Modi-Team ist oeffentlich. Verborgen ist nicht das TEAM,
sondern dass es einen eigenen ZUGANG gibt -- und der Schluessel `modi`
verlaesst das Haus jetzt nicht mehr. Die Farbkennung heisst
`moderation` und benennt die Aufgabe statt des Zugangs.

NEUE MESSUNG (pruef-modi-verborgen, Abschnitt 8b): Ein Modi schreibt
im Saal, ein Creator ruft ab, und der ROHE Antworttext darf den
Schluessel nicht enthalten. Case-SENSITIV und mit Begruendung: Der
Schluessel ist im ganzen Haus klein, das Anzeigewort gross. Dazu zwei
Gegenproben (die alte Antwort MUSS erkannt werden, das Anzeigewort
darf NICHT anschlagen) und eine Zeile, die verhindert, dass der
bequemste Weg zum gruenen Haken -- das Abzeichen weglassen -- unbemerkt
bleibt.

UND EIN STILLER AUSSETZER REPARIERT. pruef-reaktion las die Abzeichen
per Suchmuster aus reaktion.js und lief ueber die GEFUNDENEN Treffer.
Nach dem Umzug fand sie nichts -- und ZWOELF Pruefungen fielen lautlos
weg (421 -> 409), bei nur einer roten Zeile. Genau der Fall aus dem
Projektgedaechtnis vom 28.08.2026. Die Schleife laeuft jetzt ueber die
ERWARTETEN vier Rollen: Fehlt eine, wird ihre Zeile rot und die Anzahl
bleibt gleich. Gegenprobe gefahren -- Abzeichen entfernt: 423 Pruefungen
wie vorher, vier rot, mit "fehlt fuer modi" als Beleg.

pruef-modi-wortleck 8 gruen (vorher 1 rot), pruef-modi-verborgen
87 -> 101 gruen, pruef-reaktion 421 -> 423 gruen. Dazu gruen:
css-klassen, deutsche-texte, haus-trennung.

Co-Authored-By: Claude Opus 5 <[email protected]>
This commit is contained in:
2026-10-07 12:15:51 +02:00
co-authored by Claude Opus 5
parent da557b5288
commit 8f1ab790d1
52 changed files with 927 additions and 720 deletions
+92
View File
@@ -802,6 +802,98 @@ console.log("\n=== 8b. Der Hinweis nach zwei Fehlversuchen ===\n");
diese Person in jeder Liste DANACH auf -- und jeder spaetere
Abschnitt maesse einen Zustand, den es im Betrieb nicht gibt.
-------------------------------------------------------------------- */
/* ---------------------------------------------------------------------
8b. DER LIVE-CHAT VERRAET DIE ROLLE NICHT (07.10.2026)
DIE LUECKE, DIE ES BIS HEUTE GAB: `pruef-modi-wortleck` durchsucht
ausgelieferte DATEIEN. Sie kann nicht sehen, was der Server in einer
Antwort mitschickt -- und genau dort stand der Rollenname.
`/workspace/api/reaktion/chat` waehlte `rolle` aus der Tabelle und
gab sie unveraendert heraus. Eine Nachricht eines Modis trug damit
`"rolle":"modi"` an jeden im Saal, auch an Creator und Scouts. Ein
Blick in die Netzwerkspur genuegte; im Quelltext war nichts zu sehen,
weil nichts im Quelltext stand.
GEMESSEN WIRD DER ROHE TEXT der Antwort, nicht das ausgewertete
Objekt: Eine Rolle kann auch in einem Feld stecken, nach dem niemand
fragt. Was nicht im Text steht, steht nirgends.
DIE ZEILE KOMMT PER DATENBANK HINEIN und nicht ueber das Schreibfeld:
Ob ein Modi gerade schreiben DARF, haengt am Zustand der Sendung
(zu / nur Team / offen). Diese Pruefung fragt aber nicht, wer
schreiben darf, sondern was beim HERAUSGEHEN passiert -- und das soll
sie auch dann beantworten koennen, wenn der Saal geschlossen ist.
-------------------------------------------------------------------- */
console.log("\n=== 8b. Der Live-Chat gibt die Rolle nicht heraus ===\n");
{
const dc = new DatabaseSync(process.env.WORKSPACE_DB);
dc.prepare(`INSERT INTO reaktion_chat (person_id, name, rolle, text, erstellt)
VALUES (?,?,?,?,?)`)
.run(idModi1, "Modi Marina", "modi", "Hallo aus dem Saal", jetzt);
dc.close();
const anC = await anmelden("creator", "CODE-ANNA-0001");
if (anC.status !== 200) {
unklar(`Creator: Anmeldung misslang (${anC.status}) -- der Chat blieb ungeprueft`);
} else {
const a = await fetch(BASIS + "/workspace/api/reaktion/chat",
{ headers: { cookie: anC.keks } });
const roh = await a.text();
ok(a.status === 200, `der Creator bekommt den Chat (${a.status})`);
/* DIE ZAHL IN DER BEDINGUNG: Eine leere Antwort enthaelt den Namen
auch nicht -- und bewiese nichts. Der Beitrag MUSS drin sein. */
const drin = roh.includes("Hallo aus dem Saal");
ok(drin, `der Beitrag des Modis steht wirklich darin (${roh.length} Zeichen)`);
/* GEPRUEFT WIRD DER SCHLUESSEL, NICHT DAS WORT -- und der
Unterschied ist der ganze Punkt dieser Pruefung.
Beim ersten Anlauf stand hier `/\bmodis?\b/i` und meldete rot.
Der Fund war echt und trotzdem kein Mangel: In der Antwort steht
`"abzeichen":{"wort":"Modi",...}` -- das Wort, das im Chat
SICHTBAR neben dem Namen klebt, weil Filipe das ausdruecklich so
wollte („die modis, linke hand und rechte hand soll im chat extra
aussehen"). Ein Wort, das auf dem Bildschirm steht, kann man
nicht aus der Antwort heraushalten, in der es steht.
WAS WIRKLICH GEHEIM IST, ist der Schluessel: `modi` als Wert in
`rolle`, als Vergleich im Code, als Kennung im CSS. Der ist im
ganzen Haus KLEINGESCHRIEBEN -- in der Datenbank, in den
Rollenlisten, in den Auswahlen. Das Anzeigewort ist
grossgeschrieben. Deshalb hier ausdruecklich OHNE `i`.
Und weil Grossschreibung allein eine duenne Grenze waere, kommt
die zweite Bedingung dazu: Das Feld `rolle` darf in der Antwort
gar nicht vorkommen. Beides zusammen faengt sowohl den alten
Fall (`"rolle":"modi"`) als auch einen neuen, der ihn anders
schreibt. */
const schluesselDrin = /\bmodis?\b/.test(roh) || /"rolle"/.test(roh);
ok(drin && !schluesselDrin,
`der Rollenschluessel steht nirgends in der Antwort`
+ (schluesselDrin ? ` -- GEFUNDEN in: ${roh.slice(0, 220)}` : ""));
/* GEGENPROBE ZUM MESSGERAET: Genau der Text, der frueher
herausging, MUSS anschlagen. Ohne sie hiesse „nichts gefunden"
auch „die Suche findet nie etwas". */
const alteAntwort = '{"beitraege":[{"id":1,"name":"Marina","rolle":"modi"}]}';
ok(/\bmodis?\b/.test(alteAntwort) && /"rolle"/.test(alteAntwort),
"Gegenprobe: die alte Antwort wuerde erkannt");
ok(!/\bmodis?\b/.test('{"wort":"Modi"}'),
"Gegenprobe: das sichtbare Anzeigewort schlaegt nicht an");
/* UND DAS ABZEICHEN IST TROTZDEM DA. Ohne diese Zeile waere der
bequemste Weg zu einem gruenen Haken, das Abzeichen ganz
wegzulassen -- dann verraet nichts mehr etwas, und Filipes Wunsch
(„die modis ... soll im chat extra aussehen") waere stillschweigend
weg. */
let geparst = null;
try { geparst = JSON.parse(roh); } catch { /* bleibt null */ }
const meiner = (geparst?.beitraege || []).find((b) => b.text === "Hallo aus dem Saal");
ok(!!meiner?.abzeichen?.wort,
`das Abzeichen kommt trotzdem mit (${JSON.stringify(meiner?.abzeichen)})`);
ok(meiner?.rolle === undefined,
`und das Feld "rolle" gibt es gar nicht mehr (${JSON.stringify(meiner?.rolle)})`);
}
}
console.log("\n=== 9. Gegenprobe: kann diese Pruefung ueberhaupt anschlagen? ===\n");
{
const d2 = new DatabaseSync(process.env.WORKSPACE_DB);