1a2dfa07f31bdd95e97dc13f7faa2ff130f0f0eb
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
e3aeeb01cd |
Rollen wechseln: auch Spicy Media -- und DogFather ist nicht mehr vergebbar
Filipe: "ich will dass die rolle spicy und dogfather, auch die rollen
wechseln koennen wenn die personen schon drin sind. von alle
kategorien, creator, scouts, manager spicy. dogfather soll man nicht
auswaehlen koennen. das ist die einzige die man nicht auswaehlen kann
bitte."
ZWEI AENDERUNGEN, BEIDE IN EINER LISTE (ANLEGBAR):
admin: alles AUSSER der eigenen Rolle
spicy: spicy, manager, scout, creator (vorher ohne spicy)
Weil die Oberflaeche ihre Knoepfe aus derselben Auskunft baut
(`darf_anlegen` in /api/ich), verschwindet DogFather damit von selbst
aus JEDER Auswahl -- beim Anlegen wie beim Wechseln, bei Spicy Media
wie bei DogFather. Eine Liste, zwei Formulare, kein Nachziehen.
WAS DAS BEDEUTET, damit es niemand spaeter sucht: Es laesst sich kein
zweiter DogFather-Zugang mehr anlegen und niemand mehr zu einem
befoerdern. Der bestehende ist durch Sicherung 3 geschuetzt (nie den
letzten herabstufen) und kann nicht versehentlich verschwinden.
Zurueckdrehen laesst sich das nur in ANLEGBAR.
DIE TUER: /verwaltung haengt an nurAdmin, und dort steht jetzt eine
DRITTE enge Ausnahme -- PUT auf genau /personen/<Ziffern>/rolle, fuer
genau die Rollen aus darfRollenWechseln(). Gleiche Bauweise wie die
beiden davor (Liste fuer Spicy Media, Liste fuer die rechte Hand). Was
NICHT mitgeht: Codes, Sperren, Loeschen, Zuteilung, Protokoll.
EINE NEUE SICHERUNG, weil sich die Tuer geoeffnet hat: An einer
DogFather-Zeile aendert nur DogFather. Die bestehenden Pruefungen sehen
auf die ZIEL-Rolle ("darfst du 'manager' vergeben?") -- dass die
BETROFFENE Person DogFather ist, kam darin bis heute nicht vor.
Sicherung 3 haette es heute zufaellig abgefangen, weil es genau einen
gibt; eine Sperre, die nur wegen einer Zahl im Bestand haelt, ist
keine.
DIE OBERFLAECHE: "Rolle aendern" und "Loeschen" hingen an EINER Zeile
(`ich.rolle === 'admin'`). Sie gehoeren nicht zusammen -- Loeschen
bleibt bei DogFather. Und die CSS-Regel, die fuer Spicy Media die ganze
Knopfreihe ausblendete, ist weg: Welche Knoepfe es gibt, entscheidet
jetzt personen.js, und was nicht entsteht, muss man nicht verstecken.
pruef-spicy 62 -> 83. Gemessen wird jede der vier Kategorien EINZELN
(waere nur eine offen, saehe "geht" genauso aus), dazu: admin weder von
Spicy Media noch von DogFather vergebbar, an DogFathers Zeile aendert
sie nichts (und er ist danach nachweislich noch admin), ein Manager
kommt an den Weg nicht, loeschen bleibt zu -- und im Browser, dass der
KNOPF da ist, nicht nur das Recht. Genau daran war heute frueh im Chat
eine Stunde draufgegangen.
Dabei zwei eigene Messfehler gefunden: Die Knoepfe entstehen erst in
einer AUFGEKLAPPTEN Kategorie (vorher zu frueh gemessen), und /api/ich
wird jetzt als Vorbedingung geprueft.
DREI PRUEFUNGEN GEDREHT, KEINE GELOESCHT:
- pruef-personen-formular: 7 Karten, `admin` fehlt (eigene Aussage).
Die Zeichenpruefung verglich die rechte Hand gegen die Admin-KARTE --
die es nicht mehr gibt; sie lief gegen `undefined`. Ersatz ist das
Zeichen selbst, und der Kommentar sagt, dass das schwaecher ist.
- pruef-haus-trennung: Der zweite DogFather entsteht jetzt im Bestand
statt ueber die Schnittstelle, und DASS die Schnittstelle ihn
ablehnt, ist der erste Prueffall geworden. Sonst waere "nie den
letzten DogFather" ab heute ungeprueft -- weil ihre Voraussetzung
schwerer herzustellen ist.
- pruef-creator-anlegen: aus einer Aussage zwei (die vier sind da UND
admin fehlt).
Gruen: personen-liste, personen-kachel, verborgen, manager-sicht,
creator-anlegen, haus-trennung, personen-formular, spicy, rollen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
bcc1c70f4a |
Spicy Media legt Manager UND Scouts an -- eine Liste statt vier
Filipe, mit Bildschirmfoto der Zugaenge-Seite: "die spicy rolle soll auch manager und scouts hinzufuegen koennen." DER MANAGER-KNOPF FEHLTE NICHT AUS RECHTEGRUENDEN. Serverseitig war die Tuer /workspace/api/manager-anlegen fuer Spicy Media die ganze Zeit offen. Es gab nur nichts zum Draufdruecken -- wegen ZWEIER Listen in derselben Funktion, drei Zeilen auseinander (personen.js): const darf = ... spicy ? ['manager', 'creator'] : ['creator']; ... if ((r.wert === 'admin' || r.wert === 'manager') && ich.rolle !== 'admin') continue; Die erste erlaubt den Manager, die zweite nimmt ihn wieder weg. Uebrig blieb ein einziger Knopf: Creator. Nichts war kaputt, nichts wurde rot, es fehlte einfach -- die Sorte Fehler, die nur jemandem auffaellt, der davorsitzt. FUER SCOUTS GAB ES UEBERHAUPT KEINE TUER. Nur DogFather konnte welche anlegen. Und die Wegwahl in der Oberflaeche war eine Kette mit Auffangbecken (`rolle === 'manager' ? ... : creator-anlegen`): Ein Scout waere im else gelandet, und creator-anlegen legt IMMER einen Creator an. Der Knopf haette Erfolg gemeldet und das Falsche getan. DIE ANTWORT STEHT JETZT AN EINER STELLE. `darfAnlegen` in workspace.js sagt, wer wen anlegen darf. Daraus lesen: - die beiden Team-Tueren (Manager, Scout) - die allgemeine Verwaltungs-Tuer von DogFather - die Oberflaeche, ueber `darf_anlegen` in /workspace/api/ich Die Oberflaeche hat damit gar keine eigene Liste mehr und kann deshalb auch nicht mehr abweichen -- weder zu streng noch zu grosszuegig. ZWEI TUEREN, NICHT EINE MIT EINEM ROLLENFELD. Der Absatz an der Manager-Tuer raet davon ab, und der Rat gilt: Eine Tuer, die NICHTS anderes kann, als eine bestimmte Rolle anzulegen, ist sicherer als eine, die vorher nachfragt. `teamTuer(rolle)` baut beide aus demselben Text -- die Rolle wird beim Einhaengen festgelegt und kommt nie aus dem Aufruf. Geprueft: ein mitgeschicktes "rolle: admin" bleibt wirkungslos. GEPRUEFT (pruef-creator-anlegen, 33 -> 49 Pruefungen) - Spicy Media legt Manager an -> 201, Rolle stimmt - Spicy Media legt Scout an -> 201, Rolle stimmt - "rolle: admin" mitgeschickt -> wirkungslos, es wird ein Scout - ein Manager durch die Scout-Tuer -> 404 - ein Scout durch die Scout-Tuer -> 404 - Personenliste lesen -> 200 (die eine gewollte Ausnahme) - darueber anlegen -> 404, und es entsteht niemand - /api/ich nennt Spicy: manager, scout, creator -- und keinen DogFather - ein Manager bekommt genau eine Rolle genannt, ein Scout keine - die Knoepfe auf der Seite stimmen mit alldem ueberein - DogFather sieht unveraendert alle -- gemessen, nicht geglaubt Der erste Anlauf der Pruefung behauptete, Spicy Media komme gar nicht an /workspace/api/verwaltung. Falsch, und sie wurde zu Recht rot: nurAdmin laesst genau einen Fall durch, das LESEN der Personenliste. Diese Trennung ist jetzt festgenagelt. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
49bd4a7cec |
Manager legen Creator an -- eine neue Tuer statt eines Schluessels fuer die alte
Filipe: "wieso greift das in die rechte rein? ist doch ok, die sollen einfach paar leute selber hinzufuegen koennen." Er hat recht, und ich hatte zwei Dinge in einen Topf geworfen: Das hier braucht KEINE Datenbankaenderung -- nur die Rolle "Spicy Media" braucht eine. WARUM EIN EIGENER WEG UND NICHT DIE ALTE TUER Alles unter /workspace/api/verwaltung haengt an EINER Schranke (nurAdmin). Dahinter liegen acht Wege: Rollen aendern, Codes neu setzen, sperren, loeschen, Protokoll lesen. Einen Manager dort hineinzulassen und danach in jedem der acht einzeln zu pruefen, was er darf, ist genau die Bauweise, durch die am 31.08.2026 ein Loch entstanden ist -- zwei von drei Stellen abgesichert, die dritte vergessen. Deshalb bleibt die Tuer zu, und daneben steht eine neue mit genau einem Zweck: POST /workspace/api/creator-anlegen. Sie kann nichts anderes, als einen Creator anzulegen -- nicht weil eine Abfrage es verbietet, sondern weil es hier keinen anderen Weg gibt. Unterschied zwischen "darf nicht" und "kann nicht". DIE ROLLE STEHT NICHT IM AUFRUF, sie wird im Server gesetzt. Ein Feld `rolle` im Koerper waere die naheliegende Loesung und die falsche: Dann muesste eine Abfrage sie pruefen, und eine vergessene Abfrage ist ein zweiter Zugang mit vollen Rechten. Geprueft wird deshalb nicht, dass ein mitgeschicktes `rolle: "admin"` abgelehnt wird, sondern dass es WIRKUNGSLOS ist. DIE ZUTEILUNG PASSIERT SOFORT. Ein Creator ohne Betreuung ist fuer alle ausser DogFather unsichtbar -- der Manager haette ihn angelegt und danach nicht mehr gesehen. Wer anlegt, betreut; ein eigener Scout kann mitgegeben werden. Eine FREMDE Scout-Nummer wird abgelehnt (403) und nicht stillschweigend auf den Anleger zurueckgesetzt: Sonst glaubte der Manager, er haette zugeteilt. Der Knopf sitzt auf dem Dashboard, nicht in der Personenverwaltung -- dort kommt ein Manager gar nicht hinein, und hier sieht er seine Creator ohnehin. Der Zugangscode steht einmal im Dialog und wird nie nachgeladen; deshalb schliesst sich das Fenster NICHT von selbst. pruef-creator-anlegen.mjs, 29 Pruefungen, alle gruen -- und die Haelfte davon prueft, was NICHT geht: Personenverwaltung 404 fuer Manager, Scout und Creator kommen gar nicht erst durch, fremder Scout 403 (und der Creator wird dabei gar nicht erst angelegt), erfundene Nummer 403. Zwei Manager mit je einem eigenen Scout, weil sich "nur die eigenen" mit nur einem Manager gar nicht pruefen laesst. Nebenbei: .feld-hinweis ist von bereich.css nach aufgaben.css gewandert (zu den uebrigen Formularstilen) -- ein Formularbaustein in der Bereichsdatei ist nur so lange richtig, wie ihn keine zweite Seite braucht. Gruen: creator-anlegen (29), personen-liste (33), css-klassen (15), struktur (32), formulare (19). Co-Authored-By: Claude Opus 5 <[email protected]> |