7be488e0caa3cd53008dcd8e5f6db2aa746bdd9b
7
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
7be488e0ca |
Ein Zugang, den ausser DogFather niemand bemerkt
Aus dem Anforderungsdokument (Master-Blueprint V3.0) fehlte die Rolle
"Modi" ganz -- es gab nur spicy, admin, manager, scout, creator. Filipes
Bedingung dazu: "dass die keine neue eingangs kachel bekommen wie spicy
dogfather und so sondern einfach einen code. damit die von der workspace
auch nicht mal sehen dass die modis von mir einen eigenen zugang haben."
DER EINGANG. Es gibt keine sechste Kachel und es laesst sich auch keine
erzwingen: Wer von aussen `rolle: "modi"` schickt, bekommt wortgleich
dieselbe Antwort wie bei einer erfundenen Rolle. Ein Modi tippt auf
irgendeine vorhandene Kachel -- welche, ist gleichgueltig -- und gibt
seinen Code ein. Der Code allein entscheidet.
Moeglich macht das eine neue Spalte `code_kennung`: ein HMAC ueber den
Code, in Mikrosekunden nachgeschlagen. Zwei naheliegende Wege wurden
verworfen, weil man sie finden kann: ein Merkmal im Code ("M-...") waere
ein sichtbares Kennzeichen auf dem Zettel des Modis, eine eigene Adresse
(/modi.html) eine Seite, die man aufrufen kann. Der Suchschluessel steht
VOR dem gewohnten Weg, nicht dahinter -- ein Rueckfall nach einem
Fehlversuch haette genau die Fehlversuche verlaengert, und daran waere
es zu erkennen gewesen.
Unbedenklich, weil nachgemessen: Ein Code hat 16 Zeichen aus einem
32er-Alphabet, also 80 Bit Zufall. Der Suchschluessel sagt ausserdem nur,
WEN man pruefen soll -- ob der Code stimmt, sagt weiterhin scrypt.
DIE UNSICHTBARKEIT sitzt in verborgeneIds(), also an derselben einen
Stelle wie die Regel fuer den zweiten Admin-Zugang, und nicht in den
rund 170 Abfragen, die Personen lesen. Sie haengt dabei an der ROLLE und
nicht an einer Nummer -- die Schwachstelle, die im Kommentar der alten
Regel offen dasteht (wird Zugang 1 geloescht, rueckt der naechste nach),
kann einer Rolle nicht passieren.
Nach Filipes Entscheidungen: Die Modis sehen sich untereinander (Kapitel
7.2 des Dokuments), VanVan sieht sie mit (Kapitel 3, sie traegt dieselbe
Rolle), Codes gibt Filipe selbst weiter -- kein Einladelink, der in einem
Verlauf landen kann.
ZWEIMAL WAERE DAS WORT "MODI" BEINAHE IN EINER DATEI GELANDET, DIE JEDER
BEKOMMT: in den Rollenlisten von start.js und personen.js. Ein Blick in
den Quelltext haette genuegt. Der Anzeigename kommt jetzt aus
/workspace/api/ich (beschreibt immer nur den Angemeldeten selbst), die
Rollenauswahl aus der Antwort des Servers und nur an die DogFather-Rolle.
GEPRUEFT mit pruef-modi-verborgen.mjs (45 Pruefungen): fuenf Kacheln
fuehren mit dem Modi-Code hinein, ein Manager-Code auf fremder Kachel
weiterhin nicht (sonst waere nebenbei die Rollenpruefung abgeschafft),
und ueber fuenf Schnittstellen sieht ausser DogFather, VanVan und den
Modis niemand etwas -- auch nicht die ZAHL daneben.
Die Gegenprobe steht bewusst ganz unten, weil sie eine Person absichtlich
aus der Regel aushaengt: Weiter oben haette sie jeden Abschnitt danach
verfaelscht. Beim ersten Anlauf stand sie in der Mitte, und prompt tauchte
die Person in einer spaeteren Managerliste auf.
Abschnitt 5 prueft den Weg durch die Anwendung selbst (DogFather legt an,
der Modi meldet sich an). Die Abschnitte davor tragen die Personen von
Hand ein und rechnen den Suchschluessel selbst aus -- damit waere NICHT
bewiesen, dass personAnlegen() ihn im Betrieb schreibt. Ohne ihn kaeme
kein einziger echter Modi herein, und oben waere trotzdem alles gruen.
Die Umstellung der Rollenliste in der Datenbank steht ab jetzt einmal in
rollenRegelUmstellen() statt zum dritten Mal abgeschrieben. Jede Abschrift
waere eine Gelegenheit, eine der vier Absicherungen zu vergessen: Sicherung
vorher, Zaehlung innerhalb der Transaktion, Spaltenliste aus der Tabelle,
Pruefung auf verwaiste Verweise danach.
pruef-personen-formular erwartet jetzt sechs Rollen statt fuenf und prueft
die Liste statt nur die Anzahl -- sechs Karten koennten auch fuenf richtige
und eine doppelte sein. Dass die sechste dort auftaucht, ist gleichzeitig
der Nachweis, dass der Weg ueber den Server funktioniert.
Unveraendert bestanden: pruef-spicy (60), pruef-rollen (97),
pruef-verborgen, pruef-personen-liste, pruef-css-klassen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
88e2b5cd5d |
Der Wecker: das Zeitfeld ging auf -- nur ausserhalb des Bildschirms
Filipe: "wenn ich am handy auf den wecker drücke dan sieht man nichts."
Er hat woertlich recht. Der Knopf tut, was er soll, und das Zeitfeld
klappt auf -- es steht nur nicht im Bild. Aufgeklappt gemessen, fuenf
Breiten:
320 px Feld bei -127 .. -8 komplett draussen
360 px Feld bei -107 .. 12
390 px Feld bei -92 .. 27
412 px Feld bei -81 .. 38
430 px Feld bei -72 .. 47
DER GRUND IST EIN ANKER, DER GEWANDERT IST. `.tagesruf__feld` steht mit
`right: 56px` da -- "56 px nach links vom Knopf". Am Rechner ist das
richtig: Dort sitzt der Knopf am rechten Rand einer breiten Kachel, und
links davon liegt die Luecke zwischen Text und Uhr. Auf dem Handy wird
derselbe Knopf aus dem Fluss genommen und neben die zentrierte Uhr
gehaengt -- er steht dann ganz LINKS, und 56 px weiter links ist kein
Raum mehr, sondern der Bildschirmrand.
Der Abstand stimmte also noch, der Bezugspunkt nicht mehr. Dieselbe
Sorte Fehler wie die feste Umbruchschwelle und die 62 px Kopfhoehe: eine
Zahl, die fuer eine Anordnung ausgerechnet wurde und in der zweiten
still falsch ist.
Es oeffnet jetzt auf dem Handy nach RECHTS statt nach links -- in die
Richtung, in der dort der Platz ist. Das ist keine zweite Zahl, sondern
dieselbe Regel andersherum ("ins Freie oeffnen"). Der linke Rand des
Knopfes ist nie kleiner als 0, das Feld 119 px breit, der schmalste
Bildschirm 320 -- damit liegt es auf jeder Breite im Bild, ohne dass
eine Schwelle stimmen muss. `max-width: calc(100vw - 24px)` als
Sicherung, falls das Feld je breiter wird.
Die Regel steht in heim.css direkt neben der Regel, die den Knopf
verschiebt. Sie gehoeren zusammen: Wer den Anker bewegt, sieht die
Folge in derselben Medienabfrage.
GEPRUEFT WIRD ES JETZT AUCH (pruef-handy, 99 -> 115 Pruefungen). Das
Feld wird dafuer aufgeklappt gemessen, nicht zugeklappt -- ein
verstecktes Feld hat keine brauchbare Lage, und genau die ist die
Frage. Gegenprobe ist die Messung von vorher: Mit demselben Messmittel
lag das Feld bei -92..27, die Bedingung waere rot gewesen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
6c48579f66 |
Die Kopfleiste bleibt auch in einer fremden Sicht in EINER Reihe
Filipe, mit Bildschirmfoto aus der installierten App: "es ist noch nicht alles in einer zeile und irgendwie funktionieren nicht alle knoepfe." DER GRUND WAR NICHT DIE BREITE SEINES GERAETS, SONDERN DER ZUSTAND. In der eigenen Sicht klappt der Umschalter auf 36 px zusammen; sobald man die Sicht einer anderen Person uebernimmt, stand der Name darin und er war 152 px breit. Gemessen waren es dann zwei Zeilen bei 320, 360, 390, 412 UND 430 px -- ausnahmslos. Auf seinem Bild stand "Miesmus..." im Umschalter und der goldene Rahmen um die Seite: er war in einer fremden Sicht. MEINE PRUEFUNGEN HABEN DEN FALSCHEN ZUSTAND GEMESSEN. pruef-handy lief ausschliesslich in der eigenen Sicht und war deshalb gruen, waehrend es beim Nutzer zweizeilig war. Ein gruener Haken sagt nur, dass die Bedingung erfuellt war -- nicht, dass sie den Zustand geprueft hat, in dem der Nutzer ist. Die Pruefung wechselt jetzt selbst in eine fremde Sicht (92 -> 99 Pruefungen). WAS SICH AENDERT - Auf dem Handy ist der Umschalter auch in fremder Sicht ein Zeichenknopf: Auge + Anfangsbuchstabe, 46-48 statt 152 px, in der ROLLENFARBE der Person, deren Sicht laeuft. Die Farbe kommt aus `data-rolle` -- dieselbe Zuordnung, die gate.css ohnehin hat, keine zweite Farbliste. - Der volle Name wandert in ein Band unter die Leiste, zusammen mit "Zurueck zu meiner Sicht" als ganzem Satz statt als 28-px-Kreuz. Er steht dort GANZ statt als "Miesmus...". Am Rechner bleibt alles wie bisher; dort ist Platz. - Der Rahmen um die Seite nimmt dieselbe Farbe an. Man sieht damit nicht nur DASS eine fremde Sicht laeuft, sondern WESSEN. - Das `:not([data-fremd="ja"])` faellt an beiden Stellen weg. Es war der ganze Fehler: eine Regel, die den wichtigeren Fall ausnahm. UND DER BLOCK FUER SCHMALE GERAETE STAND AN DER FALSCHEN STELLE Er galt bis 340 px und stand 3600 Zeilen VOR dem 560er-Block -- bei gleicher Spezifitaet verliert er damit. Gewirkt hat er nur, weil sein Selektor zufaellig ein `:not()` trug. Jetzt steht er direkt hinter dem 560er und gilt bis 400 px (34 px je Knopf, 4 px Abstand). Damit bleibt auch bei 360 px auf den UNTERSEITEN alles in einer Reihe -- dort stehen zusaetzlich der Zurueck-Knopf und die Glocke. Gemessen nach dem Umbau, eigene und fremde Sicht, Start- und Unterseite: 360, 390, 412 und 430 px alle einzeilig. Offen bleibt 320 px (iPhone SE 1. Generation bzw. Anzeige-Zoom) -- dort passt es ohne das Weglassen einer Funktion nicht, das ist eine Entscheidung und kein Handgriff. DER SICHERE BEREICH (auf Filipes Zusage) Jede der 20 Seiten sagt `viewport-fit=cover`, aber im ganzen Workspace stand kein einziges `env(safe-area-inset-*)`. Sein Android ist NICHT betroffen (im Bildschirmfoto nachgesehen), ein iPhone waere es: Von einem 36-px-Knopf blieben unter einer 47 px hohen Statusleiste rechnerisch 5 px zum Antippen. Einmal zentral benannt (gate.css) und an den vier Stellen angewandt, wo etwas am Rand klebt: Kopfleiste (oben und seitlich), Inhalt (seitlich und unten), Speichern-Leiste im Profil, Chat-Eingabe. Auf Geraeten ohne Aussparung sind alle vier Werte 0. Nebenbei: chat.js misst die Hoehe ueber der Chatflaeche jetzt einschliesslich des Bandes -- sonst stuende das Eingabefeld genau um dessen Hoehe unter dem Bildschirmrand. Derselbe Fehler wie mit den festen 62 px, nur mit einem anderen Element. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
d0ac8ee8d1 |
Das Logo: aus dem Fleck wird wieder ein Hund
Filipe: "kannst du bitte das logo wenn man es installiert auf pc oder handy und oben rechts in der leiste noch perfektionnieren." Beide Stellen hatten denselben Fehler, und er war derselbe wie an mehreren Stellen davor: Der Husky lag als MASKE auf einer Farbflaeche. Von einer Maske zaehlt nur der Alphakanal, und die Vorlage ist rundum freigestellt -- uebrig blieb eine geschlossene Flaeche in Hundeform. Kein Auge, keine Schnauze, kein Ohrinneres. Ein Fleck. Jetzt liegt an beiden Stellen dieselbe Zeichnung im Mischmodus "screen" ueber einer stahlblauen Silhouette: Schwarz laesst das Fell dunkel, Weiss hebt Gesicht, Ohren und Auge heraus. Gleiche Farben, gleicher Daempfer (.88) -- ein Zeichen, zwei Orte. App-Symbol ausserdem: - Die Chili lief mit ihrem Stiel quer ueber den Fang. Sie ist jetzt gespiegelt, kleiner und liegt hinter dem Hals. - Der Hals endete in einer geraden Kante (die Vorlage ist unten angeschnitten). Eine zweite Maske blendet ihn aus, statt ihn abzuschneiden. - Der Grund war matschig: Rot und Blau trafen sich diagonal genau dort, wo der Kopf steht. Jetzt kaltes Licht oben, warmes unten. - Unter 64 px faellt die Gesichtszeichnung weg, die Chili aber NICHT -- klein erkennt man ein Zeichen zuerst an der Farbe. - Alle Masse haengen an einer Zahl (Groesse der Gruppe), nicht an sechs. Kopfleiste ausserdem: - Die Chili links hatte einen BLAUEN Schein -- aus der Zeit, als dort der Husky stand. Der Schein ist nie mitgewandert. Jetzt warm. - `filter` ersetzt, es ergaenzt nicht: Beim Ueberfahren wurde der Schein geloescht und das Zeichen dabei flacher statt heller. Behoben. Damit die Aenderung auch ankommt: - Der Stempel gilt jetzt auch fuer die App-Symbole und fuer das Manifest. Bilder werden einen Tag zwischengespeichert, das Symbol der INSTALLIERTEN App gar nicht neu geholt -- ohne Stempel haette niemand das neue Zeichen gesehen. - pruef-zwischenspeicher prueft das (18 -> 21 Pruefungen). Werkzeuge: - tools/ausschnitt.mjs (neu): schneidet aus einem Bildschirmfoto ein Stueck heraus und vergroessert die PNG-Datei. Noetig, weil eine Vergroesserung per CSS-transform den Browser NEU rechnen laesst -- ich habe damit 264 px beurteilt und geglaubt, es seien 22, und daraus den falschen Schluss gezogen, ein Gesicht trage bei 22 px nicht. - tools/ansicht.mjs: AUSSCHNITT=<selektor> nimmt nur ein Element auf. - workspace-symbol.mjs: SYMBOL_ZIEL lenkt die Ausgabe um (Entwuerfe ansehen, ohne die sechs echten Dateien zu ueberschreiben), und zwei Gegenproben pruefen jetzt, dass Gesicht und Chili wirklich zu sehen sind -- die alte Pruefung sagte nur "es steht etwas drauf" und haette den Fleck anstandslos durchgewunken. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
25f35c1290 |
Die App-Leiste wird dunkel, und der Titel sagt nicht mehr alles doppelt
Filipe, mit Bildschirmfoto der installierten App: "die barre oben wenn ich die seite als app installiere ist blau, sie soll der seite angepasst werden auch der text oben soll jetzt der seite unten angepasst werden". DIE LEISTE stand auf `theme-color: #0674b9` -- ein kraeftiges Blau. In einem Browserfenster faellt das nicht auf, weil man die Angabe dort gar nicht sieht. Als installierte App ist sie die FENSTERLEISTE, und damit sass ueber einer durchweg dunklen Seite ein leuchtend blauer Balken. Jetzt derselbe Ton wie die Kopfleiste darunter (#06090f): Leiste und Seite sind eine Flaeche statt zweier. Geaendert auf allen 19 Seiten und im Manifest -- steht die Farbe nur an einer Stelle, blitzt beim Wechsel auf eine andere Seite kurz die alte auf. DER TITEL stand doppelt in der Leiste, und beide Haelften sagten dasselbe: "Creator Workspace — Dogfather Universe" (aus dem Manifest) plus "Dogfather Universe · Creator Workspace · Anmeldung" (aus <title>). Der Markenname kam zweimal, der Anwendungsname zweimal, und was die Seite tatsaechlich zeigt, stand ganz hinten. Jetzt steht vorn, WO man ist, und hinten die Marke: Anmeldung · Spicy & Dogi Kalender · Spicy & Dogi Personen & Zugaenge · Spicy & Dogi "Creator Workspace" faellt dabei aus den Unterseiten heraus -- es steht im Manifest und damit ohnehin im Fenstertitel. Neunzehn Titel, alle nach demselben Muster; vorher folgten sie zwei verschiedenen. Das Manifest heisst jetzt "Creator Workspace — Spicy & Dogi" und der Ladehintergrund #0a121e statt #151e2a: Er ist das Erste, was beim Starten der App zu sehen ist, und war heller als die Seite, die danach kommt -- ein Aufblitzen bei jedem Start. pruef-start-ansicht EXIT=0 (140), pruef-workspace-seiten EXIT=0 (32). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
5ef3a13615 |
Jede App der Domain bekommt eine eigene Fensterfarbe
Beim Installieren als App sahen alle Dienste gleich aus. Nicht wegen der Symbole - die sind seit heute Mittag gut unterscheidbar - sondern wegen der Farbe: zwoelf von vierzehn trugen dasselbe Fast-Schwarz (#05070b, #05070d, #0a0910, #0b0d10, #0d0817, #0e0a16). Das ist die theme_color, also am PC die Titelleiste des App-Fensters und am Handy die Statusleiste. Neu, je App eine Farbe, abgeleitet vom eigenen Symbol: Hauptseite #065f76 Petrol (Symbol stahlblau) DogiCrew-Verwaltung #8d4125 Kupfer (Symbol orange) Webdesign #564e95 Violett (Symbol lila) Kundenportal #924985 Magenta (Symbol pink) WD-Verwaltung #b44f5e Rose (Symbol rot) Creator Workspace #0674b9 Blau (Symbol nachtblau) Nextcloud (#17a5a6) bleibt unveraendert - als einzige hob sie sich schon ab. WICHTIG war, beide Stellen zu aendern: Die meta-Angabe im HTML ueberschreibt die theme_color aus dem Manifest. Nur das Manifest zu aendern haette gar nichts bewirkt. Der background_color (Startbildschirm beim Oeffnen) bleibt bewusst sehr dunkel, nur leicht in Richtung der App-Farbe getoent - kraeftig ist nur die schmale Leiste, damit nichts grossflaechig aufblitzt (Vorgabe augenschonend). Wie die Farben entstanden sind: Zwei Entwuerfe fielen bei der eigenen Pruefung durch. In HSL gerechnet lagen Workspace und Webdesign bei einem Farbabstand von 12.6 statt der noetigen 25 - auf dem Papier 30 Grad auseinander, fuers Auge dasselbe Blauviolett. Auch der zweite Versuch scheiterte (Hauptseite zu nah an Nextclouds Tuerkis, 19.1). Neun Farben bei gleicher Helligkeit passen schlicht nicht mit genug Abstand auf den Farbkreis. Erst mit der Helligkeit als dritter Dimension und einem Optimierer, der den KLEINSTEN Abstand im Satz maximiert, kam ein Satz heraus, der haelt: kleinster Abstand 25.5. Geprueft: 68 Farbpruefungen (weisse Schrift ueberall lesbar 5.0-7.2:1, keine blendet, jede hebt sich vom bisherigen Schwarz ab, alle Paare >= 25 Delta E) und 101 Browserpruefungen ueber 16 Seiten (Manifest und meta stimmen ueberein, genau eine theme-color je Seite, Symbole vorhanden) - alle gruen, Gegenprobe schlaegt an. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
51c3d4402b |
Audit des Creator Workspace, App-Symbole fuer alle Apps der Domain
AUDIT (Auftrag: vollstaendiger Durchgang, Fehler direkt beheben)
Ausgangslage waren 40 Pruefungen mit 1616 Einzelpunkten, alle gruen.
Acht neue Pruefungen kamen dazu; sie haben gefunden, was die alten nicht
sehen konnten.
Der schwerste Fund: Die Zugangsschranke verglich req.path EXAKT gegen
eine Liste. Express raeumt Punkt-Segmente selbst weg, mehrfache
Schraegstriche aber nicht. Damit kam //workspace/start.html OHNE
Anmeldung mit HTTP 200, und ein Creator bekam ueber
/workspace//personen.html die Verwaltungsseite. Die DATEN waren nie
betroffen (nachgemessen: 404 bzw. 401). Behoben durch Normalisierung
UND eine Umkehr der Logik -- jetzt ist jede .html geschuetzt ausser der
Anmeldeseite, statt nur die in der Liste. Eine vergessene neue Seite
steht damit nicht mehr versehentlich offen.
Weiter behoben:
* Kaputter/abgebrochener Rumpf ergab 500 in HTML statt 400 in JSON --
die Oberflaeche ruft ueberall a.json() und lief in einen zweiten
Fehler; der Knopf hing ohne Meldung.
* POST /zustand/sichern war der einzige von 60 schreibenden Wegen
ohne Herkunftspruefung.
* workspace-sicherung.js gab interne Pfade in Fehlermeldungen nach
aussen; alle 23 anderen Module antworten neutral.
* admin_notiz war als einziges von 14 Feldern ohne <label>.
* Der aktive Filter hatte keinen sichtbaren Fokus (CSS-Spezifitaet
0,3,0 schlug 0,2,0) -- genau der Knopf, auf dem man steht.
* h1 -> h3 ohne Zwischenstufe auf zwei Seiten.
* HSTS ging auch ueber http mit (RFC 6797, 7.2 verbietet das).
* upgrade-insecure-requests galt auch auf 127.0.0.1 -- dadurch war
WebKit/Safari ueberhaupt nicht pruefbar, also der Browser, den
jedes iPhone benutzt.
* pruef-grosscheck las readdirSync(".") und pruefte aus server/
gestartet NULL oeffentliche Seiten -- meldete aber "ok".
Neue Pruefungen: struktur, schranke, haerte, alle-wege,
barrierefrei-workspace, breiten, tempo-workspace, browser.
Jede mit Gegenprobe und mit der geprueften Anzahl in der Bedingung.
Vier davon sind beim Bauen durch die eigene Gegenprobe aufgeflogen und
haetten sonst dauerhaft gruen gemeldet, ohne etwas zu messen.
APP-SYMBOLE (Wunsch: alle Apps der Domain, jede anders, ausser
safeaddress)
Zehn Apps, zehn Stile, zehn in OKLCH gerechnete Farben. Zusammen haelt
sie dasselbe Logo, dieselbe Eckenrundung und eine gemeinsame gedeckte
Farbreihe. Beim Bauen wird gemessen, ob sich das Logo vom Grund abhebt
(19 bis 58 Helligkeitsstufen).
Dabei aufgefallen: Das Kundenportal hatte kein eigenes Manifest und
trug Namen und Symbol der Webdesign-Seite. Der Workspace hatte gar
keins und war als App nicht installierbar. Beide haben jetzt eins.
Geaendert wurde AUSSCHLIESSLICH das Symbol. Ein Zwischenstand hatte
auch die Themenfarben gesetzt; das war mehr als bestellt und wurde
zurueckgenommen.
Werkzeuge: tools/logo-freistellen.mjs, tools/app-symbole.mjs,
tools/app-symbole-einbinden.mjs -- alles im Browser gerechnet, kein
Bildprogramm, keine neue Abhaengigkeit.
Gitea und Nextcloud sind bereits live und nachgeprueft.
Co-Authored-By: Claude Opus 5 <[email protected]>
|