Deploymentcenter BotandClaude Opus 5
7a3a5dad69
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 — Entwickler- und Agenten-Dokumentation
Zentrale Plattform für Lizenzverwaltung, Software-Updates, Infrastruktur- Monitoring und einen Bugtracker, den Coding-Agenten selbständig bedienen.
Zuerst lesen
| Dokument | Wofür |
|---|---|
| UPGRADE.md | Ablaufplan für die Umstellung auf 2.0. Enthält Pflichtschritte: Zugangsdaten wechseln, Migration, Evaluator-Cron. |
| Agent-Prompt-Vorlage | Textbaustein für CLAUDE.md / AGENTS.md eines Projekts |
| Agenten-Handbuch | Vollständige Beschreibung des Bugtracker-Workflows, öffentlich unter /docs/ |
Modul-Handbücher
- Lizenzsystem (Hardware-ID v2) — Hardware-Anbindung, Schlüsselvalidierung, Offline-Cache, CLI, Windows und Linux/Docker
- Watchdog (Heartbeat & Telemetrie) — Überwachung von Anwendungen, Diensten und Infrastruktur
- UpdateService — Release-Verteilung und Update-Prüfung
- Erstinstallation —
setup.json, Installationskonto,update-agent --action install - Bugtracker — Anbindung aus Anwendungen heraus
Modulübersicht
| Modul | Aufgabe | Endpunkte | Authentifizierung |
|---|---|---|---|
| Bugtracker | Fehler, Feature Requests und Ideen; Agenten-Workflow mit Claim/Lease | /api/bugtracker/v1/report/api/bugtracker/v1/projects/api/bugtracker/v1/manage |
Token mit bugtracker:* |
| UpdateService | Release-Verteilung, semantischer Versionsvergleich | /api/updateservice/v1/check/api/updateservice/v1/publish |
Lesen offen, Publish braucht updateservice:publish |
| Watchdog | Heartbeat-Monitoring, Zustandsbewertung, Alarmierung | /api/watchdog/v1/ping/api/watchdog/v1/evaluate |
Token mit watchdog:ping |
| Lizenzen | Lizenzprüfung, Hardware-ID v2, Offline-Cache | /api/license/v1/validate/api/license/v1/deactivate |
Validierung offen, Deaktivierung authentifiziert |
| Tokens | Selbst-Provisionierung von Sub-Tokens | /api/tokens/v1/provision |
Master-Token |
| Setup | Erstinstallation: Anmeldung, Katalog, Anwendungstoken | /api/setup/v1/login/api/setup/v1/catalog/api/setup/v1/token |
Login offen, Rest setup:* |
| System | Verfügbarkeit, Schema-Status, Schnittstellenbeschreibung | /api/health/api/openapi.json |
Health optional, OpenAPI offen |
Schnittstelle maschinenlesbar
GET https://dc.mhdf.de/api/openapi.json
Ein Agent kann sich daran selbst orientieren — der früher fest im WebUI hinterlegte Textblock entfällt damit.
Antwortformat
Alle JSON-Endpunkte antworten einheitlich:
{ "status": "success", "…": "…" }
{ "status": "error", "error": { "code": "already_claimed", "message": "…" } }
Der code ist stabil und für Programme gedacht; die message richtet sich an
Menschen und kann sich ändern.
Betrieb
| Aufgabe | Befehl |
|---|---|
| Deployment | python scripts/deploy.py |
| Migration | php public/install_db.php oder WebUI → System → DB-Migration |
| Evaluator (Cron, minütlich) | curl -fsS -H "Authorization: Bearer <SHARED_KEY>" https://dc.mhdf.de/api/watchdog/v1/evaluate |
| Zustand prüfen | curl https://dc.mhdf.de/api/health |
| Logs | var/log/dc-<datum>.log auf dem Server |
Aufbau
config/ Zugangsdaten (nicht versioniert), Vorlage in config.example.php
src/ Anwendungscode, PSR-4 unter dem Namensraum Deploymentcenter\
Core/ Bootstrap, Konfiguration, DB, Auth, CSRF, HTTP, Tokens, Migrator
Modules/ Bugtracker, License, UpdateService, Watchdog, Notify
public/ Webroot-Inhalte: WebUI, API-Endpunkte, öffentliche Dokumentation
sql/ Schema und Migrationen (fortlaufend nummeriert)
var/log/ Laufzeitprotokolle
scripts/ Deployment
Neue Klassen werden automatisch geladen, sobald sie dem Namensraum-Pfad
entsprechen — eine require-Zeile ist nicht mehr nötig.