Release-Server: Datenmodell, Endpunkte, Lizenzierung und Berechtigungen
Datenmodell des zentralen Release-Servers, Endpunkte zur Verwaltung von Installationen und Releases, Funktionsweise von Registrierungscode und Update-Anforderung, Authentifizierung der Catalog-API und die Berechtigungsschlüssel.
Der Release-Server verwaltet das Verzeichnis der Installationen (ID, Domain, Mandant, Betriebsmodell, Versionen, Lizenz, Ereignisse, Anforderungen), die Release-Liste, manuelles Hochladen und Zurückziehen, zentrale Update-Anforderungen und die Servereinstellungen. Gezeigt werden nur technische und Lizenzdaten. Rechte werden über einen Helfer mit canAction abgefragt.
Datenmodell
Die Tabellennamen tragen in der Datenbank das eigene Präfix der Installation.
| Tabelle | Rolle | Hauptfelder |
|---|---|---|
release_installation | Installationen | UUID, Bezeichnung, Domain, Mandant, Modell, Kanal, automatisches Update, Status, reg_code_hash mit Ablauf |
release | Releases | Version, Kanal, Archivort, Rückzug mit Begründung |
release_event | Ereignisse | z. B. regcode_issued |
release_request | zentrale Update-Anforderungen | Version, Modus (prepare, install), Notiz |
update_config | Servereinstellungen | server_*-Schlüssel |
company | Name des Mandanten | nur lesend |
Endpunkte
| Schlüssel | Endpunkt | Verhalten |
|---|---|---|
list | index, installations, releases | Aktivierungsstatus, öffentliche Konfiguration, Hauptschlüsseldatei, vertrauenswürdige Schlüssel, Google-Konten; seitenweise Installationsliste mit Filter, je Zeile Lizenzstatus, Rückstand zum neuesten stabilen Release, letzte 20 Ereignisse und 10 Anforderungen; höchstens 500 Releases |
installation | form, save, toggle | UUID für neue Zeile; Ereignis; Erfolg nach Zurücklesen; der Schalter kippt automatisches Update oder Status |
regcode | regcode | Einmalcode, 7 Tage gültig; der Server speichert nur den SHA-256-Fingerabdruck |
request | request | Anforderung und Ereignis; gültige SemVer und vorhandenes Release nötig (error_version); die Existenz der Installation prüft der Code nicht |
publish | upload | Zip + Manifest + Signatur + Schlüssel-ID; derselbe Prüf- und Speicherweg wie die CI-Veröffentlichung; Ablage im Archiv |
revoke | revoke | Begründung Pflicht; auf den Inseln liefert die Prüfung revoked, wenn es die installierte Version ist |
settings | settings, publisherkey | Einschalten (beim ersten Mal Hauptschlüssel), Archiv, Cache 1–20 und mindestens 16 MB, Lizenzausnahmen, Sicherheitsübersteuerung, Token 60–3600 s und 1–10 Nutzungen; der Austausch des Publisher-Geheimnisses (Schlüsselversion +1) braucht zusätzlich isSuper() |
release.selfregister: legt die eigene „central“-Installationszeile der zentralen Mehrmandanten-Instanz an und registriert sie lokal (idempotent); Recht: installation und isSuper().
Catalog-API
Endpunkte von api/update: register und publish authentifizieren mit eigenem Code oder Geheimnis, check, authorize, download und report per HMAC-Signatur. Ist die Serverrolle aus: 404.
Berechtigungen
- Alle Schlüssel sind SYSTEM; den Schlüssel
debugprüft der Controller nicht, seine Verwendung ist nicht feststellbar. - Inhaltsbereich: Der Mandant einer Installation ist nur aus den nach dem Unternehmensgruppen-Filter erlaubten Firmen wählbar (
error_scope).
Bekannte Einschränkungen
Noch nicht auf einem produktiven zentralen Server mit echtem Signaturschlüssel und HTTPS-Transport gelaufen.