669b165785fee6d16f60c61dd54e91ed25ecd95d
25
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Deploymentcenter BotandClaude Opus 5
|
c9c821a44a |
fix(webui): Ansichtsrettung suchte am falschen Ort, Suche findet Nummern
#288 war mit dem Transport allein nicht behoben. Die Ansichtsrettung fragte dokumentweit nach der offenen Unteransicht: document.querySelector('.subtab-content.active') Im Markup tragen aber ACHT Unteransichten diese Klasse - jedes Modul hat seine eigene Startansicht, und switchMainTab() raeumt nur innerhalb des Moduls auf, das es oeffnet. Zurueck kam deshalb immer die erste in Dokumentreihenfolge (sub-projects-list), voellig unabhaengig davon, was gerade sichtbar war. Wer im Bugtracker filterte, waere also auf der Projektverwaltung gelandet. Dass die Rettung fuer POST-Formulare zu funktionieren schien, lag an den wenigen, die ihren Anker fest in der action stehen haben. Gesucht wird jetzt erst das aktive Modul und darin die Unteransicht. Zusaetzlich tragen die drei Filterformulare das Feld "view" fest im Markup. Dort ist ohne Zweifel bekannt, wo sie stehen - das haengt an keiner DOM-Abfrage mehr. Und restoreViewFromHash() faellt bei einer unbekannten Unteransicht auf das Modul zurueck, statt wortlos im Dashboard zu landen. Nachgewiesen an einer DOM-Probe, die die Modulstruktur aus index.php nachbaut und die echten Funktionen darauf laufen laesst: alte Fassung -> tab-projects, neue Fassung -> sub-bugtracker-items. Ausserdem, aus derselben Sitzung gemeldet: Die Suche findet Eintraege jetzt ueber ihre Nummer. Sie ist das, was ueberall zitiert wird, und stand in keiner der durchsuchten Spalten - "288" lief ins Leere. "288" findet jetzt das Item mit dieser Nummer und alles, was die Zahl im Text hat; "#288" ausschliesslich dieses eine. Gilt fuer Bugtracker, Fehler-Stream und den Parameter search der API, der bei der Gelegenheit auch in die OpenAPI-Beschreibung gekommen ist. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Deploymentcenter BotandClaude Opus 5
|
3b56839a1e |
fix(2.7.1): Auskuenfte, die stimmen - Fassung, Health, doctor, Ansicht
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>
|
||
|
Deploymentcenter BotandClaude Opus 5
|
57aa0bc5be |
feat(tokens): Master-Tokens nachtraeglich bearbeiten
Bisher erzwang jede Korrektur ein neues Token: ein Schreibfehler im Namen, ein
falsch gewaehlter Identitaetstyp, ein nachtraeglich gebrauchtes Recht. Das ist
nicht nur laestig, sondern gefaehrlich - der neue Wert muss auf alle Maschinen
verteilt werden, und am Ende laeuft das alte weiter, weil eine vergessen wurde.
AENDERBAR ist alles ausser dem Tokenwert selbst, der Nummer, dem Typ und dem
Anlagedatum: Name, Identitaetstyp, freie Identitaet, Projekt, Lizenzschluessel,
Umgebung, Ablaufdatum und die Rechte.
Der Wert bleibt unberuehrt, weil er es muss - er liegt nur als Hash vor und
steht auf fremden Maschinen. Ein "geaenderter" Wert waere ein neues Token mit
alter Nummer. Genau diese Zusage haelt ein eigener Testfall fest: derselbe rohe
Token muss nach der Aenderung weiter funktionieren.
- TokenManager::updateMasterToken() mit zwei Schranken: leerer Name und
leere Rechteliste werden abgewiesen. Ein Token ohne Rechte sieht gueltig
aus und laesst jeden Aufruf mit "unauthorized" scheitern, ohne dass der
Grund sichtbar waere.
- Was sich geaendert hat, geht ins Log. Eine stille Rechteaenderung an einem
Token ist genau das, was man spaeter rekonstruieren will.
- Dialog in der Token-Verwaltung, erreichbar ueber den Stift in der Zeile.
Zeigt Nummer und Hinweis, dass der Wert unveraendert bleibt.
- Haengen Sub-Tokens daran, sagt der Dialog, dass eine Einschraenkung NICHT
rueckwirkend auf sie durchschlaegt - sie haben ihre Rechte beim Ausstellen
bekommen. Wer die Kinder beschneiden will, widerruft und stellt neu aus.
$scopeChoices ist aus dem Anlegeformular in den Datenteil gewandert. Beide
Formulare lesen jetzt dieselbe Liste - eine an zwei Stellen gefuehrte Liste
haette genau den Fehler wiederholt, der eben erst behoben wurde: Die
Supervisor-Rechte fehlten monatelang im Formular, obwohl TokenManager sie kennt.
Testlauf 136 Faelle. Da die Bearbeitung bewusst keine API hat - ein Token soll
seine eigenen Rechte nicht erweitern koennen - fuehrt der Weg dorthin ueber
testctl.php?action=update_master_token, wie schon beim Werkbank-Token.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Deploymentcenter BotandClaude Opus 5
|
c9bad697e5 |
feat(roadmap): Roadmap des Deploymentcenters uebernommen (I9)
61 Eintraege aus docs/ROADMAP.md stehen jetzt als Items im Deploymentcenter:
17 offen, 24 erledigt, 7 zurueckgestellt, 13 verworfen. Keine Waisen, jedes
Item mit doc_anchor. Der Abgleich laeuft ohne Befund durch.
Die Datei behaelt, was eine Tabellenzelle nicht traegt: die Begruendungen.
Der Zustand steht zwischen dc:roadmap-Markern und wird erzeugt.
- scripts/roadmap_import.py: wertet die Datei aus und uebertraegt sie.
Wiederholbar ueber client_ref, legt fehlende Themenbereiche an, wartet
bei Drosselung. Die Prioritaet liest es aus dem Abschnitt "Als
Naechstes" - solange die Datei die Quelle ist, soll auch die Prioritaet
von dort kommen.
- docs/ROADMAP.md: Statustabellen raus, erzeugter Block rein,
21 Ueberschriften und 14 Querverweise auf Item-Nummern umgestellt,
Abschnitt H mit Item-Nummern versehen.
WAS DIE UEBERNAHME ZUTAGE FOERDERTE
- G8 war zweimal vergeben: einmal offen, einmal erledigt. Genau die
Kollision handvergebener Kennungen, gegen die der Entwurf argumentiert.
Beide sind eigene Items.
- Bereich H fehlte in roadmap_epics - Migration 016 hatte nur A-G und I
gesetzt. Die Waisenerkennung meldete es. Das Importskript legt fehlende
Bereiche jetzt an, ueberschreibt aber keine vorhandenen: Ein
Uebernahmeskript darf anlegen, kuratierte Angaben nicht ueberschreiben.
- "Item #42" stand als erfundenes Beispiel im Rueckkanal-Absatz - und #42
gibt es wirklich, in predictalytics. Der Abgleich hat es gemeldet, ein
Mensch haette es nie bemerkt.
- Vier Marker waren veraltet (E1, E2, I8, D1).
BEHOBEN: spliceBlock() zerstoerte Dateien, die den Marker erwaehnen
strpos() nahm die erste Fundstelle von "<!-- dc:roadmap". Erwaehnt eine Datei
den Marker im Fliesstext - und die Einleitung einer ordentlichen Roadmap tut
genau das - setzte der Splice dort an und ueberschrieb den halben Dateikopf.
check() klammerte aus demselben Grund Prosa aus statt des Blocks.
Es trifft also ausgerechnet die Dateien, die das Verfahren beschreiben. Der
echte Block wird jetzt am Zeilenanfang samt "stand=" erkannt; das Blockende
wird ab dem Anfang gesucht, nicht ab Dateibeginn.
BEHOBEN: IPv6-Erkennung im Testlauf war launisch
erreichbar() prueft seit jeher IPv6 mit einem blossen connect(). Auf dieser
Strecke gelingt der Verbindungsaufbau zeitweise, waehrend danach nichts mehr
fliesst - der Lauf blieb dann auf IPv6 und jede Anfrage lief 21 Sekunden in
einen Timeout. Weil es launisch war, sah es mal nach einem Haenger und mal
nach einem sauberen Lauf aus. Geprueft wird jetzt bis zur Antwort:
TLS-Handschlag und ein HTTP-HEAD.
WebUI: Verweise im Inhalt hatten keine Farbregel und erschienen im
Browservorgabeblau auf schwarzem Grund. Der Bereichsverweis der Roadmap
springt ausserdem auf die Liste statt auf die Uebersicht - dort wirkt der
Filter, den er setzt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Deploymentcenter BotandClaude Opus 5
|
8b6d6a307e |
feat(mcp): Ressourcen und Prompts fuer Claude Desktop, zwei Befunde behoben
MCP-ADAPTER 1.1
Werkzeuge ruft ein Modell von sich aus auf - Ressourcen und Prompts waehlt ein
MENSCH. In Claude Desktop sind das Anhang-Menue und Schraegstrich-Befehle, und
genau die fehlten.
- Vier Ressourcen: dc://roadmap (fertiger Markdown-Block),
dc://naechste-schritte, dc://projekte, dc://befunde.
- Vier Prompts: arbeit-aufnehmen, befunde-sichten, fehler-melden,
roadmap-pflegen. Ihr Wert liegt nicht in der gesparten Tipparbeit, sondern
darin, dass die Hausregeln mitkommen - erst nachsehen wer dransitzt,
Fremdmeldung nur mit Begruendung, Verworfenes nicht ohne neues Argument
wiedervorschlagen. Bisher standen die nur in Werkzeugbeschreibungen, und
die liest ein Modell erst, wenn es das Werkzeug schon gewaehlt hat.
- DC_PROJECT: worauf die Ressourcen zeigen. Werkzeuge nehmen project_slug je
Aufruf, Ressourcen haben keine Argumente.
- Ressourcen laufen durch dieselbe Fremddaten-Abgrenzung wie
Werkzeugergebnisse - sie sind eher ein Einfallstor, weil sie ungefragt im
Kontext landen.
- Einrichtung fuer claude_desktop_config.json dokumentiert.
Behoben: "initialize" spiegelte die verlangte Protokollfassung zurueck. Ein
Client, der 2025-06-18 anfragte, bekam sie bestaetigt, obwohl der Adapter
fuer 2024-11-05 geschrieben war. Jetzt wird gegen eine Liste tatsaechlich
bedienter Fassungen ausgehandelt.
Behoben: process.exit() mitten in schliessenden libuv-Handles. Unter Windows
eine Assertion und Rueckgabewert != 0 - ein sauber beendeter Server sah aus
wie ein abgestuerzter.
ZWEI BEFUNDE, DIE ERST DIE RESSOURCEN ZUTAGE FOERDERTEN
- roadmap.php?action=render lehnte fuer ein Werkbank-Token mit
"missing_project" ab. projectFilter() laesst es beim Lesen bewusst durch
(es soll die Landschaft sehen) und liefert null, also wurde der
Projektbezug "all". Betroffen war ausgerechnet der Tokentyp, den der
Adapter verlangt. Rueckfall ist jetzt das Heimatprojekt des Tokens.
- ProjectLinks::between() benutzte :a dreimal, forProject() :slug zweimal.
Bei ATTR_EMULATE_PREPARES = false unzulaessig -> HY093 und ein 500 auf
/api/bugtracker/v1/projects. Derselbe Fehler wie einst in der
Volltextsuche des Bugtrackers; ein Suchlauf ueber alle prepare()-Aufrufe
der Codebasis fand keine weitere Stelle.
WARUM BEIDE UNBEMERKT BLIEBEN
Beide Wege laufen nur mit einem Werkbank-Token (owner_type = dev_agent). Der
Testlauf hatte keines - es gibt keine API, so eines anzulegen, und in der
Produktion geschieht das von Hand. Ein Tokentyp, den kein Testfall benutzt,
ist ein Tokentyp, dessen Sonderwege niemand prueft.
testctl.php kann jetzt action=workbench_token; vier Testfaelle decken die Wege
ab, samt Gegenprobe, dass der Rueckfall aufs Heimatprojekt das Lesen ueber alle
Projekte nicht einschraenkt. 128 Faelle, alle gruen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Deploymentcenter BotandClaude Opus 5
|
1d5ac92051 |
feat(2.7.0): Roadmap im DC, Testinstanz mit Testtor, Supervisor und MCP
Sammelcommit fuer den ueber mehrere Sitzungen gewachsenen, bisher nicht
eingecheckten Stand. Getrennte Commits waeren ehrlicher gewesen, sind es
nachtraeglich aber nicht mehr: BugRepo, changelog.json und die Doku tragen
Aenderungen aus allen Straengen gleichzeitig, und keine Zwischenstufe waere
lauffaehig.
ROADMAP IM DEPLOYMENTCENTER (2.7.0)
Planungsstand, Reihenfolge und Zustaendigkeit lagen in handgepflegten
Markdown-Dateien neben einem Bugtracker, der genau diese drei Dinge bereits
fuehrt. Zwei Pfleger fuer dasselbe Feld - Drift war eine Frage der Zeit.
Ab jetzt: Zustand im DC, Begruendung in der Datei. Kein Feld hat zwei Pfleger.
- Migration 016: epic, roadmap_rank, target_build, defer_trigger,
doc_anchor, Status "deferred", Tabelle roadmap_epics.
KEINE Roadmap-Tabelle - ein Eintrag ist ein bugtracker_item.
- Zugehoerigkeit ist ein Feld: Ein Item steht auf der Roadmap, wenn es ein
epic hat. Ein zweites Kennzeichen daneben koennte auseinanderlaufen.
- Kennung ist die Item-ID. Handvergebene Kuerzel ("A12") erzeugen die
schlimmste Fehlerart: Beide Seiten stimmig, Verschiedenes gemeint, weil
die Kennung nach einer Loeschung neu vergeben wurde.
- Zurueckstellen verlangt defer_trigger. Ohne benannten Anlass ist ein
Vorhaben nicht zurueckgestellt, sondern vergessen. Die Regel sitzt im
Repository, damit sie auf allen drei Schreibwegen gleich greift.
- Modules/Bugtracker/Roadmap.php, /api/bugtracker/v1/roadmap.php,
WebUI-Modul mit Filtern, cli/roadmap.php --write/--check,
dc_roadmap und dc_roadmap_set im MCP-Adapter.
- cli/roadmap.php --write ERZEUGT den Zustandsteil der Markdown-Datei;
--check prueft nur die Prosa. Was erzeugt wird, kann nicht driften.
- docs/ROADMAP_MIGRATION.md: Uebernahme fuer die anderen Projekte.
TESTINSTANZ UND TESTTOR
- dc-dev.mhdf.de: zweite Installation, eigene DB, eigene Schluessel,
Basic-Auth davor, Rocket.Chat aus.
- 124 Testfaelle in tests/e2e gegen API, Rechte, Migrationen, Sperre.
- scripts/deploy.py bringt vor jedem Upload erst den anstehenden Stand auf
die Testinstanz und laesst dann den Testlauf laufen. Erst bei
Rueckgabewert 0 geht etwas auf die Produktion (--ohne-test als Notausgang).
Andersherum prueft der Lauf aelteren Code als den, der gleich hochgeht.
- tests/ ist aus dem Produktiv-Deploy ausgeschlossen; testctl.php kann
nicht versehentlich auf dc.mhdf.de landen.
- Ein Lauf mit mehr uebersprungenen als geprueften Faellen endet mit
Rueckgabewert 2 statt 0. Nichts ist kaputt, geprueft wurde es aber auch
nicht - der Unterschied darf nicht am Rueckgabewert verschwinden.
SUPERVISOR, PROJEKTLANDSCHAFT, NACHPRUEFUNG (2.6.0/2.6.1)
- Migration 013: projektuebergreifend melden (dev_agent, evidence,
triage_external, affects).
- Migration 014: supervisor_findings, Katalog, fuenf serverseitige
Detektoren im Tick.
- Migration 015: Nachpruefung als Arbeitsschlange statt Benachrichtigung.
- DEV-Lizenzschluessel zur Selbstbedienung, dc-testkit fuer die Test-VM.
- MCP-Adapter: 15 Werkzeuge, ohne Fremdabhaengigkeiten, mit Abgrenzung
von Fremddaten gegen Prompt-Injektion.
BEHOBEN
- observe und status im Supervisor legten den Zustand des Befundes als
"status" in die Antwort. Http::ok() merged ['status' => 'success']
darunter, also gewann der Befundzustand - eine angenommene Meldung kam
als status="open" an. Heisst jetzt finding_status. War Item #59.
Migrationen 013-016 sind auf dem Produktivserver noch NICHT ausgefuehrt.
Ohne sie bricht das WebUI, weil die Roadmap-Ansicht bei jedem Seitenaufruf
gegen bugtracker_items.epic abfragt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Deploymentcenter BotandClaude Opus 5
|
687ee0cefc |
feat(installer): Laufzeitpruefung, Host-Ueberwachung, Zugang fuer Adminkonten
Drei Dinge, die beim ersten Lauf des Installers auf einer Linux-Maschine auffielen. 1. Die Release-Ablage wies Administratorkonten ab. ReleaseGuard nahm nur die Rolle 'installer' in die .htpasswd auf, waehrend Installskripte und Agent ausdruecklich sagten, ein Administratorkonto tue es auch: Anmeldung und Katalog gelangen, erst der Download endete mit 401 - und die Meldung sprach von abgelaufenen Lizenzen, die es bei einer Erstinstallation gar nicht geben kann. Adminkonten zaehlen jetzt zu den Installationskonten. FORMAT_VERSION auf 3, damit reconcile() die Dateien sofort neu schreibt statt erst beim naechsten turnusmaessigen Lauf; ein neu angelegtes Konto landet ausserdem unabhaengig von seiner Rolle sofort darin. Bei einem 401 mit Benutzerzugangsdaten nennt der Client jetzt Konto und zugangsberechtigte Rollen, und der Agent bricht ab, statt ueber die API weiterzusuchen und dieselbe Meldung ein paar Schritte spaeter ein zweites Mal zu zeigen. 2. Der Installer prueft die .NET-Laufzeit. Bisher endete eine gelungene Installation auf einer Maschine ohne .NET mit einer Anwendung, die sich nicht starten laesst - und die Fehlersuche begann beim Deploymentcenter, weil das der letzte bewusste Schritt war. Gelesen wird die runtimeconfig.json der Anwendung und mit "dotnet --list-runtimes" verglichen; fehlt etwas, nennt der Installer den Installationsbefehl fuer diese Plattform. Eigenstaendig veroeffentlichte Pakete werden nicht bemaengelt, rollForward wird beachtet. 3. Die Ueberwachung der Maschine entsteht im Installer. Zwei Fragen - Name im Dashboard und ob eingeplant werden soll - statt fuenf Schritten in der Oberflaeche an einem anderen Rechner. Monitor, Token mit genau watchdog:ping, Skript, Dateirechte, ein Heartbeat zur Probe und der Cron-Eintrag bzw. die geplante Aufgabe entstehen daraus. Fuer Maschinen ohne Installation: --action monitor. Die Agent-Skripte werden jetzt in src/Modules/Watchdog/AgentScript.php erzeugt - von Oberflaeche und Installer gemeinsam - und melden Last, Speicher, Plattenbelegung und Laufzeit mit, statt nur "status: ok". Beim Ausfuehren fielen zwei Fehler auf, die dort behoben sind: df -P verrutscht bei Geraetenamen mit Leerzeichen (gezaehlt wird jetzt von hinten), und ohne LC_ALL=C erzeugt awk auf einem deutschen System "12,5" und damit kaputtes JSON. Neu: POST /api/setup/v1/agent. SDK 2.6.0 mit SetupClient.RequestWatchdogAgentAsync(). Die OpenAPI-Beschreibung des neuen Endpunkts bleibt zunaechst aussen vor: public/api/openapi.php traegt gerade auch fremde, noch nicht committete Aenderungen aus einer parallel laufenden Arbeit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Deploymentcenter BotandClaude Opus 5
|
f8771c8d1b |
fix(guard): Zugangsschutz je Produkt abschaltbar, Dienst-Betrieb, Buildzeiten
Sieben Rueckmeldungen aus einer laufenden Integration. Der schwerwiegendste Punkt ist ein Fehler von mir. D2 - Predictalytics ist ausgesperrt. Bestaetigt: /releases/predictalytics/ antwortet mit 401, waehrend die API weiter "Update verfuegbar" meldet. Jede ausgelieferte Installation laeuft damit in die Wand. Ursache ist nicht der Schutz an sich, sondern dass ich ihn scharfgeschaltet habe, ohne zu pruefen, ob die Verbraucher nachgezogen sind - genau der Fall, vor dem UPGRADE §16.1 warnt. Behoben wird die Klasse des Problems, nicht nur dieser Fall: Produkte lassen sich unter UpdateService -> Zugangsschutz einzeln ausnehmen. Damit ist der gestaffelte Rollout moeglich, der bisher fehlte: ausnehmen, Build mit Schluessel ausliefern, wieder einschalten. Ausgenommene Produkte sind in der Uebersicht deutlich als AUSGENOMMEN markiert und faerben den Selbsttest nicht gruen. D5 - BuildInfo.targets verhinderte inkrementelle Builds. BuildDateUtc trug die volle Uhrzeit, aenderte sich also bei jedem Build; WriteOnlyWhenDifferent griff nie, und jedes einbindende Projekt wurde jedes Mal neu uebersetzt. Jetzt tagesgenau. Das Commit-Datum waere stabiler, laesst sich aber nicht verlaesslich holen - die Formatangabe von git log ueberlebt MSBuild und cmd.exe nicht, wie ein Fehlversuch gezeigt hat. D4 - LicenseConfig war uneinheitlich und fuer Dienste unbrauchbar. SetStorageDirectory benutzte den Pfad roh, waehrend der Weg ueber die Umgebungsvariable <slug>/license anhaengte: zwei Produkte im selben Prozess schrieben in dieselbe state.dat. Und ohne $HOME - systemd User= ohne Heimatverzeichnis - landete der Rueckfall im Installationsverzeichnis, unter /opt nicht beschreibbar. Neu: einheitliches Anhaengen und ein Rueckfall auf /var/lib/<slug>, der vorher prueft, ob dort ueberhaupt geschrieben werden kann. D1 - Woher die Anwendung den Lizenzschluessel fuer den Update-Zugang nimmt, stand nirgends zusammenhaengend. Jetzt ein Beispiel in UPDATESERVICE §5A, das TryGetCachedKey und CheckForUpdateAsync verbindet. D3 - Fuer einen laufenden systemd-Dienst gab es keinen Update-Weg. Neu: SETUP §4A mit einer oneshot-Unit, die stoppt, aktualisiert und wieder startet - ohne --restart, weil der Agent sonst an systemd vorbei einen zweiten Prozess startet. Inklusive EnvironmentFile fuer den Schluessel und dem Hinweis auf die Dateirechte nach einem Lauf als root. D6 - Die Empfehlung Environment.Exit(1) passt fuer handelnde Systeme nicht. Ein neuer Abschnitt im Lizenz-Leitfaden beschreibt den Sperrbetrieb: abschalten, was neue Verpflichtungen eingeht; weiterlaufen lassen, was bestehende abwickelt. D7 - Die Drosselungsgrenzen aller Endpunkte stehen jetzt in docs/README.md. /api/errors/v1/report erlaubt 300 pro Minute, nicht 60; die Einstellung bugtracker.error_rate fehlte in der Beispielkonfiguration. Der zweite Teil des Befunds war veraltet: docs/README.md fuehrt die Release-Anleitung bereits. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Deploymentcenter BotandClaude Opus 5
|
7a3a5dad69 |
fix(releases): Lizenzschluessel nicht mehr im Klartext, Selbsttest, Zielorte
Vier Befunde aus einer externen Durchsicht der 2.4-Integration.
1. Die .htpasswd war eine Klartext-Kundenliste
Das htpasswd-Format hasht nur die Passwortspalte. Benutzername UND Passwort
waren der Lizenzschluessel - der Schluessel stand also im Klartext direkt
neben seinem eigenen bcrypt-Hash, und der Hash war Dekoration. Geschuetzt
hat das Ganze nur die FilesMatch-Regel in derselben Datei.
Der Benutzername wird jetzt abgeleitet: lic_<sha256(schluessel), 16 Hex>.
Die Datei enthaelt damit nur noch eine Einwegableitung und einen Hash ueber
einen hochentropen Schluessel.
Server und SDK muessen dabei zeichengenau uebereinstimmen; ein Test prueft
die C#-Ableitung gegen die PHP-Formel.
2. Ein Formatwechsel blieb unbemerkt liegen
Beim Umbau auf 1. faellt auf: reconcile() sah keinen Anlass zur
Neuerzeugung, die Dateien behielten das alte Format, waehrend die Clients
bereits das neue schickten. Die erzeugten Dateien tragen deshalb jetzt eine
Formatkennung; weicht sie ab, wird neu erzeugt.
3. Doku beschrieb Nginx, der Schutz ist Apache-only
.htaccess wird von Nginx ignoriert - dort waeren die Verzeichnisse offen und
die .htpasswd oeffentlich abrufbar. Die Statusanzeige pruefte nur, ob die
Dateien existieren, und haette in dem Fall "GESCHUETZT" gemeldet.
Neu: ein echter Selbsttest ruft die eigene Paket-Adresse OHNE Zugangsdaten
ab und erwartet 401. Er laeuft beim manuellen Erzeugen und nach jeder
automatischen Neuerzeugung; das Ergebnis steht in der Oberflaeche, ein
Fehlschlag im Log. Er findet nebenbei auch abgeschaltetes AllowOverride und
Tippfehler in der erzeugten Datei. Doku korrigiert, Nginx-Vorlage ergaenzt.
4. Erstinstallation schrieb an einen Ort, an dem Linux-Anwendungen nicht lesen
setup.json-Ziele waren immer installationsrelativ. Eine Anwendung, die sich
unter Linux richtig verhaelt, liest aus $XDG_CONFIG_HOME - /opt/<app> ist
fuer den Dienstbenutzer meist nicht schreibbar. Der Installer legte die
Datei also dorthin, wo nie jemand nachsieht.
Ziele haben jetzt ein "location": install (Vorgabe), config, data, home,
plus ${VAR}- und %VAR%-Ersetzung in "file". Unbekannte Variablen bleiben
stehen statt leer zu werden - ein Platzhalter faellt auf, ein falscher Pfad
nicht. Der Installer gibt den aufgeloesten Pfad aus, weil bei config das
Konto entscheidet, unter dem er laeuft.
Ausserdem
- Doku zeigte "status": "ok" fuer update/delete; Http::ok() erzeugt
"status": "success".
- UPGRADE §16.1 deckte Neuprodukte nicht ab: Fuer ein Produkt ohne Release
existiert /releases/<slug>/ nicht und wird uebersprungen. Das Verzeichnis
entsteht erst mit dem ersten Upload, der naechste Tick schuetzt es. Der erste
ausgelieferte Build muss die Zugangsdaten also schon mitbringen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Deploymentcenter BotandClaude Opus 5
|
ceb977187e |
feat(releases): Zugangsschutz ueber Lizenzschluessel
/releases/ wurde bisher offen ausgeliefert, damit ausgelieferte Anwendungen ohne Zugangsdaten nach Updates suchen koennen. Das bedeutete aber auch, dass jeder im Internet die vollstaendigen Pakete herunterladen konnte - mitsamt allem, was versehentlich darin liegt. Genau so lag ein echter API-Schluessel in einer mitgelieferten appsettings.json oeffentlich abrufbar. Zugang haengt jetzt am Lizenzschluessel: Wer eine gueltige Lizenz fuer ein Produkt hat, kommt an dessen Updates. Die Anwendung kennt ihren Schluessel ohnehin und versorgt sich damit selbst - es muss nichts verteilt werden. Server - ReleaseGuard erzeugt je Produktverzeichnis .htaccess und .htpasswd. Bewusst getrennt: eine gemeinsame Datei wuerde bedeuten, dass eine Lizenz fuer Produkt A auch Produkt B oeffnet. license_licenses.product_id bindet jeden Schluessel ohnehin an genau ein Projekt. - Eingetragen werden aktive, nicht abgelaufene Lizenzen (Benutzername = Passwort = Schluessel; Basic Auth braucht zwei Felder, es gibt aber nur ein Geheimnis) sowie alle Installationskonten - bei einer Erstinstallation gibt es noch keinen Schluessel, mit dem sich das Paket holen liesse. - Deren Hash wird unveraendert aus dc_users uebernommen: password_hash() erzeugt bcrypt im Format $2y$, genau das versteht Apache. Ein Klartextpasswort wird nirgends gebraucht. Argon2-Hashes werden erkannt und uebersprungen statt eine unbrauchbare Datei zu erzeugen. - Lizenzschluessel werden mit Kosten 8 gehasht statt 12: 29 Zeichen maschineller Zufall sind kein Menschenpasswort, Apache prueft aber bei *jeder* Anfrage neu. - Geschrieben wird ueber eine temporaere Datei mit rename() - ein Abbruch wuerde sonst eine halbe Zugangsdatei hinterlassen und in dem Moment die halbe Kundschaft aussperren. - Neu erzeugt bei jeder Lizenz- und Kontoaenderung. Abgelaufene Lizenzen loesen anders als ein Widerruf nichts aus; dafuer gleicht cli/tick.php nach und erzeugt spaetestens alle sechs Stunden neu. - Statusanzeige und Schaltflaeche im WebUI unter UpdateService. Client - ReleaseCredentials: Lizenzschluessel oder Installationskonto als Basic Auth. - UpdateClient und Agent senden sie fuer latest.json und package.tar.gz. - UpdateCheckResult.Unauthorized trennt "Lizenz traegt nicht mehr" von einem Netzwerkfehler. Ohne diese Unterscheidung sucht man an der falschen Stelle. - LaunchUpdateAgent reicht licenseKey als --license-key durch. - Der Installer benutzt die beim Anmelden eingegebenen Zugangsdaten auch fuer den Paketabruf; das Setup-Token taugt dafuer nicht, weil Apache prueft und nicht die Anwendung. Sonstiges - deploy.py klammert artifacts/ aus. Ohne das landeten die gebauten Installer-Binaries zusaetzlich unter /artifacts/ im Webroot. ACHTUNG Reihenfolge: Der Schutz sperrt jede Anwendung aus, die noch mit dem alten SDK gebaut ist. Erst ausliefern, dann scharfschalten - siehe UPGRADE.md §16. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Deploymentcenter BotandClaude Opus 5
|
c8f3e78635 |
feat(setup): Erstinstallation ueber den Update-Agent, Installationskonto, Downloads
Bisher gab es nur den Update-Weg: eine Anwendung musste bereits installiert und eingerichtet sein, damit sich etwas aktualisieren liess. Die Erstinstallation auf einem neuen System war Handarbeit - Paket kopieren, Konfiguration abtippen, Token besorgen. Setup-API (neu) - POST /api/setup/v1/login tauscht Benutzername und Passwort gegen ein Token mit 30 Minuten Gueltigkeit und ausschliesslich setup:install. Es wird nicht mitgeschrieben und lebt im Installer nur im Speicher. - GET /api/setup/v1/catalog zeigt nur, was zur Laufzeitkennung des anfragenden Systems passt. Ein Projekt mit ausschliesslich Windows-Paket taucht auf einem Linux-Rechner gar nicht erst auf. - POST /api/setup/v1/token stellt das Dauertoken der Anwendung aus. Welche Rechte vergeben werden, entscheidet der Server; die Anfrage kann nur einschraenken. Sonst waere der Umweg ueber ein kurzlebiges Token wirkungslos. Rollentrennung (Migration 012) - dc_users bekommt role, disabled und last_login_at. Die Rolle "installer" darf sich ueber den Setup-Weg anmelden und nicht am WebUI. Die Zugangsdaten werden auf jedem Zielsystem eingetippt; mit einem Administratorkonto verteilte man damit den Zugang zu Tokens, Lizenzen und Monitoren auf jeden Rechner, auf dem je etwas installiert wurde. - Auth::verifyCredentials() prueft sessionfrei, damit Setup- und WebUI-Login nicht zwei verschiedene Haertungsgrade haben (Drosselung, Timing-Angleichung, Rehash gelten fuer beide). - Konten mit hinterlegtem TOTP-Geheimnis werden am Setup-Weg mit 501 abgewiesen. Eine TOTP-Pruefung gibt es im Deploymentcenter noch nicht; sie stillschweigend zu uebergehen waere ein Rueckschritt. - Benutzerverwaltung im WebUI - es gab bisher gar keine, nur den einen von install_db.php angelegten Admin. Das letzte aktive Administratorkonto laesst sich weder deaktivieren noch loeschen. Installer - update-agent --action install fuehrt durch Anmeldung, Auswahl, Zielverzeichnis, Installation und Einrichtung. Die Dateien kommen ueber denselben Pfad wie ein Update - mit Pruefsumme, Signatur, Staging und Rollback. Ein zweiter Download-Weg waere ein zweiter Ort fuer dieselben Fehler. - --action configure holt die Einrichtung nachtraeglich. - setup.json im Paket beschreibt die benoetigten Werte. Bewusst im Paket und nicht zentral: so ist sie mit der Anwendung versioniert. - Gefragt wird nur, was uebrig bleibt: bereits gesetzt -> detect:... -> provision -> fragen. Platzhalter wie changeme oder <dein-wert> gelten dabei nicht als eingerichtet, sonst liefe die Anwendung mit der Vorlage los. - SetupWriter erhaelt vorhandene Inhalte. Eine appsettings.json fuehrt neben den abgefragten Werten meist Logging und anderes; sie neu zu erzeugen waere bequemer und verloere das - bei einer Neuinstallation ohne Backup. int und bool landen als JSON-Typ, nicht als Zeichenkette. Downloads - scripts/build_installer.ps1 baut selbstenthaltende Einzeldateien fuer win-x64, linux-x64 und linux-arm64 (rund 34 MB, .NET-Laufzeit inbegriffen). Ohne NativeAOT und ohne Trimming: Spectre.Console loest ueber Reflexion auf und braeche sonst erst beim Anwender. - scripts/upload_installer.py laedt sie nach /installer/. Getrennt von deploy.py, das client-dotnet bewusst ausklammert. - Bereich "Installer" auf der UpdateService-Seite mit Groessen, Pruefsummen und den wget-Befehlen; die Angaben stammen aus installer.json statt aus fest eingetragenem Text. - install.sh und install.ps1 laden, pruefen die Pruefsumme und legen ab - sie richten bewusst nichts selbst ein. Das Manifest wird BOM-frei geschrieben, sonst scheitert json_decode() daran. Enthaelt ausserdem die bislang nicht committete Arbeit an den RocketChat-Benachrichtigungen (Migrationen 010 und 011) sowie die Loesch- und Editierfunktion des UpdateService; die betroffenen Dateien liessen sich nicht getrennt stagen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Deploymentcenter BotandClaude Opus 5
|
2388b5abe1 |
feat(updateservice): Plattform-Dimension, signierte Releases, Update mit Rollback
Behebt eine Reihe zusammenhaengender Fehler im Update-Weg, die zusammen verhindert haben, fuer mehr als eine Plattform auszuliefern - und die im Fehlerfall halb aktualisierte Installationen hinterliessen. Server - Migration 009: Spalte platform samt neuem Unique-Key. Zuvor verdraengte das zuletzt veroeffentlichte Paket alle anderen Plattformen derselben Version, weil ON DUPLICATE KEY auf (slug, version, channel) griff. Ein Linux-System zog sich damit das Windows-Paket. - Aufloesungsregel: je Version das plattformgenaue Paket, sonst das plattformunabhaengige. Ein Client ohne Plattformangabe sieht ausschliesslich 'any' - lieber kein Update als das falsche. - manifest_json wird endlich befuellt; die Spalte blieb bisher immer leer, wodurch die API nie der Rueckfall sein konnte, als der sie gedacht war. - Releases werden serverseitig mit RSA-SHA256 signiert, neuer Endpunkt /api/updateservice/v1/pubkey. Bewusst kein HMAC: der Pruefende laeuft auf fremden Systemen und darf den Signierschluessel nicht besitzen. Packager - Bricht ab, statt die Versionshistorie zu verlieren. Schlug das Lesen der bestehenden latest.json fehl, ersetzte ein leeres catch die komplette Historie durch einen einzigen Eintrag - ohne jede Meldung. - Echte Glob-Muster. Zuvor trafen "logs/**" und "scratch/**" aus der mitgelieferten Beispielkonfiguration nie zu. - preservePatterns: Konfigurationsvorlagen werden ausgeliefert, ersetzen am Ziel aber keine vorhandene Datei. Eine settings.json mit Zugangsdaten ueberschrieb bisher beim Update die Konfiguration jedes Zielsystems. - Warnt vor Dateien, die nach Zugangsdaten aussehen und auf keiner Liste stehen. - Prueft --version gegen die Hauptassembly. Eine Abweichung fuehrte zu einer Endlosschleife: Clients aktualisieren, melden weiter die alte Version, halten das Release erneut fuer neu. - --platform mit Ableitung aus dem Publish-Pfad. Agent - Anwenden mit Plan, Backup und vollstaendigem Rollback. Die Stelle war als "Atomic Replace with Backup" kommentiert und war eine Kopierschleife. - Verwaiste Dateien werden entfernt, aber nur solche aus dem Manifest der Vorversion. Was nicht aus einem Release stammt, bleibt liegen. - Das laufende Agent-Binary wird zur Seite gelegt statt ueberschrieben. - API-Rueckfall in FetchManifestAsync; bisher nur im SDK vorhanden, weshalb die Anwendung "Update verfuegbar" und der Agent "kein Release" sagen konnte. - Installierte Version aus --current-version oder manifest.json statt des Textes "Unbekannt", der als 0 gelesen wurde und jede Version neuer erscheinen liess. Reparatur funktioniert damit auch ohne manifest.json. - Setzt das Ausfuehrungsbit fuer Linux-Pakete, die unter Windows gebaut wurden. SDK - ResolveAgentPath() liefert den plattformrichtigen Namen; ein fest verdrahtetes "update-agent.exe" wird unter Linux nie gefunden. - LaunchUpdateAgent uebergibt jetzt --restart (wurde nie uebergeben, die Anwendung blieb nach dem Update zu), --wait-for-pid (kein Wettlauf mehr mit dem Herunterfahren) und --platform. Enthaelt ausserdem die bislang nicht committete Arbeit an Watchdog, Lizenz- Client und cli/tick.php samt Migration 008; die betroffenen Dateien liessen sich nicht getrennt stagen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Deploymentcenter BotandClaude Opus 5
|
5f9b0c5596 |
docs: Integrationsanleitungen auf Stand 2.0 bringen, Status "stopped" ergänzen
Watchdog-Anleitung vollständig überarbeitet - Alle drei Codebeispiele trugen das geseedete Demo-Token fest im Quelltext. Es ist an die Source "srv-db-01" gebunden — wer es übernommen hätte, wäre für jeden anderen Dienst abgewiesen worden. Jetzt Umgebungsvariable und eine Anleitung, wie man ein eigenes Token erzeugt. - Der Ratschlag "sende beim Beenden einen Ping mit Status stopped" beschrieb etwas, das die API nicht konnte. Statt die Anleitung an die Lücke anzupassen, ist die Lücke geschlossen: status akzeptiert jetzt "stopped" und "maintenance". Der Evaluator lässt solche Monitore in Ruhe, statt wenige Minuten nach jedem sauberen Shutdown einen Fehlalarm zu erzeugen. - Neu dokumentiert: checks (Gesundheitszustand per Push, ohne offene Ports), metrics samt Verlauf und Abweichungsvergleich, Alarmunterdrückung über die Hierarchie, die Schwellen des Evaluators (2x warning, 4x down) und der erforderliche Cron-Job. Lizenz-Anleitung - Neuer Abschnitt zum Antwortformat. Die Lizenz-Endpunkte antworten bewusst ohne den status/error-Umschlag der übrigen API; das Feld status auf oberster Ebene trägt den Lizenzzustand. Genau diese Besonderheit hatte ich beim Umbau übersehen, weshalb sie jetzt ausdrücklich festgehalten ist — samt Tabelle aller Zustände. - Ergänzt: Deaktivierung braucht den shared_key, mit Beispiel für den .NET- Client und curl. Verhalten bei Ratenbegrenzung. UpdateService-Anleitung - Prüf-Endpunkte dokumentiert (check, latest, releases) samt Antwortformat. - Tabelle zum Versionsvergleich mit den Fällen, die vorher falsch liefen. - Auto-Resolve beim Veröffentlichen beschrieben. Agent-Prompt-Vorlage - Fehler-Schnittstelle ergänzt, inklusive Hinweis auf "ignored": true, damit ein Agent bekannte Fehler nicht untersucht. Alle in der Dokumentation genannten API-Pfade und Scopes wurden maschinell gegen Routing und TokenManager abgeglichen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Deploymentcenter BotandClaude Opus 5
|
60e34b29f6 |
feat(errors, watchdog): Fehler-Stream mit Ignore-Regeln, Metrik-Verlauf, Abhängigkeits-Alarme
Fehler-Schnittstelle - Neuer schlanker Eingang POST /api/errors/v1/report für den globalen Exception-Handler einer Anwendung. Titel und Dringlichkeit leitet der Server ab; gespeichert wird in derselben Tabelle wie der Bugtracker. Ein zweiter Speicher wäre nur ein zweiter Ort, an dem man suchen müsste. - error_level (fatal/error/warning) trennt die technische Art des Ereignisses von der geschäftlichen Dringlichkeit. Ein Duplicate-Entry ist technisch ein error, geschäftlich belanglos — beides zu vermischen war der Grund, warum solche Meldungen als Bug im Dashboard landeten. Ignore-Regeln gegen bekanntes Rauschen - bugtracker_ignore_rules mit contains/regex/exception_class, Pflichtfeld für die Begründung und optionaler Alarmschwelle. - Ein Treffer bedeutet nicht "wegwerfen": Der Fehler wird weiterhin erfasst und hochgezählt, bleibt aber aus der Übersicht heraus und löst keine Benachrichtigung aus. Der Zähler ist der eigentliche Zweck — dass ein bekannter Fehler auftritt, ist normal; dass er plötzlich hundertmal so oft auftritt, ist ein Signal. Dafür das rollende Stundenfenster und error.rate_exceeded. - Neue Regeln lassen sich rückwirkend auf bestehende Einträge anwenden. Gruppierung überarbeitet - Der Schlüssel nahm bisher 300 Zeichen Stacktrace auf. Derselbe Fehler zersplitterte dadurch, sobald ein Aufrufer den Stack einmal mitschickte und einmal nicht. Jetzt zählt der Ursprungsort: bevorzugt die Dateiangabe, sonst der erste Rahmen des Stacktrace. - Die Normalisierung ersetzte nur Zahlen ab vier Stellen, wodurch 'AA-1' und 'BB-2' getrennt blieben. Werte in Anführungszeichen, die Ziffern enthalten, gelten jetzt als veränderlich — der Schlüsselname bleibt erhalten, sodass verschiedene Unique-Keys unterscheidbar sind. Mit 9 Testfällen belegt. Metrik-Verlauf - watchdog_metrics speichert numerische Heartbeat-Werte mit Zeitstempel. Zuvor wurde metrics_json bei jedem Heartbeat überschrieben; damit ließ sich "die Platte läuft seit drei Tagen voll" nicht erkennen, nur "sie ist voll". - GET /api/watchdog/v1/metrics liefert den verdichteten Verlauf und die Abweichung vom eigenen Sieben-Tage-Durchschnitt. Dieser relative Ansatz braucht keine projektspezifischen Schwellwerte. - Aufbewahrung 14 Tage, Bereinigung stündlich durch den Evaluator. Health-Checks per Push statt Abruf - Der Heartbeat nimmt ein checks-Objekt entgegen, das die Anwendung selbst ermittelt. Das Deploymentcenter interpretiert die Namen nicht, es liest nur ok und message — was "gesund" bedeutet, entscheidet jede Anwendung selbst. Schlägt eine Prüfung fehl, wird ein als ok gemeldeter Heartbeat auf warning herabgestuft. - Bewusst ausgehend: auf den Zielmaschinen müssen keine Ports geöffnet werden. Abhängigkeitsbewusste Alarmierung - Fällt ein Monitor aus, dessen Parent selbst unten ist, wird der Alarm unterdrückt. Der Zustand bleibt sichtbar. Vorher erzeugte ein ausgefallener Hypervisor mit zwölf VMs dreizehn Meldungen für ein Problem. - Mehrere Ebenen und fehlerhafte Hierarchien (Zyklen, gelöschte Parents) sind abgesichert; mit 10 Testfällen belegt. WebUI - Neue Ansicht "Fehler-Stream" mit Filtern nach Projekt, Fehlerklasse, Umgebung, Zeitraum und Sichtbarkeit sowie Volltextsuche und Pagination. Stummgeschaltete Einträge sind standardmäßig ausgeblendet. - Verwaltung der Ignore-Regeln inklusive Trefferzähler. - Die Detailansicht zeigt Fehlerklasse, Stummschaltungsgrund und die Häufung im laufenden Stundenfenster. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Deploymentcenter BotandClaude Opus 5
|
a74c6fd990 |
fix(clients, docs): Lizenz-Antwortformat wiederherstellen, Packager absichern
Regression aus dem vorigen Commit - /api/license/v1/validate lieferte die Antwort im neuen status/error-Umschlag. Der Vertrag dieses Endpunkts ist aber bereits ausgerollt: das Feld "status" auf oberster Ebene trägt den Lizenzzustand (valid, revoked, expired ...). LicenseClient las dadurch "success" statt "valid" — jeder ausgelieferte Client hätte seine Lizenz für ungültig gehalten. Die Lizenz-Endpunkte antworten jetzt wieder ohne Umschlag (Http::raw). Gefunden durch Ausführen der projekteigenen Test-Suite gegen den Server. Packager - FTP-Zugangsdaten standen als Standardwerte im Quelltext und zusätzlich in packager.config.json und in der Integrationsanleitung. Alle drei Fundstellen bereinigt; die Konfigurationsdatei ist nicht mehr versioniert. Zugangsdaten kommen aus Datei, Umgebungsvariablen oder CLI-Argument, sonst bricht das Programm mit einer klaren Meldung ab. - Das Veröffentlichen sendet jetzt ein Token (updateservice:publish) und nutzt den Endpunkt /api/updateservice/v1/publish. - Fehler wurden von einem leeren catch verschluckt, und ohne Erfolgsfall wurde gar nichts ausgegeben. Das Werkzeug meldete am Ende immer Erfolg und lieferte Rückgabewert 0, selbst wenn FTP-Upload und API-Aufruf fehlgeschlagen waren. Jetzt ehrliche Meldungen und Rückgabewerte 0/1/2. - packager.config.json wurde vom csproj nie ins Ausgabeverzeichnis kopiert, weshalb sie dort nie gefunden wurde und stets die hartkodierten Werte griffen. UpdateClient - IsVersionNewer entfernte die Vorabkennung, aber kein führendes "v". Damit scheiterte Version.TryParse bei "v1.4.2" und es wurde auf einen alphabetischen Vergleich zurückgefallen, in dem "v1.9.0" als neuer gilt als "v1.10.0" — derselbe Fehler wie zuvor serverseitig im SQL. Ersetzt durch einen vollständigen semantischen Vergleich, verifiziert mit 16 Testfällen. - Der Rückfall auf die API lag in einem catch-Block, aber GetAsync wirft bei einem 404 keine Exception. Fehlte die statische latest.json, brach die Prüfung ab, statt die API zu befragen. Dokumentation - BUGTRACKER_INTEGRATION_GUIDE.md beschrieb denselben Workflow ein zweites Mal und war bereits auseinandergelaufen: Aufrufe ohne Token, alte Pfade, weder Claim/Lease noch Idempotenz. Ersetzt durch einen Verweis auf das gepflegte Agenten-Handbuch samt Übersicht der Änderungen. - UPDATESERVICE_INTEGRATION_GUIDE.md um Token, Umgebungsvariablen und Rückgabewerte ergänzt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Deploymentcenter BotandClaude Opus 5
|
e7fbc85db4 |
fix(security, core): Auth-Pflicht für Ingest-APIs, 500er-Ursachen beheben, Agenten-Workflow
Sicherheit
- install_db.php war ohne Authentifizierung erreichbar und setzte bei jedem
Aufruf das Admin-Passwort auf einen fest im Code stehenden Wert zurück.
Jetzt Auth-Pflicht; ein Konto wird nur bei leerer Benutzertabelle angelegt.
- Stored XSS im Bugtracker-Detail-Modal: Titel, Beschreibung, Fehlermeldung,
Stacktrace und Kommentare gingen ungefiltert durch innerHTML.
- report.php, projects.php und das Veröffentlichen von Releases verlangen jetzt
zwingend ein Token. Publish war zuvor völlig ungeschützt.
- CSRF-Token in allen Formularen, Session-Regenerierung nach Login,
Drosselung fehlgeschlagener Anmeldeversuche.
- Zugangsdaten aus der Versionskontrolle entfernt (Serverdaten.txt,
config.php, .htpasswd, deploy_config.json). Historie enthält sie weiterhin,
Rotation erforderlich (siehe docs/UPGRADE.md).
- Token-Validierung nur noch über SHA-256-Hash; expires_at wird ausgewertet.
Behobene 500er
- Audit::log() war in index.php weder eingebunden noch importiert. Jeder
Klick auf "Aktivierung freigeben" endete in einem Fatal Error.
- Derselbe benannte PDO-Platzhalter mehrfach je Statement (:id in
revokeToken/deleteToken, :q siebenfach in der Volltextsuche). Bei
EMULATE_PREPARES=false ist das nicht zulässig und warf HY093.
- Migration 005 nutzte dynamisches SQL, dessen Semikolons in String-Literalen
vom alten explode(';')-Installer als Statement-Ende gelesen wurden. Sie
schlug still fehl, wodurch push_id/target_agent/tags dauerhaft fehlten.
- Monitor-Umbenennung ohne Transaktion, verschachtelte Transaktionen im
RateLimiter.
Funktionale Korrekturen
- Der Watchdog-Evaluator fehlte vollständig: Monitor-Zustände änderten sich nur
beim Eintreffen eines Heartbeats, ein ausgefallenes System blieb dauerhaft
"up". Erster Lauf auf dem Produktivsystem: 7 von 10 Monitoren waren
tatsächlich seit über einem Tag nicht erreichbar.
- Das Feld "os" fehlte im Monitor-Dialog, wurde aber gespeichert und löschte
damit bei jedem Speichern das Betriebssystem.
- Der Resolve-Dialog existierte im HTML nicht; der Button war funktionslos.
- Versionsvergleich erfolgte lexikografisch, wodurch 1.9.0 als neuer galt
als 1.10.0.
- Schreiboperationen meldeten Erfolg auch für nicht existierende IDs.
- Post/Redirect/Get gegen doppelte Einträge beim Neuladen.
Neue Struktur
- src/bootstrap.php mit PSR-4-Autoloader ersetzt die require-Ketten.
- Core: Config, Http, Csrf, ApiAuth, Logger, Migrator, ErrorReporter.
- Migrator mit zeichenweisem SQL-Parser, dc_migrations und Baseline-Verfahren,
damit bestehende Installationen keine Beispieldaten zurückbekommen.
Agenten-Workflow
- Claim/Lease: Items werden exklusiv übernommen, damit nicht zwei Agenten am
selben Problem arbeiten. action=next holt und reserviert in einem Zug.
- Idempotenz über client_ref, Deduplizierung auch für Feature Requests,
Erkennung von Regressionen, automatische Eskalation des Schweregrads.
- Strukturierter Code-Kontext (repo_url, commit_sha, file_path, line_no).
- Delta-Abfragen über updated_since, Pagination, Bulk-Update.
- Beim Veröffentlichen eines Releases schließen sich Items mit passendem
resolved_in_build selbst.
- Ausgehende Webhooks mit HMAC-Signatur, /api/health, /api/openapi.json.
- Unbehandelte Fehler meldet die Plattform in ihren eigenen Bugtracker.
WebUI
- Serverseitige Filterung mit Pagination statt Rendern aller Datensätze.
- Migrations-Schranke, Evaluator-Warnung, Übersicht aktiver Agenten.
Zeitstempel liegen in der Datenbank durchgängig in UTC und werden für die
Anzeige in die App-Zeitzone umgerechnet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Deploymentcenter Bot
|
a21536f495 | feat(docs, api): Add Projects Discovery API, deploymentcenter project seed, public web docs endpoint, and minimal agent prompt template | ||
|
Deploymentcenter Bot
|
c437bdee6f | feat(bugtracker, tokens): Add project search, push_id, target_agent, tags, edit modal, extended severities (idea, wishlist), token actions (copy/toggle/delete), and agent integration guide | ||
|
Deploymentcenter Bot
|
563046be07 | fix: resolve 500 error caused by extra brace in index.php and missing Db::connect method | ||
|
Deploymentcenter Bot
|
d71f90cdfc | feat: integrate Bugtracker module, UpdateService enhancements & Token hierarchy | ||
|
Deploymentcenter Bot
|
70b35f7b8b | feat(license): implement Hardware-ID v2, multi-platform Linux support, StateStore LLS2 hardening, and AI Agent docs | ||
|
Deploymentcenter Bot
|
21275d1a1f | Add full monitor edit modal, direct token creation per monitor row, and cascade deletion/renaming in Watchdog | ||
|
Deploymentcenter Bot
|
731965bde5 | Move subnav menus into top-bar, apply Predictalytics glassmorphism design, add project edit and safe deletion modal, secure license deactivation, add API Swagger docs, and add Watchdog entity hierarchy tree with full CRUD | ||
|
Deploymentcenter Bot
|
fe9f95584e | Refactor UI with purple dark theme glassmorphism, projects management, license editing, agent installer scripts, unmaskable tokens, C# test suite | ||
|
Deploymentcenter Bot
|
3a38fd4837 | Initial commit: Modular Deploymentcenter platform |