2 Commits

Include renames

Author	SHA1	Message	Date
DogFatherGitandClaude Opus 5	2bebab156b	Profilbild gebaendigt, Steckbrief von der Creator-Akte getrennt ... ZWEI FEHLER, DIE FILIPE GESEHEN HAT. 1. DAS PROFILBILD LAG UEBER DER HALBEN SEITE. Als Patrick sein Bild hochlud, zog sich ein roter Balken quer ueber die Startseite. Ursache: Die CSS-Regel .wer__bild hat GEFEHLT. Das Element wurde in kopf.js erzeugt, die Regel dazu nie geschrieben -- und ein <img> ohne Groessenangabe nimmt seine natuerliche Groesse an, bei einem Handyfoto also mehrere tausend Pixel. Dazu fehlte overflow: hidden am Traeger. WARUM KEINE PRUEFUNG DAS GEFUNDEN HAT: Sie lud ein 1x1-Pixel-PNG hoch. Klein, schnell, von Hand gebaut -- und voellig unfaehig, irgendetwas zu ueberdecken. Die Pruefung war gruen, der Fehler war da, und gesehen hat ihn der Nutzer. Sie arbeitet jetzt mit einem 1200x1200-Bild, also in der Groesse, die wirklich hochgeladen wird, und misst danach: Bleibt das Bild in seinem 28-px-Feld, ragt es irgendwo heraus, laeuft die Seite ueber. Gegenprobe gemacht -- ohne die Regel meldet sie 1200x1200 in 28x28 und 918 px Ueberlauf. 2. ZWEI PERSONEN AUF EINEM BILDSCHIRM. Auf der Profilseite stand oben "Profil: SpongBobSchwammKopf" und mittendrin "MEIN PROFIL: Dogfather". Niemand konnte sagen, welche Angabe zu wem gehoert. Es sind auch wirklich zwei verschiedene Dinge: MEIN STECKBRIEF gehoert MIR -- Bild, ein Satz ueber mich, meine Kanaele. Fuehre ich selbst. CREATOR-PROFILE die BETREUUNGSAKTE eines anderen Menschen -- Ziele, 90-Tage-Plan, interne Notizen. Fuehren die Betreuer. Scouts, Manager und DogFather haben jetzt zwei getrennte Kacheln und eine eigene Seite (steckbrief.html, serverseitig geschuetzt). Ein Creator behaelt beides zusammen -- er hat nur eine Seite und sieht dort ausschliesslich sich selbst. Die Logik liegt in einer eigenen Datei statt hinten an profil.js: Sie gehoert der angemeldeten Person, nicht der Akte. ACHTZEHN KACHELN, ACHTZEHN FARBEN. Die neue Kachel haette sich ihren Farbton mit den Creator-Profilen geteilt -- zwei Nachbarn in derselben Farbe. Statt eine Farbe dazuzuerfinden, wurde tools/kachel-farben.mjs fuer 18 Winkel neu gerechnet, samt der neuen Nachbarschaft im Raster. Der kleinste Abstand zweier Nachbarn liegt weiterhin bei 100 Grad. Gefunden hat das die Startseitenpruefung ("17 Farben auf 18 Kacheln"). Die Trennung wird jetzt fuer JEDE Rolle geprueft: welche Kacheln sie sieht, dass auf der Akte kein fremder Steckbrief steht, und dass die eigene Seite die richtige Person zeigt. Eine alte Pruefung, die das Gegenteil verlangte, wurde ersetzt statt stehen gelassen. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-01 15:04:23 +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