Files
dogfather-universe/server/rechte.js
T
DogFatherGitandClaude Opus 5 47a91e9708 Die goldene Regel: was nicht in der Tafel steht, ist verboten
Filipe: "egal welche rolle oder person hinzugefuegt wird soll immer nur
das sehen wass ich erlaube. mehr nicht. soll nichts so sein dass wenn
mann eine rolle oder jemanden hinzufuegt dass er dan alles sieht."

DER BEFUND -- GEZAEHLT, NICHT GESCHAETZT

NEUN von zwanzig Seiten standen auf `null`, und `null` hiess "jede
angemeldete Rolle": Start, Uebersicht, Aufgaben, Chat, Kalender,
Dateien, Calls, Start-Check, Wissen. Eine neue Rolle erbte sie alle,
ohne dass jemand etwas erlaubt haette.

UND EIN ZWEITES LOCH, das ich vorher nicht gemessen hatte: Die Schranke
las `const erlaubt = GESCHUETZT[pfad]` und prueffte `if (erlaubt && ...)`.
Eine Seite, die GAR NICHT in der Tabelle stand, ergab `undefined`, fiel
durch dieselbe Bedingung und war damit ebenfalls fuer jede angemeldete
Rolle offen. Am 11.09.2026 betraf das keine einzige Seite (nachgezaehlt:
22 Dateien = 20 Eintraege + 2 Zugangswaende) -- aber jede NEUE waere so
entstanden.

Die Rolle wird im Haus an 74 Stellen in 20 Modulen abgefragt, und die
Endzweige widersprechen einander: Aufgaben enden mit `default: 0=1`
(sieht nichts), Bereiche und Dateien fallen in "eigene plus betreute".
Drei Module, drei Antworten auf dieselbe Frage.

WARUM NICHT "DIE LISTE DURCHGEHEN"

Das waere die naheliegende Antwort und die falsche. Im Code stand seit
dem 10.09. genau dieser Satz -- "Wer eine Rolle hinzufuegt, muss diese
Liste durchgehen" -- und einen Tag spaeter standen immer noch neun
Seiten auf `null`. Ein Satz, der sich auf ein Gedaechtnis verlaesst, ist
keine Sicherung. Dazu: eine vergessene Erlaubnis MELDET SICH NIE. Die
Seite laedt ja. In der anderen Richtung ist es schlimmer -- eine Seite,
die zu viel zeigt, sieht aus wie eine Seite, die funktioniert.

WAS JETZT GILT

server/rechte.js traegt die Tafel, `darfSeite()` liest sie, und sie
kennt zwei Antworten: Seite in der Tafel UND Rolle darin -> ja. Alles
andere -> nein. Kein `null`, kein `undefined`, kein Zweig, der etwas
durchlaesst.

DIE TABELLE IST UMGEZOGEN, NICHT NEU GESCHRIEBEN. In ihren Kommentaren
steckt das Gedaechtnis des Hauses -- jede Zeile traegt ein Datum und
einen Satz von Filipe ("nimm die kategorie zahlen bei jedem weg", "die
manager sollen diese kategorien garnicht sehen", "ich will dass die
rechte Hand auch alle sieht"). Die wegzurefactoren waere der teuerste
Fehler dieses Umbaus gewesen.

VERHALTENSGLEICH FUER DIE SIEBEN VORHANDENEN ROLLEN. Die neun
`null`-Seiten tragen jetzt alle sieben Namen. Eine Umkehrung, die
nebenbei Rechte entzieht, waeren zwei Aenderungen in einer -- und man
wuesste hinterher nicht, welche etwas kaputtgemacht hat. Enger stellen
ist ein eigener Schritt.

pruef-rechtetafel.mjs (NEU, 19 Pruefungen, Port 4397) macht daraus eine
Garantie statt einer Absicht:

  * Jede Rolle braucht einen Eintrag -- sonst rot. Man kann eine Rolle
    nicht mehr hinzufuegen, ohne zu entscheiden, was sie sieht.
  * Jede Seite braucht einen Eintrag -- verglichen gegen das
    DATEISYSTEM, nicht gegen eine zweite Liste. Eine neue Seite ist
    damit erst einmal fuer NIEMANDEN offen statt fuer alle.
  * Eine Phantomrolle kommt auf keine der zwanzig Seiten.
  * Gegenprobe: jede ECHTE Rolle kommt irgendwo hin (spicy 18, admin 20,
    manager 17, scout 16, creator 15, hand 13, modi 11) -- sonst waere
    die Zeile darueber auch gruen, wenn schlicht alles zu waere.
  * Am Server: eine Seite ohne Eintrag wird abgewiesen statt
    ausgeliefert, und alle 20 Seiten der DogFather-Rolle liefern wirklich.
  * Zerstoerende Probe ganz am Ende (die Lektion vom 09.09.: in der
    Mitte verbiegt sie alles danach).

ZWEI EIGENE FEHLER UNTERWEGS. `node --check` meldete "Syntax in
Ordnung", das Modul lud aber nicht -- beim Umzug war eine Konstante
verlorengegangen. Syntax ist kein Beweis. Und ein Kommentar behauptete
danach noch das Alte ("eine neue Seite ist mindestens nur fuer
Angemeldete"); der Rueckfall ist jetzt "fuer niemanden", und das steht
da auch so.

Gruen: pruef-rechtetafel 19 (neu), pruef-rollen 287, pruef-sicht 84,
pruef-crew-adresse 129, pruef-modi-verborgen 80, pruef-haus-trennung 62.
Stempel 202609111617.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-11 16:18:09 +02:00

308 lines
15 KiB
JavaScript

/* =====================================================================
DIE RECHTETAFEL — was jede Rolle sehen darf, an einer Stelle
=====================================================================
Filipe, 11.09.2026:
"egal welche rolle oder person hinzugefuegt wird soll immer nur
das sehen wass ich erlaube. mehr nicht. soll nichts so sein dass
wenn mann eine rolle oder jemanden hinzufuegt dass er dan alles
sieht, soll jede rolle immer nur das sehen was sie sehen sollen."
---------------------------------------------------------------------
DAS IST EINE UMKEHRUNG DER BAUWEISE, KEINE EINSTELLUNG
Vorher galt: erlauben, ausser es steht etwas dagegen. Die Tabelle
der geschuetzten Seiten hiess sogar so -- "GESCHUETZT ist die
Ausnahme, nicht die Regel" -- und sie kannte zwei Wege, auf denen
etwas durchfiel:
1. `null` als Wert hiess "jede angemeldete Rolle". NEUN von zwanzig
Seiten standen darauf: Start, Uebersicht, Aufgaben, Chat,
Kalender, Dateien, Calls, Start-Check, Wissen. Eine neue Rolle
erbte sie alle, ohne dass jemand etwas erlaubt haette.
2. Eine Seite, die GAR NICHT in der Tabelle stand, fiel durch
dieselbe Bedingung (`if (erlaubt && ...)`) und war damit
ebenfalls fuer jeden offen. Das betraf am 11.09.2026 keine
einzige Seite -- gemessen, nicht gehofft --, aber jede neue
waere so entstanden.
Ab hier gilt das Gegenteil: WAS NICHT IN DIESER TAFEL STEHT, IST
VERBOTEN. Kein `null`, kein `undefined`, kein Zweig, der etwas
durchlaesst. `darfSeite()` kennt genau zwei Antworten.
---------------------------------------------------------------------
WARUM DAS NICHT "DIE LISTE EINMAL DURCHGEHEN" IST
Das waere die naheliegende Antwort und die falsche. Die Rolle wird
im Haus an 74 Stellen in 20 Modulen abgefragt (gezaehlt, nicht
geschaetzt). Drei Gruende, und alle drei sind hier schon eingetreten:
* Eine Liste ALTERT. Am 09.09. war `content.html` fuer eine neue
Rolle offen -- nicht aus Nachlaessigkeit, sondern weil die Seite
spaeter dazukam als die Ueberlegung.
* Eine vergessene Erlaubnis SCHWEIGT. Sie faellt nur dem auf, der
hindurchgeht, und der merkt nichts: Die Seite laedt ja. In der
anderen Richtung ist es schlimmer -- eine Seite, die zu viel
zeigt, sieht aus wie eine Seite, die funktioniert.
* Bei 74 Stellen ist "ich gehe sie alle durch" kein Verfahren,
sondern ein Vorsatz.
Deshalb steht die Antwort nicht in einem Kommentar, sondern in
`pruef-rechtetafel.mjs`: Eine Rolle ohne Eintrag macht den Prueflauf
rot. Eine Seite ohne Eintrag macht den Prueflauf rot. Man KANN es
nicht mehr vergessen.
---------------------------------------------------------------------
DIESE DATEI HAENGT VON NICHTS AB
Kein Import aus workspace.js -- sonst gaebe es einen Ring, und die
Tafel muesste warten, bis das grosse Modul geladen ist. Sie ist
damit auch ohne laufenden Server pruefbar, genau wie crew-adresse.js.
===================================================================== */
/** Alle Rollen, die es gibt. Muss zu ROLLEN in workspace.js passen --
* pruef-rechtetafel vergleicht die beiden und wird rot, wenn eine
* Rolle nur in einer der beiden Listen steht. */
export const ALLE_ROLLEN = [
"spicy", "admin", "manager", "scout", "creator", "hand", "modi",
];
/* Kurzform fuer die Tafel unten. `ALLE` heisst hier ausdruecklich
"alle Rollen, die es GIBT" -- nicht "alle, die es geben wird".
Genau darin liegt der Unterschied zum alten `null`. */
const ALLE = ALLE_ROLLEN;
/* Schutz der angemeldeten Seiten. Serverseitig, nicht nur im Browser --
sonst könnte man die Seite einfach direkt aufrufen. */
/* Pfad -> erlaubte Rollen. `null` heisst: jede angemeldete Rolle.
Die Rolle wird hier mitgeprueft und nicht nur in der Schnittstelle.
Sonst bekommt z. B. ein Creator die Verwaltungsseite zwar ausgeliefert
(HTTP 200) und sieht ihr Geruest, auch wenn sie danach leer bleibt und
das Skript ihn wegschickt. Sichtbar sein soll sie gar nicht. */
export const SEITEN = {
/* AUS `null` WURDE EINE LISTE (11.09.2026).
Filipe: "egal welche rolle oder person hinzugefuegt wird soll
immer nur das sehen wass ich erlaube."
Diese neun Seiten standen auf `null` -- das hiess "jede
angemeldete Rolle", also auch jede Rolle, die es noch gar nicht
gibt. Jetzt stehen die sieben, die es wirklich gibt.
FUER DIE VORHANDENEN ROLLEN AENDERT SICH DAMIT NICHTS. Das ist
Absicht: Eine Umkehrung, die nebenbei Rechte entzieht, waere
zwei Aenderungen in einer -- und man wuesste hinterher nicht,
welche der beiden etwas kaputtgemacht hat. Wer hier enger
stellen will, macht das als eigenen Schritt. */
"/workspace/start.html": [...ALLE],
"/workspace/uebersicht.html": [...ALLE],
/* AUSDRUECKLICH OHNE 'modi' (10.09.2026). Vorher stand hier `null`
("jede angemeldete Rolle") -- und mit der neuen Rolle hiess das
auch: sie. Die Seite laedt dann zwar, ihre Schnittstelle antwortet
ihm aber mit 404, weil `content` nicht zu seinen Bereichen gehoert.
Eine Seite, die man oeffnen kann und die dann leer bleibt, sieht
aus wie ein Fehler -- und ist einer.
Das ist die Kehrseite von "geschuetzt ist die Regel, nicht die
Ausnahme": Eine NEUE ROLLE erbt jedes `null` automatisch. Wer eine
Rolle hinzufuegt, muss diese Liste durchgehen -- der Kachel-Durchgang
in pruef-rollen findet die Faelle, die dabei auffallen. */
"/workspace/content.html": ["spicy", "admin", "manager", "scout", "creator"],
"/workspace/aufgaben.html": [...ALLE],
/* Chat (06.09.2026): jede Rolle. WEN man erreicht, entscheidet
schreibbareIds() -- nicht der Zugang zur Seite. Ein Creator, der
die Seite nicht öffnen dürfte, könnte auch nicht antworten, und
genau das Antworten ist der Zweck. */
"/workspace/chat.html": [...ALLE],
/* NUR DogFather (07.09.2026). Wunsch Filipe: "nimm die kategorie
zahlen bei jedem weg, nur die rolle dogfather soll die sehen."
Bis heute stand hier `null` -- jede Rolle durfte die Seite oeffnen,
und WESSEN Zahlen jemand sah, entschied sichtbareCreatorIds().
Die Begruendung dafuer war gut (es sind SEINE Zahlen), sie ist
jetzt aber nicht mehr meine Entscheidung.
WICHTIG: Die Kachel wegzunehmen haette NICHT gereicht. Eine Kachel
ist ein Weg, keine Schranke -- wer die Adresse kennt oder ein altes
Lesezeichen hat, waere weiterhin hineingekommen. Beides gehoert
zusammen: bereiche.js zeigt sie nur noch DogFather, diese Zeile
laesst nur ihn hinein. */
/* JETZT WIEDER FUER ALLE (11.09.2026). Filipe, mit der Kachel im
Bild: "jetzt soll jede rolle diese kachel sehen. spicy, dogfather,
manager, scout und creator. aber die creator kriegen dan quasi nur
ihre daten zu sehen und der manager scout dogfather oder spicy
koennen eintragen."
Die Zeile stand seit dem 07.09.2026 auf ["admin"] -- erst "nimm
die kategorie zahlen bei jedem weg", dann die Praezisierung, dass
auch Spicy Media sie nicht sieht. Beides ist damit aufgehoben.
AUSDRUECKLICH ALS LISTE, NICHT ALS `null`. `null` hiesse "jede
angemeldete Rolle" -- und damit automatisch auch jede Rolle, die
es noch gar nicht gibt. Genau das ist am 10.09. bei content.html
schiefgegangen. Hier stehen die fuenf, die Filipe genannt hat.
WER WAS DARF, steht NICHT hier. Diese Zeile oeffnet nur die Tuer.
Dahinter gilt weiterhin: sichtbareCreatorIds() entscheidet, WESSEN
Zahlen jemand sieht (ein Creator sieht genau sich selbst), und
darfEintragen() entscheidet, wer schreiben darf (Leitung + Scout,
also NICHT der Creator). Beides war schon vorher so gebaut und
bleibt unangetastet -- es war nur niemand da, der es benutzen
konnte. */
"/workspace/leistung.html": ["spicy", "admin", "manager", "scout", "creator"],
/* NUR DogFather (02.09.2026). Die Rollenauswahl verspricht das seit
jeher ("Manager -- dieselben Rechte, ausser der
Personenverwaltung"), die Schranke hielt sich nur nicht daran.
Wunsch: "die manager sollen diese kategorien garnicht sehen". */
/* PERSONEN & ZUGAENGE: jetzt auch fuer Manager und Spicy Media
(07.09.2026).
Filipe: "die manager sehen immer noch nicht die kachel personen &
zugangscode, wo sie dan die neuen creator hinzufuegen koennen ...
und die sollen in der kategorie wo die jetzt sehen werden auch noch
das mit den hinzufuegen sehen, alles andere auf der seite sollen die
weiterhin nicht sehen."
DIE SEITE OEFFNET SICH, DIE SCHNITTSTELLEN NICHT. Das ist der ganze
Trick und der Grund, warum das hier ungefaehrlich ist: Alles unter
/workspace/api/verwaltung haengt weiterhin an `nurAdmin` -- Rollen
aendern, Codes neu setzen, sperren, loeschen, Protokoll lesen
bleiben zu und antworten mit 404. Wer die Seite oeffnet, bekommt
also genau die Teile zu sehen, fuer die es auch einen Weg gibt.
Eine Seite ist kein Schutz, sie ist ein Weg. Der Schutz steht in den
Schnittstellen, und der ist unveraendert. */
/* 'hand' kam am 10.09.2026 dazu. Filipe: "ich will dass die rechte
Hand auch alle sieht."
ES WAR DIE DRITTE SCHICHT, DIE ZUSTIMMEN MUSSTE. Die Kachel stand
da, die Schnittstelle liess sie lesen -- und die Seite selbst warf
sie auf die Startseite zurueck. Gefunden hat das nicht das Auge,
sondern pruef-rollen: Sie geht jede Kachel jeder Rolle ab und
schaut, wo man landet ("Rechte Hand Kachel personen.html LANDET
AUF start.html").
Dass die Seite aufgeht, gibt ihr nichts, was die Schnittstellen ihr
nicht ohnehin geben: Alles unter /workspace/api/verwaltung ausser
der Liste antwortet ihr weiterhin mit 404. Eine Seite ist kein
Schutz, sie ist ein Weg. */
"/workspace/personen.html": ["spicy", "admin", "manager", "hand"],
"/workspace/profil.html": ["spicy", "admin", "manager", "scout", "creator"],
/* Der eigene Steckbrief -- jede Rolle hat einen. Ein Creator wird
dort nicht hingeschickt (er sieht seinen auf profil.html), darf die
Seite aber aufrufen: Sie zeigt ihm dasselbe, nur ohne die Akte. */
/* 'modi' kam am 10.09.2026 dazu. Der Steckbrief ist die EIGENE Seite
("Dein Bild und deine Kanäle"); profil.html daneben ist der
Entwicklungsplan eines Creators und fuer ihn sinnlos. Der erste
Anlauf hatte genau das verwechselt -- die Kachel hiess "Mein
Profil" und fuehrte auf eine Seite, deren Schnittstelle mit 404
antwortet, weil sie ausdruecklich nur Creator kennt. Gefunden vom
neuen Kachel-Durchgang in pruef-rollen. */
"/workspace/steckbrief.html": ["spicy", "admin", "manager", "scout", "creator", "hand", "modi"],
"/workspace/kalender.html": [...ALLE],
"/workspace/dateien.html": [...ALLE],
/* 'modi' kam am 10.09.2026 dazu -- und es war ein echter Fund: Ohne
diese Zeile leiteten VIER seiner Kacheln (Live-Ablauf, Community,
Technik, Ideen-Board) wortlos auf die Startseite zurueck. Der
Rollen-Rundgang meldete sie trotzdem als "ok": Eine Umleitung ist
kein Fehler, die Seite laedt ja -- nur eben eine andere. Seither
prueft pruef-rollen fuer JEDE Rolle, dass jede Kachel, die sie
bekommt, auch wirklich dort ankommt.
WELCHE Bereiche ein Modi oeffnen darf, entscheidet die Liste
seiner Kacheln (MODI_BEREICHE_ERLAUBT) -- sonst kaeme er ueber die
Adresszeile auch in die Agentur-Ablage. */
"/workspace/bereich.html": ["spicy", "admin", "manager", "scout", "creator", "hand", "modi"],
"/workspace/report.html": ["spicy", "admin", "manager", "scout", "creator"],
"/workspace/scouting.html": ["spicy", "admin", "manager", "scout"],
/* DIE ARBEITSLAGE DES TEAMS (09.09.2026).
Filipe: "so eine kategorie wie ueber die creator will ich dass nur
fuer die spicy und dogfather rolle auch ueber manager und scouts
gibt."
Nur diese beiden Rollen. Ein Manager sieht seine eigene Zeile hier
ausdruecklich NICHT -- das ist kein Versehen: Eine Uebersicht ueber
die Arbeit der Kollegen gehoert der Leitung, nicht der Reihe. Der
Schutz steht ohnehin in der Schnittstelle (workspace-team.js);
diese Zeile sorgt nur dafuer, dass niemand vor einer leeren Seite
steht. */
"/workspace/team.html": ["spicy", "admin"],
"/workspace/calls.html": [...ALLE],
"/workspace/startcheck.html": [...ALLE],
"/workspace/wissen.html": [...ALLE],
/* Ebenfalls nur DogFather: Was von allein passiert, bestimmt, was
allen anderen zugeschoben wird. */
/* AUTOMATIONEN BLEIBEN BEI DogFather (07.09.2026). Ausdruecklich:
"bei automationen sollen die nicht sehen." Dahinter liegen
Sicherungen, die KI und der Zustand des Servers -- das ist Betrieb,
nicht Betreuung. */
"/workspace/automation.html": ["admin"],
/* Die gemeinsame Lage des Teams -- nur die DogFather-Rolle, also
Filipe und VanVan (10.09.2026). Fuer alle anderen leitet die
Schranke auf die Startseite; die Schnittstelle dahinter antwortet
zusaetzlich mit 404. Zwei Schloesser, absichtlich: Faellt eines
weg, haelt das andere. */
/* Der Eingang: DogFather und seine rechte Hand. Blueprint 3.1 --
"Kann im Alltag vertretend Entscheidungen treffen." Genau das
passiert auf dieser Seite. */
"/workspace/teamlage.html": ["admin", "hand"],
};
/* Die Zugangswaende. Sie haben keine Rolle, weil sich dort noch
niemand angemeldet hat -- sie sind der Ort, an dem das passiert.
Sie stehen hier nur, damit die Pruefung "jede Datei hat einen
Eintrag" sie nicht als Luecke meldet. */
export const OHNE_ANMELDUNG = [
"/workspace/index.html",
"/workspace/crew-index.html",
];
/* =====================================================================
DIE EINE FRAGE, DIE ALLES BEANTWORTET
===================================================================== */
/**
* Darf diese Person diese Seite oeffnen?
*
* Zwei Antworten, keine dritte:
* - Die Seite steht in der Tafel UND die Rolle steht darin -> ja.
* - Alles andere -> nein. Auch eine Seite, die es in der Tafel gar
* nicht gibt. Das ist die eigentliche Aenderung.
*
* @param {{rolle?: string}|null} person
* @param {string} pfad z. B. "/workspace/start.html"
*/
export function darfSeite(person, pfad) {
const rolle = person?.rolle;
if (!rolle) return false;
const erlaubt = SEITEN[String(pfad || "")];
/* Kein Eintrag heisst NEIN. Vorher hiess es ja -- und genau darin
lag das Loch, das man einer neuen Seite nicht ansieht. */
if (!Array.isArray(erlaubt)) return false;
return erlaubt.includes(rolle);
}
/**
* Die Tafel aus der anderen Richtung: Rolle -> Seiten.
*
* Fuer die Uebersichtsseite ("Wer sieht was") und fuer Pruefungen.
* ABGELEITET, nicht zweitgeschrieben -- eine zweite Liste waere die
* Stelle, an der die beiden auseinanderlaufen.
*/
export function seitenFuer(rolle) {
return Object.entries(SEITEN)
.filter(([, r]) => r.includes(rolle))
.map(([p]) => p)
.sort();
}
/** Alle Seiten der Tafel -- fuer die Pruefung gegen die Platte. */
export function alleSeiten() {
return Object.keys(SEITEN).sort();
}