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>
18 KiB
Deploymentcenter — Lizenzsystem Integration für KI-Agenten
Zielgruppe: KI-Agenten & Softwareentwickler Gültig ab: Hardware-ID v2, Deploymentcenter 2.0 Plattformen: Windows, Linux (inkl. systemd und Docker), macOS
⚠️ Änderungen in Version 2.0
/api/license/v1/validatebleibt unverändert und ohne Token erreichbar. Ausgelieferte Clients laufen ohne Anpassung weiter./api/license/v1/deactivateverlangt weiterhin Authentifizierung — aber mit dem neu erzeugtenshared_key. Der alte Wert lag im Repository und wurde ersetzt; wer ihn irgendwo eingetragen hat, muss nachziehen.- Die Signatur der Offline-Lizenzdateien heißt jetzt ehrlich HMAC-SHA256 statt irreführend
ED25519_SIG_. Der frühere „Server Public Key" im WebUI war frei erfunden und wurde entfernt.Umstellungsschritte: UPGRADE.md
⚠️ Änderungen in Version 2.1 — betreffen jede bestehende Integration
- Ein HTTP-Fehler ist kein Lizenzurteil mehr.
ValidateAsyncfällt jetzt bei jedem erfolglosen Aufruf auf den Offline-Cache zurück, nicht nur bei einer Exception. Der Statusunknown_errorentfällt, siehe §6.cache_ttl_hourswird ausgewertet. Die Offline-Gnadenfrist ist damit tatsächlich begrenzt, siehe §3.ValidateAsyncnimmtappVersionund einenCancellationTokenentgegen.- Neu:
LicenseClient.TryGetCachedKey()undRevalidateAsync().DeactivateAsyncsendet den Schlüssel nur noch alsAuthorization: Bearer. Der zusätzlicheX-Watchdog-Keyist entfallen.- Standard-Zeitgrenze von 15 s statt 100 s.
0. Antwortformat — bitte beachten
Die Lizenz-Endpunkte antworten ohne den status/error-Umschlag der
übrigen Deploymentcenter-API. Das Feld status auf oberster Ebene trägt den
Lizenzzustand:
{
"type": "validation_result",
"status": "valid",
"issued_at": 1786435199,
"expires_at": 1817971199,
"cache_ttl_hours": 168,
"hardware_id": "2:win:a765bd47...",
"license_key": "XXXXX-XXXXX-XXXXX-XXXXX-XXXXX",
"nonce": "der übergebene Wert",
"endpoints": { "validate": "/api/license/v1/validate",
"deactivate": "/api/license/v1/deactivate" },
"message": "License is valid"
}
status |
Bedeutung |
|---|---|
valid |
Lizenz gültig, Aktivierung eingetragen |
not_found |
Projekt oder Schlüssel unbekannt |
revoked |
Lizenz widerrufen oder diese Hardware gesperrt |
suspended |
Lizenz vorübergehend ausgesetzt |
expired |
Ablaufdatum überschritten |
activation_limit |
Maximale Anzahl Aktivierungen erreicht |
Diese Sonderstellung ist bewusst: Ein Umschlag mit
status: "success"würde von jedem bestehenden Client als „nicht valid" gelesen — sämtliche Lizenzen gälten schlagartig als ungültig. Wer eine eigene Anbindung schreibt, mussstatusalso von der obersten Ebene lesen, nicht aus einemresult-Objekt.
1. Architektur & Konzepte
Das Lizenzsystem von Deploymentcenter schützt Anwendungen über eine Kombination aus serverseitiger Validierung, plattformunabhängiger Hardware-ID v2 und einem gehärteten lokalen Cache (LLS2 format with AES-GCM encryption).
1.1 Hardware-ID v2 Format
Format: 2:<plattform>:<64-Hex-Zeichen>
Beispiele:
2:win:9f3ab7c1...(Windows,HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid)2:lin:41e0d5aa...(Linux,/etc/machine-id)2:lin:7c9182ff...(Linux/Container via UmgebungsvariableDEPLOYMENTCENTER_HWID)
1.2 Hash-Berechnung (KEIN MachineName im Hash)
sha256("LicenseLabrador-HWID-v2" + "\n" + plattform + "\n" + quelle + "\n" + rohwert)
WICHTIG: Der Rechnername steckt nicht im Hash. Ein Umbenennen der Maschine verändert die Hardware-ID nicht und verbraucht keine zusätzlichen Aktivierungsplätze.
1.3 Quellen-Priorisierung je Plattform
Windows:
HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid(machine-guid)- Verkettete physische MAC-Adressen (
mac) - Erzeugte Schlüsseldatei
machine.keyim StorageDirectory (keyfile)
Linux:
/etc/machine-id(machine-id) — muss plausibel sein (Länge >= 16, nichtuninitialized, nicht nur Nullen)./var/lib/dbus/machine-id(dbus-machine-id)/sys/class/dmi/id/product_uuid(dmi-uuid)- Verkettete physische MAC-Adressen (
mac) - Erzeugte Schlüsseldatei
machine.key(keyfile)
Container / Headless Overrides:
Wenn DEPLOYMENTCENTER_HWID oder LICENSELABRADOR_HWID gesetzt ist, gewinnt diese Variable Plattform-weit (override).
2. Einbindung in C# (.NET Core / .NET 8+)
Verwende das NuGet-Paket/Projekt Deploymentcenter.Client (Multi-Targeting netstandard2.0;net8.0).
2.1 Initialisierung und Standard-Validierung
using System;
using System.Threading.Tasks;
using Deploymentcenter.Client;
public class Program
{
private static readonly string ServerUrl = "https://dc.mhdf.de";
private static readonly string ProductSlug = "myapp"; // In dc_projects hinterlegter Slug
public static async Task Main(string[] args)
{
// 1. CLI Schalter für Headless/Admin-Operationen abfangen
if (args.Length > 0 && args[0] == "--license-status")
{
var hwInfo = HardwareId.GetHardwareId(ProductSlug);
Console.WriteLine($"HWID v2: {hwInfo.HardwareId} ({hwInfo.HwidSource})");
return;
}
// 2. LicenseClient instanziieren
var client = new LicenseClient();
string licenseKey = "LLAB1-98A72-B3C4D-5E6F7-89012";
// 3. Online-Validierung durchführen
LicenseValidationResult res = await client.ValidateAsync(
ProductSlug, licenseKey, ServerUrl, appVersion: BuildInfo.Version);
if (res.IsValid)
{
Console.WriteLine($"[✔] Lizenz gültig! (Status: {res.Status}, Cached: {res.IsCached})");
}
else if (res.IsTransient)
{
// Kein Urteil, nur keine Verbindung. Weiterlaufen lassen.
Console.WriteLine($"[!] Lizenz vorerst nicht prüfbar: {res.Message}");
}
else
{
Console.WriteLine($"[✖] Lizenz ungültig: {res.Message}");
Environment.Exit(1);
}
}
}
2.2 Signatur
Task<LicenseValidationResult> ValidateAsync(
string productSlug,
string licenseKey,
string serverBaseUrl,
string? appVersion = null,
CancellationToken cancellationToken = default);
appVersion landet in der Aktivierungsliste des WebUI. Ohne Angabe greift
LicenseClient.DefaultAppVersion und danach die Version der Startassembly.
Einmal beim Start setzen genügt:
LicenseClient.DefaultAppVersion = BuildInfo.Version;
Vorher stand hier fest
"1.0.0". In der Verwaltungsansicht trug dadurch jede Installation dieselbe Version, obwohl die Spalteapp_versiondafür da ist.
2.3 Ergebnisfelder
| Feld | Bedeutung |
|---|---|
IsValid |
Darf die Anwendung laufen? |
Status |
valid, valid_offline, revoked, expired, not_found, activation_limit, suspended, cache_expired, clock_rollback, server_unavailable |
IsTransient |
Neu. Wahr, wenn kein Urteil vorliegt, sondern nur die Verbindung scheiterte |
IsCached |
Ergebnis stammt aus dem Offline-Cache |
ExpiresAt |
Ablauf der Lizenz (Unix-Zeit) |
CacheExpiresAt |
Neu. Ende der Offline-Gnadenfrist (Unix-Zeit) |
2.4 Zwischengespeicherten Schlüssel lesen
// Für --license-status: was liegt lokal vor?
string? key = LicenseClient.TryGetCachedKey(ProductSlug);
LocalCacheData? state = LicenseClient.TryGetCachedState(ProductSlug);
// Erneut prüfen, ohne den Schlüssel selbst vorhalten zu müssen
var res = await client.RevalidateAsync(ProductSlug, ServerUrl);
ValidateAsync legt den Schlüssel bei erfolgreicher Prüfung selbst im
verschlüsselten Cache ab — eine eigene Ablage braucht es dafür nicht.
3. Zustandsspeicher (StateStore.cs) & Cache-Härtung
- Format: File Envelope mit Magic
"LLS2", 12-Byte Nonce, AES-256-GCM Ciphertext und 16-Byte GCM Tag. - Schlüsselableitung: HKDF-SHA256 aus
HardwareId+ProductSlug. - Windows: DPAPI-Zusatzhülle um AES-GCM Payload.
- Linux: Dateirechte
0600(chmod 600 state.dat). - Sicherheitsvorgabe: Kein Klartext-Rückfall! Beschädigte oder manipulierte Cache-Dateien werden strikt als Cache-Fehltreffer behandelt.
3.1 Offline-Gnadenfrist
Der Server meldet in jeder Antwort cache_ttl_hours — den projektspezifischen
Wert aus dc_projects.default_cache_ttl_hours, den du im WebUI unter
Projekte einstellst. Der Client trägt daraus CacheExpiresAt in den Cache
ein: frühestens die TTL, spätestens der Ablauf der Lizenz selbst.
Vorher wurde das Feld ignoriert und stattdessen das Ablaufdatum der Lizenz als Cache-Ablauf eingetragen. Bei einer Lizenz bis 2040 war die Frist ohne Serverkontakt damit praktisch unbegrenzt — die Einstellung im WebUI blieb wirkungslos.
Wer eine eigene Anbindung schreibt: cache_ttl_hours auswerten, nicht durch
expires_at ersetzen.
3.2 Schema-Stand des Caches
state.dat trägt jetzt Schema 3 (zusätzlich CacheExpiresAt, CacheTtlHours).
Schema 2 wird weiterhin gelesen; die Frist wird dort aus IssuedAt plus der
Standard-TTL von 168 h abgeleitet. Ein SDK-Wechsel erzwingt also keine
Online-Prüfung.
3.3 Migration fremder Cache-Dateien
Eine Datei ohne LLS2-Kopf wird nur übernommen, wenn ihr ProductSlug zu
diesem Produkt passt und sie einen Lizenzschlüssel enthält.
Vorher wurde beliebiges JSON nach
LocalCacheDatadeserialisiert und sofort zurückgeschrieben. Passte kein einziges Feld, entstand ein Standardobjekt, das die ursprüngliche Datei überschrieb. Da LicenseLabrador denselben Pfad und Dateinamen verwendet —GetStorageDirectoryberücksichtigt eigensLICENSELABRADOR_STORAGE_DIR—, zerstörte das dessen Cache still.
4. Kopfloser Betrieb (Headless Services / systemd)
Diese Schalter baut deine Anwendung selbst — das SDK bringt keine CLI mit. Es liefert die Bausteine dafür; die folgende Empfehlung ist eine Konvention, damit alle Dienste gleich zu bedienen sind.
# Status der Hardware-ID und des lokalen Caches ausgeben
my-service --license-status
# Lizenzschlüssel festlegen & aktivieren
my-service --license-set-key LLAB1-98A72-B3C4D-5E6F7-89012
# Aktivierung für diesen Host aufheben (Freigabe am Server)
my-service --license-deactivate
Umsetzung mit den Bausteinen des SDK:
var client = new LicenseClient();
switch (args[0])
{
case "--license-status":
{
var hw = HardwareId.GetHardwareId(ProductSlug);
var state = LicenseClient.TryGetCachedState(ProductSlug);
Console.WriteLine($"HWID v2: {hw.HardwareId} ({hw.HwidSource})");
Console.WriteLine($"Schlüssel: {LicenseClient.TryGetCachedKey(ProductSlug) ?? "keiner"}");
Console.WriteLine($"Cache: {(state == null ? "leer" : state.Status)}");
if (state != null && state.CacheExpiresAt > 0)
{
var until = DateTimeOffset.FromUnixTimeSeconds(state.CacheExpiresAt);
Console.WriteLine($"Offline noch bis: {until:u}");
}
return 0;
}
case "--license-set-key":
// ValidateAsync legt den Schlüssel bei Erfolg selbst im Cache ab.
var res = await client.ValidateAsync(ProductSlug, args[1], ServerUrl);
Console.WriteLine(res.Message);
return res.IsValid ? 0 : 1;
case "--license-deactivate":
string? key = LicenseClient.TryGetCachedKey(ProductSlug);
if (key == null) { Console.Error.WriteLine("Kein Schlüssel hinterlegt."); return 1; }
bool ok = await client.DeactivateAsync(
ProductSlug, key, ServerUrl,
Environment.GetEnvironmentVariable("DC_SHARED_KEY") ?? "");
return ok ? 0 : 1;
}
TryGetCachedKeyundTryGetCachedStatesind neu in 2.1. Vorher gab es keinen Weg, den Schlüssel aus dem eigenen Cache zu lesen — jede Anwendung musste ihn ein zweites Mal selbst ablegen oder direktStateStore.Load()aufrufen.
Deaktivierung braucht Authentifizierung
/api/license/v1/deactivate gibt einen Aktivierungsplatz frei und ist deshalb
geschützt — sonst könnte jeder fremde Installationen abmelden. Der Aufruf
verlangt den shared_key aus config/config.php:
// Der Schlüssel gehört auf den Administrationsrechner, nicht in die
// ausgelieferte Anwendung.
var client = new LicenseClient();
bool released = await client.DeactivateAsync(
productSlug: "myapp",
licenseKey: "LLAB1-98A72-B3C4D-5E6F7-89012",
serverBaseUrl: "https://dc.mhdf.de",
authToken: Environment.GetEnvironmentVariable("DC_SHARED_KEY"));
curl -X POST https://dc.mhdf.de/api/license/v1/deactivate \
-H "Authorization: Bearer $DC_SHARED_KEY" \
-H "Content-Type: application/json" \
-d '{"product":"myapp","license_key":"XXXXX-...","hardware_id":"2:win:a765..."}'
Alternativ genügt für Einzelfälle der Knopf Freigeben in der Hardware-Liste des WebUI — das ist der übliche Weg und braucht keinen Schlüssel im Feld.
Nur noch
Authorization: Bearer. Frühere SDK-Fassungen schickten denselben Wert zusätzlich alsX-Watchdog-Key. Der Name führte in die Irre — hier gehört dershared_keyhin, kein Watchdog-Token — und der Server prüftX-Watchdog-KeyvorAuthorization. Ein dort versehentlich eingetragenes Watchdog-Token hätte das richtige Bearer-Token stillschweigend verdrängt und zu einem unerklärlichen 401 geführt.
5. Migration v1 → v2 ohne Platzverlust
Wenn ein bestehender Windows-Client auf Hardware-ID v2 aktualisiert wird:
- Der Client schickt
hardware_id(v2) undlegacy_hardware_id(v1) mit. - Der Server findet die alte Aktivierung unter
legacy_hardware_idund zieht den Datenbank-Eintrag lautlos auf v2 um. - Es wird kein zusätzlicher Aktivierungsplatz verbraucht!
6. Fehlerfälle richtig behandeln
Nur ein gelesenes Urteil ist ein Urteil. Ein HTTP-Fehler sagt nichts über die Lizenz aus — er sagt, dass die Frage nicht beantwortet wurde.
ValidateAsync fällt deshalb bei jedem erfolglosen Aufruf auf den
Offline-Cache zurück: Netzfehler, Zeitüberschreitung, 429, 5xx, und auch bei
einer erfolgreichen Antwort, die sich nicht auswerten lässt (etwa der
Fehlerseite eines Proxys mit Statuscode 200).
var res = await client.ValidateAsync(ProductSlug, key, ServerUrl);
if (res.IsValid)
{
// valid oder valid_offline — weiterarbeiten
}
else if (res.IsTransient)
{
// server_unavailable, cache_expired: kein Urteil, nur keine Auskunft.
// Warnen, weiterlaufen lassen, später erneut prüfen.
logger.Warn(res.Message);
}
else
{
// revoked, expired, not_found, activation_limit, suspended, clock_rollback
// Das ist ein Urteil. Jetzt darf beendet werden.
Environment.Exit(1);
}
Wenn Beenden die gefährlichere Option ist
Environment.Exit(1) ist die richtige Antwort für ein Werkzeug, das man
einfach nicht mehr benutzen darf. Für ein System, das offene Verpflichtungen
verwaltet, ist es die falsche: Ein Handelssystem mit offenen Positionen, eine
Maschinensteuerung im Zyklus, ein Dienst mitten in einer Transaktion — die
dürfen bei einer abgelaufenen Lizenz nicht einfach aufhören. Der Schaden aus
dem abrupten Ende wäre größer als der aus dem Weiterlaufen.
Die brauchbare Antwort ist Sperrbetrieb statt Abbruch: Was neue Verpflichtungen eingeht, wird abgeschaltet; was bestehende abwickelt, läuft weiter.
if (!res.IsValid && !res.IsTransient)
{
logger.Error("Lizenz ungültig: {0}. Wechsle in den Sperrbetrieb.", res.Message);
// Was neue Verpflichtungen eingeht: aus.
strategyEngine.StopOpeningPositions();
scheduler.PauseNewJobs();
// Was bestehende abwickelt: bleibt an.
// - Risikoüberwachung
// - Schließen offener Positionen
// - Ordnungsgemäßes Herunterfahren, wenn nichts mehr offen ist
riskManager.KeepRunning();
notifier.Alert("Lizenz abgelaufen - Sperrbetrieb. Keine neuen Positionen.");
}
Wer diesen Weg geht, sollte zwei Dinge festhalten: wann aus dem Sperrbetrieb ein Ende wird (etwa sobald keine Position mehr offen ist), und dass der Zustand sichtbar ist — ein Sperrbetrieb, den niemand bemerkt, ist ein stiller Ausfall.
Der Offline-Cache federt das übrigens schon ab: Eine kurzzeitig nicht
erreichbare Prüfung führt gar nicht erst hierher, dafür ist IsTransient da.
Hier geht es um das echte Urteil.
| Status | IsTransient |
Bedeutung |
|---|---|---|
valid |
– | Vom Server bestätigt |
valid_offline |
– | Aus dem Cache, Gnadenfrist läuft noch |
server_unavailable |
ja | Keine Verbindung und kein brauchbarer Cache |
cache_expired |
ja | Gnadenfrist abgelaufen, Server weiterhin stumm |
revoked, expired, not_found, activation_limit, suspended |
nein | Endgültig |
clock_rollback |
nein | Systemuhr zurückgedreht, Online-Prüfung nötig |
Was sich geändert hat: Der Cache-Zweig lag zuvor ausschließlich im
catch. Ein429oder500wirft aber keine Exception — die Prüfung fiel aus dem Erfolgszweig heraus und endete alsunknown_error, ohne den Cache auch nur zu befragen. Ein Server-Schluckauf entzog damit die Lizenz, ein gezogenes Netzkabel nicht. Der Statusunknown_errorexistiert nicht mehr.
Ratenbegrenzung
/validate ist auf 120 Anfragen pro Minute und IP begrenzt. Darüber kommt
429 mit {"status":"error","error":{"code":"rate_limited"}} — hier greift
ausnahmsweise das Umschlagformat, weil die Drosselung vor der Lizenzlogik
zuschlägt. Hinter einem NAT mit vielen Installationen ist das erreichbar. Der
Client verwendet in diesem Fall den lokalen Cache und versucht es später erneut.
Zeitgrenze
Der intern erzeugte HttpClient hat jetzt 15 s statt der 100 s des .NET-Standards
— sonst stand eine Anwendung beim Start bis zu anderthalb Minuten still, wenn
der Server nicht antwortete. Ein selbst übergebener HttpClient wird nicht
verändert; dessen Zeitgrenze verantwortet der Aufrufer.