Vier Faelle, die genau die Fehler wiederfinden wuerden, um die es in 2.7.1
ging:
- whoami nennt Bindung und Rechte, und zwar dieselben, die provisioniert
wurden
- whoami gibt den Klartextwert des Tokens nicht heraus. Eine Auskunft ueber
ein Token darf das Token nicht weiterreichen
- whoami ohne Token antwortet 401
- Health meldet dieselbe Fassung, die changelog.json fuehrt. Das ist der
Fall, der #346 nicht wiederkommen laesst: Ein fester Wert in der
Konfiguration faellt sonst niemandem auf, weil die Datei gitignored ist
Ausserdem: Wird der Shared Key an whoami geschickt, sagt der Endpunkt das
jetzt (not_a_token) statt "Token unbekannt". Der Shared Key ist kein Token -
er hat weder Bindung noch Rechteliste, und ohne den Hinweis sucht der
Aufrufer den Fehler bei seinem Token.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der erste Durchlauf der Testinstanz hat neun Bugs zutage gefoerdert, und fast
alle waren dieselbe Sorte Fehler: eine Auskunft, die nicht stimmte.
Am folgenreichsten die Fassung. config/config.php fuehrte app.version als feste
Zeichenkette und stand seit 2.0.0 darauf, waehrend 2.7.0 lief - unbemerkt, weil
die Datei gitignored ist und in keinem Diff auftaucht. Zwei gemeldete Bugs sind
daran fehldiagnostiziert worden ("der Server ist zu alt"). src/bootstrap.php
leitet die Fassung jetzt aus "current" in public/docs/changelog.json ab.
Im Einzelnen:
- #346 Fassung aus dem Changelog statt aus der Konfiguration
- #60 /api/health ueberlebt eine leere Datenbank: eigener Check "schema",
healthy=false mit Begruendung statt HTTP 500
- #54 dc-testkit doctor prueft Mindestfassung (semantisch) und Rechte, statt
sie nur anzuzeigen - dafuer neu: GET /api/tokens/v1/whoami
- #53 dc-testkit.sh unter /testkit/ erreichbar (Route fehlte, der
dokumentierte Bezugsweg hat nie funktioniert) und mit LF ausgeliefert
(deploy.py/deploy_dev.py entfernen CR bei .sh/.bash beim Upload)
- #288 Filter und Formulare werfen nicht mehr aufs Dashboard zurueck: die
offene Ansicht wandert bei GET als "view" in den Query-String, und die
Filter loesen ueber requestSubmit() aus - form.submit() erzeugt kein
submit-Ereignis, weshalb der zentrale Zuhoerer dort nie lief
- #347 /api/bugtracker/v1/roadmap auch ohne .php erreichbar
- #55 Fassungshinweis in TESTUMGEBUNG.md 4.6 (serverseitig war das mit 2.6.0
bereits behoben)
Nicht geprueft: php -l. Auf dem Arbeitsplatz ist kein PHP installiert; die
Abnahme laeuft ueber die Testinstanz.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
