Manuelle Entwicklungs- und Integrationsanleitung (9 Sprachen, keine KI erforderlich)

Diese Anleitung gilt für den Licentivo-Anbieter. Händler mit einem anderen Lizenzsystem können in der Administration unter „Lizenzauswahl und Anpassung“ einen benutzerdefinierten Dienst wählen, ihn nach der benutzerdefinierten Lizenzierungs-API und dem Integrationsablauf anbinden und weiterhin das SDK ihres eigenen Lizenzsystems verwenden.

Die aktuellen unveröffentlichten Änderungen verwenden Kontoidentitätsaustausch; Zuständigkeiten und Migrationseinschränkungen siehe Kaufzeitraum und Konto-SDK-Grenze. Launch berechnet den Kaufzeitraum; das Licentivo SDK führt die Autorisierung aus.

Nur das Launch-Integrationspaket der jeweiligen Sprache installieren. Das Launch-Paket enthält das offizielle SDK, den Standardadapter und die Linkkonfiguration; die offizielle Lizenzierungsadresse ist fest auf https://www.licentivo.com gesetzt. Das Programm meldet sich mit dem Konto an, das der Käufer im aktuellen Launch-Shop registriert hat.

Ausgefüllten Initialisierungscode erhalten

1. In der Launch-Administration Software, Verkaufsplan und Licentivo-Lizenzrichtlinie verknüpfen und in der jeweiligen Umgebung veröffentlichen.
2. Anwendungsintegration → Integrationsprüfung und Code öffnen und Software, Sprache sowie Test-/Produktionsumgebung wählen.
3. Auf „Produktinformationen lesen und Integrationscode erzeugen“ klicken. Launch liest automatisch die aktuelle öffentliche Site-Adresse, bestehende Produktzuordnung und öffentliche Signaturschlüssel.
4. Die Verbindungsfunktion der Seite in das eigene Projekt kopieren und Oberfläche und Geschäftsaufrufe wie unten beschrieben manuell erstellen. Alternativ nach Prüfung der automatisch ausgefüllten Parameter das Connect/connect der jeweiligen Sprache selbst aufrufen.

Zwei interne Produkt-IDs müssen weder manuell eingegeben noch launch-config.json oder product.json erzeugt werden. Die Seite kann die Quellcode-Verbindungsfunktion speichern. Die private Serverdatei config.yaml dient nur dem Start des Launch-Dienstes und darf nicht mit Kundensoftware veröffentlicht werden.

Die Site-Adresse stammt aus der gültigen öffentlichen Adresse der aktuellen Instanz (Startkonfiguration public_url oder gültige öffentliche Adresse in den Website-Einstellungen der Administration). Sie kann eine Domain oder IP-Adresse mit Port sein, muss aber ein Protokoll enthalten; produktive Integration verwendet gültiges HTTPS. Die Listen-Adresse http_addr ist keine Kundenadresse. Nach Änderung von Site-Adresse, Produktzuordnung oder Umgebung die Verbindungsfunktion von der aktuellen Site neu beziehen; Sitzungen und Caches der alten Site dürfen nicht als Autorisierung der neuen Site verwendet werden.

Die zwei Produktkennungen sind eine vorhandene interne Zuordnung: Launch-Softwareprodukt und Licentivo-Lizenzprodukt. Die Integrationsseite füllt sie anhand der gewählten Software automatisch aus; Käufer geben nur ihr Shopkonto ein. Öffentliche Signaturschlüssel liest der Server über die konfigurierte Licentivo-Verbindung; Management-Schlüssel und Kundenlizenz-Zugangsdaten gelangen nicht in den Quellcode.

Zweck von Connect/connect

Connect/connect bezeichnet in verschiedenen Sprachen das Erstellen eines Launch-Anwendungsclients. Go, C# und einige native Schnittstellen verwenden Connect mit großem Anfangsbuchstaben; Python, JavaScript, Ruby und andere Sprachen verwenden stilgemäß connect. Die von der Administration erzeugten connectLaunch(), connect_launch() oder LaunchConnection.Open() sind Projektfunktionen mit vorausgefüllten öffentlichen Parametern und rufen intern den jeweiligen Spracheinstieg auf.

Die Verbindung führt nur die Initialisierung durch: Sie validiert Shopadresse, Produktzuordnung, Umgebung und öffentliche Signaturschlüssel, erstellt den Launch-Client und konfiguriert das im Paket enthaltene offizielle Licentivo SDK. Sie prüft weder die Kundenidentität noch gibt sie kostenpflichtige Funktionen unmittelbar frei. Die vollständige Reihenfolge lautet:

Connect/connect → Login or Restore → RunFeature → Logout / Close
                                       └──────────→ ReleaseDevice (explicit device unlink only)

Während der Anwendungslaufzeit sollte dasselbe Clientobjekt beibehalten werden, damit das SDK Heartbeats und Floating-Plätze ordnungsgemäß verarbeitet. Normales Schließen behält die Gerätebindung; ausdrücklicher Kunden-Logout und der Kompatibilitätseinstieg ReleaseDevice rufen denselben Logout-Ablauf des offiziellen SDK auf.

Installation und Initialisierungseinstiege

Die öffentlichen Installationsprüfungen von 0.1.6 für neun Sprachen sind vollständig bestanden (9/9); alle Installationsmethoden der folgenden Tabelle wurden geprüft. GitHub Release bietet ebenfalls native Pakete und Offline-Dateien; Verwendung siehe Installationsanleitung für heruntergeladene Pakete.

Öffentlicher Quellcode und README-Dateien aller Sprachen stehen im Launch SDK-Repository, native Pakete und Offline-Dateien im v0.1.6 Release, öffentliche Installationsergebnisse unter Registry-Verifikation für neun Sprachen. Die README jedes Pakets enthält Installationsbefehle und API. Das JavaScript-Paket enthält TypeScript-Deklarationen. Gewöhnliche Sprachabhängigkeiten werden vom Paketmanager aufgelöst, etwa cryptography für Python, BouncyCastle für C# und base64 für Ruby; ein offizielles SDK-Paket muss nicht installiert werden.

Der öffentliche Go-Modulname ist github.com/spf86/licentivo-launch-sdk, der Importpfad github.com/spf86/licentivo-launch-sdk/pkg/launchclient; die Anwendung benötigt kein lokales replace. Das native Windows-Paket verwendet amd64 GNU/MinGW, außerdem gibt es ein natives Linux-amd64-Paket. Ruby-Plattformpakete und Windows-Distributionen von Rust/native enthalten curl; Quellbuilds anderer Plattformen benötigen gewöhnliche C11-, curl/OpenSSL-Entwicklungsabhängigkeiten. Hinweise zu Plattform-Toolchains stehen in den Paket-README-Dateien.

Anmeldung und geschützte Operationen

Die folgenden Ausschnitte verwenden die im vorherigen Schritt kopierte Verbindungsfunktion. email und password stammen aus der eigenen Anmeldeoberfläche; das Passwort darf nicht in Quellcode oder Konfiguration geschrieben werden. export muss durch einen in der Planrichtlinie tatsächlich vorhandenen Funktionsnamen ersetzt werden.

Go

app, err := connectLaunch()
if err != nil { return err }
defer app.Close()
if _, err := app.Login(ctx, email, password); err != nil { return err }
return app.RunFeature("export", func() error {
    return exportReport()
})

ctx verwendet den Anwendungslaufzeitkontext; der Heartbeat darf nicht unmittelbar nach Ende der Anmeldeanfrage abgebrochen werden. Netzwerkoperationen gehören in einen Hintergrundthread. Zur Wiederherstellung Restore(ctx), zum Konto-Logout Logout(ctx) und zur Gerätefreigabe ReleaseDevice(ctx) aufrufen.

Python

with connect_launch() as app:
    app.login(email, password)
    result = app.run_feature("export", export_report)

restore() stellt eine bestehende sichere Sitzung wieder her; ohne Sitzung die Anmeldeoberfläche anzeigen. logout() bereinigt das Konto; release_device() gibt das Gerät ausdrücklich frei. Synchrone Netzwerkoperationen dürfen die Desktop-Ereignisschleife nicht blockieren.

C# / .NET

await using var app = LaunchConnection.Open();
await app.Login(email, password);
await app.RunFeature("export", async () => {
    await ExportReport();
});

await Restore(), await Logout() und await ReleaseDevice() verwenden. Den SDK-Lebenszyklus während der Anwendungslaufzeit erhalten und asynchrone Oberflächenabläufe verwenden.

Java

try (var app = LaunchConnection.open()) {
    app.login(email, passwordChars);
    app.runFeature("export", () -> exportReport());
}

Passwörter verwenden char[]. restore() gibt ohne Sitzung den Fehler NO_SESSION zurück; die Anmeldeoberfläche sollte angezeigt werden. Andere Fehler dürfen nicht als Autorisierung gelten. logout() und releaseDevice() sind unterschiedliche Operationen. try-with-resources übernimmt das Schließen.

JavaScript / Node.js / TypeScript

const app = connectLaunch();
try {
  await app.login(email, password);
  const result = await app.runFeature('export', () => exportReport());
} finally {
  await app.close();
}

restore() gibt ohne Sitzung null zurück; erst nach normaler Wiederherstellung darf Geschäftslogik ausgeführt werden. Der boolesche Rückgabewert von logout() zeigt an, ob der Remote-Logout bestätigt wurde; ein Fehler bei der Gerätefreigabe muss angezeigt werden. Der Code läuft in Node.js, im Electron-Hauptprozess oder einem vertrauenswürdigen Backend; Browser und Electron-Renderer speichern keine Autorisierungs-Zugangsdaten.

Rust

let mut app = connect_launch()?;
app.login(&email, &password)?;
let result = app.run_feature("export", || {
    export_report()?;
    Ok(())
})?;
app.close();

Der Callback gibt Result<T, Failure> zurück. restore(), logout() und release_device() geben Ergebnisse zurück; Fehler müssen behandelt werden. Drop schließt ebenfalls die Laufzeit. Der native Standardkern wird durch build.rs kompiliert und gelinkt; das offizielle SDK muss nicht selbst gelinkt werden.

Ruby

app = connect_launch
begin
  app.login(email, password)
  result = app.run_feature('export') { export_report }
ensure
  app.close
end

restore stellt eine Sitzung wieder her, logout meldet das Konto ab, release_device gibt das Gerät frei. Geschützte Operationen verwenden Codeblöcke; Ausnahmen dürfen nicht in Erfolg umgewandelt werden.

C

static int export_action(void *context) {
    return export_report(context); /* Return 1 only on success. */
}

launch_application *app = connect_launch();
if (!app) return 0;
int ok = launch_application_login(app, email, password);
if (ok) ok = launch_application_run_feature(app, "export", export_action, context);
/* Check launch_application_error(app) on failure; never log credentials. */
launch_application_close(app);
return ok;

launch_application_restore hat drei Zustände: 1 wiederhergestellt, 0 keine Sitzung, -1 Fehler. Nur ohne Sitzung normal die Anmeldung anzeigen; Ablehnung oder Ausnahme darf nicht als Erfolg gelten. Auch Rückgabewerte von logout und release_device müssen geprüft werden.

CMake importiert nur Launch:

find_package(LicentivoLaunch CONFIG REQUIRED)
add_executable(myapp main.c)
licentivo_launch_link(myapp)

C++

auto app = connectLaunch();
app.Login(email.c_str(), password.c_str());
app.RunFeature("export", [&] { exportReport(); });

Restore(), Logout(), ReleaseDevice() folgen der C++-Ausnahmesemantik. RAII-Destruktion übernimmt das Schließen. CMake verwendet licentivo_launch_link(myapp CXX); Launch behandelt SDK-Linking und Laufzeitbibliotheken des Distributionspakets automatisch.

Lebenszyklus, sicherer Speicher und Fehler

Das Erstellen des Verbindungsobjekts initialisiert nur. Das Programm muss sich erfolgreich anmelden oder wiederherstellen und bei jeder Geschäftsoperation den Funktionsschutz-Callback verwenden. Bezahlte Bestellung, vorhandene Sitzung oder anklickbare Schaltfläche ersetzen keine SDK-Prüfung.

Standardmäßig werden Sitzungen nur im Speicher gehalten. Gemerkte Anmeldung benötigt sicheren Speicher: Go, Python, C# und natives C/C++ bieten Windows-DPAPI für den aktuellen Benutzer; Java, Node, Rust und Ruby bieten AES-GCM-Speicher mit vom Aufrufer verwaltetem Schlüssel. Plattformübergreifende Anwendungen sollten den System-Zugangsdatenstore anbinden. Schlüssel und Chiffretext dürfen nicht im selben gewöhnlichen Verzeichnis liegen.

Normales Schließen bewahrt die ausdrücklich gemerkte Sitzung und stoppt die Laufzeit. Konto-Logout ruft zuerst den einheitlichen Logout des offiziellen SDK auf und bereinigt dann den Launch-eigenen Kontodatensatz. ReleaseDevice ist ein Kompatibilitätseinstieg desselben Ablaufs; solange der Remote-Widerruf aussteht, darf keine erfolgreiche Freigabe gemeldet werden. Cache-Verzeichnis und Logout-Wiederherstellungsjournal des offiziellen SDK nicht bereinigen. Launch-Sitzungsschutz bedeutet nicht, dass alle Gerätedateien des offiziellen SDK verschlüsselt sind; Cache-Verzeichnisberechtigungen einschränken.

Ausdrückliche 401/403/404, falsches Konto, Abbruch oder Ratenbegrenzung dürfen nicht in einen erfolgreichen Offline-Zugriff umgewandelt werden. Erstaktivierung und Richtlinien ohne Offline-Nutzung erfordern weiterhin eine Verbindung. Ist die Serverdomain/IP nicht erreichbar, ein Verbindungsproblem anzeigen und nicht heimlich eine andere Site kontaktieren.

Abnahme und Referenzen

Echte Anmeldung, Autorisierung des zugehörigen Kontos, geschützte Operationen, Wiederherstellung nach Neustart, gültiges Offline-Verhalten und Offline-Ablauf, Cache-Manipulation, Logout, Kontowechsel und Gerätefreigabe prüfen. Diese Anleitung erfordert keine KI. Testtools und externe Abnahmegrenzen siehe acceptance.md; lokale Pakete und Build-Anweisungen siehe integration-packages.md.

Konfigurationsprüfung, Codeerzeugung und lokale Tests beweisen nicht automatisch erfolgreiche echte Zahlung, Lizenzausstellung oder Aktivierung auf der offiziellen Website. Externer Shop und Zahlungs-Sandbox müssen nach Konfiguration separat abgenommen werden.