d845d91d708b483ade8502ca1fc9f50c454c7c3f
10
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 DogFatherGit
|
d845d91d70 |
Workspace: Scout-CRM -- Pipeline, Follow-ups und Uebergabe
/workspace/scouting.html. Erster Baustein aus Phase 3 und der Bereich,
in dem Scouts bisher praktisch nichts hatten.
Der Merksatz von Seite 15 ist hier die Sicherheitsregel, nicht nur eine
Beschreibung: "Scouts sehen ihre Pipeline -- die Admin-Rolle die
Gesamtuebersicht -- Creator keine Scout-internen Daten."
- Creator bekommen 404, nicht 403, und zwar auf Schnittstelle UND Seite.
Sie sollen nicht einmal erfahren, dass es den Bereich gibt.
- Ein Scout sieht ausschliesslich die eigene Pipeline. Geprueft: Patrick
bekommt auf Sams Lead 404 beim Lesen, Aendern und Loeschen.
- Das Management sieht alles, kann nach Scout filtern und Leads einem
Scout zuordnen.
Pipeline als gruppierte Liste, nicht als Board: Sechs Spalten waeren auf
dem Handy unbedienbar, und Scouts arbeiten unterwegs. Jede Stufe traegt
eine eigene Farbe an der linken Kante, die von kuehl (neu entdeckt) nach
gruen (uebergeben) laeuft -- die Richtung der Pipeline wird sichtbar,
ohne Ampel-Geblinke.
Jede Karte hat genau EINEN naheliegenden Schritt ("Weiter zu ..."), der
Rest steckt im aufklappbaren Teil. Der Weiter-Knopf traegt bewusst nur
die Farbe seiner Stufe statt des vollen Farbverlaufs, sonst waere die
Seite ein Streifenmuster aus identischen Leuchtbalken.
Faellige Follow-ups stehen als eigene Leiste ganz oben. Das ist der
Teil, der ohne System am ehesten untergeht -- nicht der Kontakt selbst,
sondern das Nachfassen.
Uebergabe ("Creator-Onboarding starten", Seite 15): Aus einem
uebergebenen Lead legt das Management mit einem Klick eine echte Person
mit Zugangscode an. Der Code wird genau einmal angezeigt, wie in der
Personenverwaltung. Die Qualifizierung des Scouts (Plattform, Handle,
Potenzial, LIVE-Aktivitaet) wandert dabei automatisch ins Creator-Profil
-- sonst muesste das Management abtippen, was laengst dasteht. Geprueft:
Lead -> Person -> Profil, alle drei verbunden, zweiter Versuch wird
abgelehnt.
Ein uebergebener Lead ist Teil der Betreuungsgeschichte -- den loescht
nur das Management, nicht der Scout (403).
Nebenbei: .knopf-still gab es im Baukasten noch gar nicht, die Zweit-
knoepfe waren nackte Systemknoepfe. Jetzt sauber definiert.
|
||
|
DogFatherGit
|
072ded20a2 |
Workspace: Reports & Review -- Phase 2 vollstaendig
/workspace/report.html. Fuehrt bewusst KEINE eigenen Eintraege, sondern fasst zusammen, was in Aufgaben, Bereichen, Terminen und Dateien schon steht: "Fortschritt wird nicht gefuehlt, sondern nachvollziehbar gemacht". Die vier Abschnitte sind woertlich die Fragen aus dem Deck, Seite 16: Was wurde erledigt? Was blockiert? Was hat funktioniert? Was kommt als Naechstes? Zwei Punkte daraus sind ernst genommen: 1. "Vorher / nachher" (Historie). Jede Zahl wird mit demselben, unmittelbar davorliegenden Zeitraum verglichen. Eine Zahl allein sagt wenig -- 3 erledigte Aufgaben sind gut oder schlecht, je nachdem ob es vorher 1 oder 9 waren. Bei Zahlen, wo mehr SCHLECHTER ist (offene Probleme), ist die Trendfarbe umgedreht. 2. "Jeder Review endet mit einer Entscheidung, nicht nur mit einer Zusammenfassung." Der Report legt deshalb direkt eine Aufgabe an -- ohne Seitenwechsel, mit hoher Prioritaet und optionaler Frist. Geprueft: Eintrag im Report -> Aufgabe erscheint im Brett. "Was blockiert?" zeigt zusaetzlich die drei am laengsten offenen Aufgaben mit Namen, nicht nur eine Zahl. Sichtbarkeit: - Scout: 404, sowohl Schnittstelle als auch Seite (leitet weg) - Creator: sieht nur sich. Geprueft -- Luna fordert ?creator=3 (Mika) an und bekommt einen Report ueber SICH, der Parameter wird fuer Nicht-Management ignoriert - Der Review-Termin aus dem Profil ist Steuerungswissen und wird einem Creator auch hier nicht mitgeschickt, genau wie im Profil selbst Damit ist Phase 2 aus dem Konzept vollstaendig. |
||
|
DogFatherGit
|
df9f87af0a |
Workspace: Phase 2 -- LIVE, Content, Technik, Community, Schutz
Fuenf Bereiche auf einmal, aber NICHT fuenf Module. Im Deck haben sie dieselbe Grundform: Eintraege zu einem Creator mit Art, Datum, Titel, Text und Status. Sie unterscheiden sich nur darin, welche Arten es gibt und ob eine Bewertung oder eine Dringlichkeit dazugehoert. Deshalb ein gemeinsamer Unterbau: eine Tabelle, eine Sichtbarkeitsregel, eine Pruefung, eine Ansichtsseite (bereich.html?b=live). Ein Fehler laesst sich damit an EINER Stelle beheben statt an fuenf, und ein weiterer Bereich waere ein Eintrag in BEREICHE -- kein neues Modul. Arten woertlich aus dem Deck (Seiten 7-12): live Vorbereitung / Waehrend LIVE / Auswertung + Bewertung 1-5 content Idee / Produktion / Veroeffentlicht technik Setup / Problem / Loesung / Anleitung + Dringlichkeit community Moderation / Aktion / Konflikt + Dringlichkeit schutz Richtlinie / Vorfall / Eskalation / Gelernt + Dringlichkeit Die Oberflaeche kennt die Bereiche nicht auswendig -- welche Arten und Zusatzfelder es gibt, sagt der Server in der Antwort. Geprueft, und zwar fuer alle fuenf gleichzeitig: - Sichtbarkeit: Chef sieht alles, Luna nur ihren Bereich, Mika nur seinen, Sam (Scout) gar nichts (404 -- Scouts haben mit der Creator-Betreuung nichts zu tun) - Luna legt Eintrag mit creator_id=Mika an: landet still in ihrem eigenen Bereich, Mika sieht ihn nicht - Luna auf Mikas Eintrag: 404; Luna loescht Chefs Eintrag ueber ihren Bereich: 403 (loeschen darf das Management und wer ihn schrieb -- sonst koennte ein Creator eine Notiz ueber sich verschwinden lassen) - Eintrag ueber den falschen Bereich in der Adresse ansprechen: 404 - unbekannte Art 400, Bewertung 9 (erlaubt 1-5) 400, unbekannter Bereich 404, fremde Herkunft 403 Beim Testen sahen Umlaute zunaechst zerstoert aus (efbfbd, das Unicode-Ersatzzeichen). Ursache war der curl-Aufruf: Git Bash kodiert $'\xc3\xbc' nach Locale um. Ueber den echten Weg (Browser) kommen Umlaute, ss und Gedankenstrich unveraendert an und liegen sauber in der Datenbank -- gegengeprueft auf Byte-Ebene. |
||
|
DogFatherGit
|
81b51ab94f |
Workspace: Dateiablage mit Freigabe-Ablauf (Phase 1 vollstaendig)
/workspace/dateien.html -- Ablegen per Ziehen oder Auswaehlen, Entwurf -> Review -> Freigabe, Filter je Zustand. OHNE NEUE ABHAENGIGKEIT. Uploads laufen ueblicherweise ueber multer. Hier schickt der Browser die Datei roh im Rumpf, der Name steht im Kopf (URI-kodiert, damit Umlaute heil ankommen). express.raw() bringt den passenden Empfaenger schon mit -- kein Zerlegen von multipart/form-data von Hand, was gerade hier heikel waere. Die drei Punkte, an denen Dateiablagen typischerweise scheitern: 1. Die Dateien liegen AUSSERHALB des Repos (workspace-daten/dateien/). Lagen sie darin, wuerde express.static sie ungeprueft ans Netz geben. 2. Auf der Platte traegt jede Datei einen erzeugten Zufallsnamen, der Originalname steht nur in der Datenbank. Geprueft mit dem Dateinamen "../../etc/passwd": gespeichert wurde "passwd", auf der Platte ein Zufallsname IM Ordner -- nichts ist ausgebrochen. 3. Ausgeliefert wird immer als Download mit neutralem Typ, dazu nosniff und CSP sandbox. Geprueft mit einer hochgeladenen boese.html: kommt als application/octet-stream zurueck, kann also keinen Code im Namen der Domain ausfuehren. Freigabe nach Konzept: Der Zustand "freigegeben" ist eine Abnahme und bleibt dem Management vorbehalten. Geprueft -- Luna kann Entwurf -> Review, aber nicht freigeben (403); eine freigegebene Datei kann sie weder aendern noch loeschen. Sichtbarkeit wie ueberall: Chef 2 Dateien, Luna 1, Mika 0. Zugriff auf eine fremde Datei: 404, nicht 403. Ein Fehler beim Testen gefunden: Bei zu grosser Datei brach express.raw ab, BEVOR der eigene Code lief -- der Fehler landete im allgemeinen Behandler als HTTP 500. Fuer die Nutzerin sah das aus wie ein kaputter Server statt wie "Datei zu gross". Jetzt faengt ein eigener Fehlerbehandler am Ende des Routers das ab und antwortet mit 413 und einer verstaendlichen Meldung. Damit ist Phase 1 aus dem Konzept vollstaendig. |
||
|
DogFatherGit
|
ef79659f8f |
Workspace: Kalender mit Terminen, Calls und Aufgaben-Fristen
/workspace/kalender.html -- letzter grosser Baustein aus Phase 1.
Zeigt zwei Quellen in EINER Ansicht, wie im Konzept gefordert
("Kalender & Calls" neben "Deadlines" und "Wiedervorlagen"):
* eigene Termine (Arten: Call, Termin, Review)
* Fristen offener Aufgaben, nur lesend eingeblendet
Nach Tagen gruppiert statt als Monatsraster: Es geht um wenige, dafuer
konkrete Termine. Eine Liste liest sich dabei besser und funktioniert auf
dem Handy ohne Umbau. Zeitraum umschaltbar: 14 / 30 / 90 Tage, wobei 90
den 90-Tage-Plan aus dem Konzept abdeckt.
Sichtbarkeit wie bei den Aufgaben, wieder an einer Stelle definiert.
Geprueft mit drei Konten:
Chef 2 Termine + 2 Fristen | Luna 2 + 1 | Sam 0 + 1
Die Fristen folgen dabei exakt der Aufgaben-Regel -- Sam sieht nur seine.
Loeschen darf das Management und wer den Termin selbst angelegt hat.
Sonst koennte ein Creator einen Call absagen, den das Management
angesetzt hat. Geprueft: Luna auf Chefs Call 403, auf ihren eigenen 200,
Sam sieht ihn gar nicht (404).
Weiteres:
- Ort/Link wird nur dann als Verweis dargestellt, wenn er wirklich mit
http(s) beginnt -- sonst liesse sich javascript: einschleusen
- Zeitpunkt und Dauer werden geprueft (kaputtes Datum 400,
5000 Minuten 400)
- Beginn steht als lokale Zeit ohne Zeitzone: Alle Beteiligten sitzen in
derselben, eine falsch umgerechnete Uhrzeit waere schlimmer als gar
keine Umrechnung
|
||
|
DogFatherGit
|
8bfd2ae166 |
Workspace: Creator-Profile (Onboarding aus dem Konzept)
/workspace/profil.html -- Stammdaten, Ziele und 90-Tage-Plan, genau nach Seite 5 des Konzepts. Management waehlt oben den Creator aus, ein Creator sieht nur sein eigenes Profil. Sicherheitskern ist das Feld admin_notiz. Das Konzept fordert "private Admin-Notizen separat". Die Notiz wird deshalb nicht im Browser ausgeblendet, sondern gar nicht erst gesendet: Die Spaltenliste der Abfrage haengt an der Rolle (FELDER_OFFEN / FELDER_ADMIN). Dasselbe gilt fuer Plan-Start und Review-Termin. Geprueft: - In der kompletten Rohantwort an den Creator kommt der Inhalt der internen Notiz 0-mal vor - Creator auf fremdes Profil: 404 (lesend wie schreibend) - Scout auf ein Profil: 404, profil.html leitet ihn weg - Creator setzt admin_notiz selbst: wird stillschweigend ignoriert, der Inhalt bleibt unveraendert - Profil einer Nicht-Creator-Person: 404 Dabei ist ein aelterer Fehler aufgefallen: /api/ich lieferte nur Name und Rolle, nicht die eigene Nummer. Dadurch rief die Profilseite eines Creators /api/profil/undefined auf und blieb leer. Derselbe Fehler machte in der Personenverwaltung den Selbstvergleich unwirksam -- beim eigenen Eintrag erschien ein "Sperren"-Knopf, den der Server dann ablehnte. /api/ich liefert jetzt zusaetzlich die id. Im Protokoll landen nur die Feldnamen, nie die Inhalte: Im Profil stehen persoenliche Angaben, die nicht zusaetzlich im Audit-Log auftauchen sollen. |
||
|
DogFatherGit
|
232a2003dd |
Workspace: Aufgaben bearbeiten, Personenverwaltung im Browser
Aufgaben: - Bearbeiten-Dialog (Titel, Beschreibung, Prioritaet, Frist, Zuordnung). Als natives <dialog>: Fokusfang, Esc zum Schliessen und Abdunklung ohne eigenen Code. - Loeschen nur fuer Management, mit Rueckfrage und Protokolleintrag. Das Konzept will, dass Erledigtes stehen bleibt -- Loeschen ist der Ausnahmefall fuer Fehleintraege, nicht der normale Abschluss. Personen (/workspace/personen.html, nur Management): - Anlegen, Code erneuern, sperren/entsperren, Protokollansicht - Der Code wird genau einmal in der Antwort zurueckgegeben, nie gespeichert; beim Schliessen auch aus dem Dokument entfernt - Selbstschutz: niemand kann sich selbst sperren, und das letzte aktive Management laesst sich nicht sperren -- sonst kaeme niemand mehr hinein - Code fuer sich selbst tauschen nur mit ausdruecklicher Bestaetigung, weil es die eigene Sitzung sofort beendet Zwei Fehler, die beim Testen aufgefallen sind: 1. Rollenpruefung fehlte beim Ausliefern der Seiten. Ein Creator bekam personen.html mit HTTP 200 -- die Schnittstellen wiesen ihn zwar ab, das Geruest der Seite war aber sichtbar. GESCHUETZT ist jetzt eine Zuordnung Pfad -> erlaubte Rollen statt einer blossen Liste. 2. Das Protokoll nannte den falschen Verursacher. personAnlegen trug die NEU ANGELEGTE Person als person_id ein, der Eintrag las sich also so, als haette sie sich selbst angelegt. Akteur und Betroffener sind jetzt getrennt: Akteur in person_id, Betroffener im Text. Ueber die Kommandozeile angelegte Personen zeigen korrekt keinen Akteur. |
||
|
DogFatherGit
|
2eecb40537 |
Workspace: Aufgabenbrett und Dashboard-Zahlen
Erster echter Arbeitsbereich aus dem Konzept. Kanban mit offen / in Arbeit / Review / erledigt, dazu Prioritaet, Frist, Verantwortlicher und Zuordnung zu einem Creator-Bereich. Kern ist die Datentrennung, und die sitzt AUSSCHLIESSLICH im Server -- in jeder einzelnen Abfrage, an einer Stelle definiert (sichtbar()): admin sieht alles creator sieht seinen Bereich und was ihm zugewiesen ist scout sieht nur, was ihm zugewiesen ist Geprueft mit vier Testkonten: - Chef sieht 4, Luna 2, Mika 1, Sam 1 Aufgaben - Luna auf Mikas Aufgabe: 404 (nicht 403 -- sonst liesse sich durch Ausprobieren herausfinden, welche Nummern es gibt) - Luna legt Aufgabe mit creator_id=Mika an: wird still auf ihren eigenen Bereich umgebogen, Mika sieht sie nicht - Anfrage mit fremdem Origin: 403 - ohne Anmeldung: 401, ungueltiger Status/leerer Titel: 400 - Scout bekommt in der Personenliste nur sich selbst - Dashboard-Zahlen je Rolle korrekt eingegrenzt Weitere Punkte: - Texte werden im Browser nur ueber textContent gesetzt, nie innerHTML -- ein Aufgabentitel darf keine Auszeichnung einschleusen - ueberfaellig = Frist vorbei UND nicht erledigt; die Kachel faerbt sich nur, wenn wirklich etwas ansteht - erledigt_am wird gesetzt bzw. wieder geleert, wenn eine Aufgabe zurueckgeholt wird - Erledigtes verschwindet nicht, wie im Konzept gefordert |
||
|
DogFatherGit
|
6d9bad880c |
Workspace: echte Besucher-IP statt Cloudflare-Adresse
Gefunden beim Nachsehen im Protokoll nach der ersten echten Anmeldung: Jeder Eintrag trug dieselbe IP 172.69.220.140 -- eine Cloudflare-Adresse. Ursache: Die Kette ist Besucher -> Cloudflare -> Caddy -> Express, aber `trust proxy` steht auf 1. Express nimmt daher den letzten Eintrag aus X-Forwarded-For, und das ist Cloudflare. Auswirkung war nicht nur ein unbrauchbares Protokoll, sondern vor allem: ALLE Nutzer teilten sich einen einzigen Sperr-Zaehler. Beim ersten Anmelden waren nach zwei Tippfehlern plus drei Testversuchen bereits 5 von 8 verbraucht -- drei weitere und der Zugang waere fuer alle gesperrt gewesen. Jetzt wird CF-Connecting-IP ausgewertet (setzt Cloudflare bei jeder Anfrage selbst, vom Besucher nicht faelschbar), mit Rueckfall auf die Peer-Adresse. `trust proxy` bleibt bewusst unangetastet, damit die Aenderung nur /workspace betrifft und nicht die ganze Website. Geprueft: 8 Fehlversuche von IP A sperren IP A (429), IP B bekommt weiterhin 401 und kann sich normal anmelden (200). Ausserdem: Spaltenbreite im Protokoll-Ausdruck korrigiert -- bei `anmeldung_fehlgeschlagen` (genau 24 Zeichen) klebte die Rolle am Namen. |
||
|
DogFatherGit
|
f3a55af80f |
Creator Workspace: Anmeldung, Sitzungen und Audit-Log
Erster funktionierender Login fuer /workspace. Bewusst OHNE neue Abhaengigkeiten: Node 24 bringt node:sqlite mit, Hashing und Zufall kommen aus node:crypto. Nichts zu kompilieren, keine fremde Lieferkette an einer Stelle, an der es um Zugangsdaten geht. Sicherheit: - Codes liegen nur als scrypt-Hash (N=32768) mit eigenem Salt in der DB - Vergleich in konstanter Zeit (timingSafeEqual) - Sitzungstoken 32 Byte Zufall, in der DB nur als SHA-256 - Cookie httpOnly, SameSite=lax, Path=/workspace, secure abhaengig von req.secure (live immer an, nur der lokale http-Test kommt ohne aus) - Sperre nach 8 Fehlversuchen je IP fuer 10 Minuten -- danach ist auch der richtige Code blockiert (geprueft) - gleiche Fehlermeldung bei falscher Rolle und falschem Code - Audit-Log fuer Anmeldung, Fehlversuch, Sperre, Abmeldung, Codewechsel Die Datenbank liegt AUSSERHALB des Repos (../workspace-daten/): sonst waere sie ueber express.static aus dem Netz erreichbar, und ein git pull wuerde Nutzdaten anfassen. workspace.js kann die Website nicht mitreissen: node:sqlite wird erst bei Bedarf per createRequire geladen, jede Route faengt ihre Fehler selbst ab. Faellt die DB aus, antwortet nur /workspace/api/* mit 503. Codes werden ausschliesslich auf der Kommandozeile erzeugt (server/workspace-code.js) und dort einmal angezeigt -- nie in Git. Ausserdem: start.html als geschuetzte Seite nach dem Anmelden. Der Schutz sitzt serverseitig vor express.static, nicht nur im Browser. |