Démarrer
Vue d'ensemble
Ce qu'est Keyright, en quoi Keyright Cloud et l'auto-hébergement diffèrent, et une carte de ce manuel — un service d'émission plus des SDK natifs pour les fichiers de licence hors ligne et l'activation en ligne.
Keyright est une infrastructure de licences pour les éditeurs de logiciels : un service d’émission plus des SDK natifs pour .NET, Node.js, Python et Java que votre application embarque pour vérifier les licences — ou, pour tout autre langage, une petite API HTTP que vous appelez directement. Il émet des fichiers de licence hors ligne signés et des leases d’activation en ligne, applique le verrouillage par machine et les sièges, transporte des droits/niveaux, et est multi-tenant avec des clés de signature RSA par tenant. Chaque SDK vérifie le même format signé, de sorte qu’une gamme de produits multi-langages partage un seul tenant et une seule clé publique. Il est compatible au niveau du protocole avec le système de licences de Nebula.NET.
Le service d’émission inclut un tableau de bord web — voici à quoi ressemble votre espace de travail une fois que vous avez créé un produit et émis quelques licences :
Keyright Cloud ou auto-hébergé
Keyright fonctionne dans l’un de deux modes de déploiement, et ce manuel couvre les deux côte à côte.
| Keyright Cloud | Auto-hébergé |
|---|---|
| Nous hébergeons le service d’émission à keyright.delta1labs.com. Inscrivez-vous, créez un espace de travail et commencez à émettre des clés — rien à déployer ni à exploiter. | Vous exécutez le service d’émission dans votre propre infrastructure (y compris totalement isolée du réseau, air-gapped). Vous êtes propriétaire des données et de la disponibilité, et le matériel de licence ne quitte jamais votre réseau. |
La partie sur laquelle vous construisez est identique dans les deux cas : le SDK que vous embarquez, le format signé des licences et des leases, et la clé publique que vous livrez ne changent pas. Seules deux choses diffèrent — l’URL du service vers laquelle pointe votre application et l’identifiant d’administration que vous utilisez pour gérer l’espace de travail. Tout au long de la documentation, $BASE est l’URL de votre service d’émission et $TOKEN est votre identifiant d’administration (envoyé dans l’en-tête X-Admin-Token).
Comment utiliser ce manuel
- Premiers pas — le parcours éditeur de bout en bout pour Cloud et auto-hébergé : obtenir un service d’émission, créer un produit, mettre le SDK dans votre application, émettre une licence et passer en production.
- Cas d’usage — un guide par tâche : essais gratuits, activation et sièges, verrouillage de fonctionnalités, vente de mises à niveau, mesure d’usage et crédits, traitement des commandes de boutique, révoquer / renouveler / expiration et hors ligne et isolé (air-gapped).
- Intégration du SDK — le parcours client complet par langage : .NET, Node.js, Python, Java, ou l’API HTTP brute.
- Auto-hébergement — exécutez et licenciez votre propre instance : le guide de déploiement et licence et éditions.
- Référence — la référence rapide du tableau de bord (où effectuer chaque tâche dans l’interface web) et la référence de l’API HTTP.
Ci-dessous, les mêmes destinations regroupées selon ce que vous cherchez à faire.
Intégrer les licences dans votre application
- Premiers pas — le parcours de bout en bout : obtenir une clé de signature, émettre votre première licence, la vérifier dans votre application (hors ligne + en ligne), et une liste de contrôle de mise en production.
- Choisissez votre SDK — un parcours client complet par langage : .NET, Node.js, Python, Java. Pas de SDK pour votre langage ? Utilisez l’API HTTP directement (Go, Rust, C++, PHP…) — y compris comment vérifier vous-même la signature d’une lease.
- Essais gratuits en libre-service — activez des essais par produit, laissez les clients obtenir eux-mêmes une clé d’essai depuis votre propre site, et distribuez des fichiers d’essai hors ligne aux évaluateurs isolés du réseau (air-gapped).
Comprendre le modèle
- Activation et désactivation — chaque chemin d’activation et de désactivation pour les licences d’essai, annuelles (à durée) et perpétuelles : en ligne, hors ligne/isolé (air-gapped) et côté éditeur — et exactement ce que votre application voit dans chaque cas.
- Sécurité et modèle de lease — l’explication honnête de la façon dont les clés et les leases sont sécurisées, pourquoi une licence mono-poste ne peut pas tourner sur deux machines même hors ligne, ce que « inviolable » signifie vraiment, et comment la lease de courte durée se renouvelle et se comporte hors ligne.
Exploiter et administrer
- Référence rapide du tableau de bord — un court index du tableau de bord web à
/dashboard: comment se connecter, les vues Basique / Intermédiaire / Avancé, et un tableau tâche → où la faire. - Référence de l’API HTTP — une carte lisible de chaque endpoint (Runtime
/v1/*, Admin/admin/*, Platform/platform/*, Auth/auth/*, Plans, Webhooks) avec méthode, chemin et authentification.
Les concepts clés en un paragraphe
Un tenant est un espace de travail éditeur isolé avec sa propre clé de signature (RSA ; la clé privée est conservée chiffrée au repos et ne quitte jamais le service — votre application n’embarque jamais que la clé publique). Un tenant définit des produits, chacun avec des niveaux (nombres de sièges + modèles de droits). Une licence est émise pour un produit/niveau à un licencié, avec un nombre de sièges et une expiration facultative. Votre application est soit livrée avec un fichier de licence hors ligne signé, soit effectue une activation en ligne : elle envoie en POST la clé de licence + un identifiant de machine stable à /v1/activate et reçoit en retour une lease signée de courte durée liée à cette machine ; le SDK vérifie la lease avec la clé publique embarquée et se réactive avant l’expiration. Les plans (Free/Starter/Growth/Scale/Enterprise) régissent les quotas d’un tenant (licences actives, produits).