2 Commits

Include renames

Author	SHA1	Message	Date
DogFatherGitandClaude Opus 5	0404f8c0c1	Dreizehn Lecks: eine Managerin sah die Creator aller anderen ... Wunsch: "jeder manager soll auch immer nur seine und die seiner scouts zugeteilten creator und creator daten sehen. und nicht die der anderen." DIE KETTE WAR GEBAUT -- SIE WURDE NUR NICHT BENUTZT Manager -> seine Scouts -> deren Creator steht seit dem 01.09.2026 an genau einer Stelle (betreuteIds). Die Frage war eine andere: Benutzt sie auch JEDER Weg, der Creator-Daten herausgibt? Ueber zwanzig Stellen prueften die ROLLE statt der ZUTEILUNG -- "ist Leitung? dann alles". NICHT GELESEN, SONDERN GEMESSEN server/pruef-manager-sicht.mjs baut zwei Managerinnen mit vollstaendig getrennten Creators. Bei der fremden heisst ALLES "GEHEIM..." -- Aufgabe, Termin, Bereichseintrag, Datei, Steckbrief, Content-Saeule. Danach wird jede der 31 Leseschnittstellen abgefragt und die ganze Antwort danach durchsucht. Ein Leck faellt damit auf, egal wo es sitzt und egal, ob ich es beim Lesen uebersehen haette. GEFUNDEN: DREIZEHN. Alle geschlossen: Kalender fremde Fristen -- besonders unangenehm, weil es nicht wie ein Leck aussieht: eine kleine orange Marke mit einem Titel, in dem fremde Vorhaben stehen Personenauswahl alle Namen im Zuweisungsfeld Dateien alle Namen in der Freigabe-Auswahl Uebersicht Gesamtuebersicht ueber ALLE Creator Report Auswahl UND Auswertung ueber den ganzen Bestand Start-Check alle Creator zur Auswahl Steckbriefe Bild, Kanaele, "ueber mich" von allen Profile alle Profile, samt interner Notiz Schulung Schulungsstand aller Creator Suche Creator-Profile aller -- die unauffaelligste Stelle: Man sucht etwas anderes und bekommt fremde Namen Content-Balance Themensaeulen fremder Kanaele (die Abfrage daneben war korrekt eingeschraenkt, DIESE hatte eine eigene Bedingung) darfCreator eine einzige Zeile -- sie hing an Profil, Start-Check und Uebersicht gleichzeitig. Es reichte, eine Nummer in die Adresse zu schreiben. Die Antwort steht jetzt an EINER Stelle: sichtbareCreatorIds und sichtbarePersonenIds in workspace.js. Rueckgabe null heisst "alle" und gilt allein DogFather -- bewusst kein leeres Feld: Eine leere Liste bedeutet "niemand", und die Verwechslung der beiden macht aus einer Sperre eine Freigabe. ZWEI DINGE, DIE ICH MIR SELBST NACHTRAGEN MUSS 1. Beim Stopfen fehlte einmal ein Import. Der Weg warf einen Fehler, antwortete 503 -- und weil in einer Fehlermeldung kein "GEHEIM" steht, meldete die Pruefung "kein Leck". Sie war gruen, weil der Weg KAPUTT war. Die Pruefung zaehlt jetzt beides: nichts durchsickern UND antworten. 2. Ein Fehlalarm: Die Suche gibt den SUCHBEGRIFF in ihrer Antwort zurueck. Wer nach "GEHEIM" sucht, findet das Wort zwangslaeufig -- auch bei null Treffern. Ich haette um ein Haar ein Leck "repariert", das es nie gab. Das Echo wird jetzt entfernt, bevor gemessen wird. FOLGEN, bewusst in Kauf genommen: * Ein Manager ohne Zuteilung sieht keinen Creator. Die Uebersicht sagt ihm das jetzt in einem Satz, statt leer zu bleiben. * Er kann nur noch IN SEINEN Creator-Bereichen schreiben (darfCreator). ZWEI PRUEFUNGEN UMGEDREHT statt geloescht -- eine geloeschte Pruefung hinterlaesst keine Spur davon, dass hier einmal etwas anderes galt: pruef-uebersicht ("Manager sieht dasselbe" -> "nur seine zugeteilten", mit beiden Faellen) und pruef-scout-zuteilung ("sieht die ganze Personenliste" -> "landet auf der Startseite"). GEPRUEFT: 43 neue Pruefungen, dazu 23 bestehende Laeufe gruen -- Startansicht 133, Rollen 97, Kalender 84, Serien 67, Steckbrief 65, Handy 50, Sicht 48, Ampel 47, Content 45, Aufgabenbrett 44, Schulung 41, Bereiche 37, Scout-Zuteilung 36, Uebersicht 35, Personenliste 33, Freie Namen 32, Team 30, Protokoll-Loeschen 20, Personenformular 20, Formulare 19, Betreuung 18, Code 17, Grosscheck 15. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-03 01:01:00 +02:00
DogFatherGitandClaude Opus 5	299ef0d506	Eigenes Profil fuer jeden - mit Bild und Kanaelen ... SCREEN 1: Jeder im Workspace hat jetzt seinen eigenen Steckbrief -- Creator, Scout, Manager und DogFather gleichermassen. Ein Bild, ein Satz ueber sich, und die Kanaele, auf denen er unterwegs ist. Er steht ganz oben auf profil.html, ueber der Creator-Akte; die ist etwas anderes (die fuehren die Betreuer, den Steckbrief fuehrt man selbst). Das Bild erscheint sofort ueberall: in der Kopfleiste jeder Seite und in der Begruessung. /api/ich liefert es deshalb gleich mit -- das spart auf jeder Seite eine zweite Abfrage und verhindert, dass die Plakette erst als Buchstabe erscheint und dann umspringt. Faellt das Bild aus, steht der Buchstabe da: Er wird nicht ersetzt, sondern liegt darunter. WARUM KEINE ECHTE TIKTOK-ANMELDUNG. "Mit TikTok verbinden" klingt nach OAuth. Das waere: ein Entwicklerkonto mit App-Freischaltung, eine Pruefung durch TikTok (Wochen, widerrufbar), je Person ein Zugriffstoken, das ablaeuft, erneuert werden muss und -- wenn es abhandenkommt -- fremden Zugriff auf ein fremdes Konto bedeutet. Dafuer bekaeme man Follower-Zahlen. Gebraucht wird hier aber "Wer ist das, und wo finde ich ihn?". Dafuer genuegt der oeffentliche Name. Gespeichert wird deshalb NUR das Handle -- kein Token, kein Passwort, nichts, was abhandenkommen kann. Daraus wird ein Verweis auf den Kanal. Vier Kanaele: TikTok, Instagram, YouTube, Twitch. Sollen spaeter echte Zahlen dazukommen, ist das ein eigenes Vorhaben -- der Name hier bleibt dann trotzdem richtig. Eingefuegt werden darf, was Leute wirklich in der Zwischenablage haben: "@name", "https://www.tiktok.com/@name" oder der Name allein. Alles wird auf den Namen zurueckgefuehrt, statt eine Fehlermeldung zu zeigen. SICHERHEIT beim Bild -- die drei Stellen, an denen Profilbilder typischerweise scheitern: 1. Der Typ wird an der SIGNATUR der Datei geprueft, nicht am Content-Type, den der Absender behauptet. Ein umbenanntes SVG mit Skript darin kaeme sonst durch und liefe im Namen der Domain -- mit der Sitzung des Betrachters. 2. Auf der Platte bekommt jede Datei einen Zufallsnamen. Kein Name kann Pfade verlassen oder etwas ueberschreiben. 3. Ausgeliefert mit nosniff und einer eigenen, alles verbietenden Inhaltsregel. Das Bild liegt als Datei neben der Datenbank, nicht darin: Bilder in SQLite blaehen jede Sicherung auf, und die laeuft jede Nacht. Niemand schreibt einem anderen ins Profil -- auch DogFather nicht. Ein Satz ueber sich und der eigene Kanalname gehoeren der Person. Wer wen SEHEN darf, folgt der bekannten Regel: Leitung alle, Scout seine Creator, Creator sich und seine Betreuer. Fremde Profile sind 404, nicht 403. ZWEI FUNDE DURCH DIE PRUEFUNG: - Der TikTok-Link, den die App beim Teilen kopiert, endet auf "?lang=de&is_from_webapp=1". Der wurde abgelehnt: "sieht nicht richtig aus" -- obwohl es der offizielle Link ist. Jetzt werden Parameter und Anker mit abgeschnitten. - Ein zu grosses Bild ergab "500 Serverfehler" statt einer Ansage. Der PayloadTooLargeError lief bis in die allgemeine Fehlerbehandlung durch. Jetzt 413 mit dem Satz, wie viel erlaubt ist. Von Hand haette das vermutlich nie jemand probiert. Vor der Schemaaenderung wurde eine geprueft vollstaendige Sicherung gezogen (VACUUM INTO, Integritaet ok, 6 Personen). Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-01 11:31:34 +02:00