Configuration

La configuration du Babel Licensing Service est un aspect essentiel de la mise en place d’une infrastructure de licences sûre et fiable. Elle repose notamment sur le fichier appsettings.json, qui permet de définir les différents paramètres du Babel Licensing Service.

Le fichier de configuration appsettings.json du Babel Licensing Service contient différents paramètres de l’application. Voici le détail de ses sections :

1. Serilog : cette section configure la journalisation au moyen de la bibliothèque Serilog. Elle définit les récepteurs (sinks) de journalisation (console et fichier), les niveaux de journalisation des différents espaces de noms et les enrichisseurs qui ajoutent des informations de contexte.
2. AllowedHosts : sert au filtrage des hôtes, pour lier votre application à des noms d’hôte précis.
3. Kestrel : cette section configure le serveur web Kestrel. Elle définit les protocoles par défaut et les points de terminaison du service gRPC.
4. Application : cette section contient les paramètres propres à l’application Babel Licensing Service. Elle indique si gRPC-Web est activé, le chemin du fichier de licence, la clé de signature utilisée pour la validation de licence et la durée de validité du jeton.
5. Email : ces paramètres configurent les notifications par e-mail. Ils comprennent l’activation ou la désactivation de l’envoi d’e-mails, les détails du serveur SMTP (hôte, port, SSL), les identifiants d’authentification et les informations sur l’expéditeur et les destinataires.
6. Licensing : cette section configure différents aspects du système de gestion des licences. Elle définit l’intervalle du signal de présence et les formats des jetons des licences d’activation et des licences flottantes.
7. Reporting : cette section configure le service de rapports et contient la clé de chiffrement utilisée pour la génération des rapports.
8. Database : cette section indique le fournisseur de base de données utilisé par l’application.
9. ConnectionStrings : ces paramètres définissent les chaînes de connexion des différents fournisseurs de base de données (SQL Server, MySQL/MariaDB, SQLite, PostgreSQL).

Chaque section peut être adaptée aux exigences propres à votre déploiement du Babel Licensing Service.

Serilog

Le Babel Licensing Service utilise Serilog pour la journalisation. Voici comment la configuration de Serilog se présente dans le fichier appsettings.json.

"Serilog": {
  "Using": [ "Serilog.Sinks.Console", "Serilog.Sinks.File" ],
  "MinimumLevel": {
    "Default": "Information",
    "Override": {
      "Microsoft": "Warning",
      "System": "Warning",
      "Grpc": "Warning"
    }
  },
  "Enrich": [
    "FromLogContext",
    "WithMachineName",
    "WithThreadId"
  ],
  "WriteTo": [
    { "Name": "Console" },
    {
      "Name": "File",
      "Args": {
        "path": "log.txt",
        "rollingInterval": "Day"
      }
    }
  ]
}

La section "Serilog" est définie en premier ; elle contient plusieurs éléments clés.

Using : cette propriété indique les récepteurs Serilog utilisés pour la journalisation. Dans cet exemple, "Serilog.Sinks.Console" et "Serilog.Sinks.File" indiquent que les journaux sont écrits à la fois dans la console et dans un fichier.

MinimumLevel : définit le niveau de journalisation minimal des différentes sources de journaux. La valeur Default est réglée sur « Information », ce qui signifie que tous les journaux de niveau Information ou supérieur sont capturés. Une section Override définit en outre des niveaux de journalisation propres à certains espaces de noms. Les niveaux de journalisation disponibles sont les suivants :

• Verbose : Verbose est le niveau le plus bavard, rarement (voire jamais) activé en production.
• Debug : Debug sert aux événements internes du système qui ne sont pas forcément observables de l’extérieur, mais qui aident à déterminer comment quelque chose s’est produit
• Information : les événements Information décrivent ce qui, dans le système, correspond à ses responsabilités et à ses fonctions. Ce niveau sert généralement à journaliser les appels gRPC.
• Warning : les événements de niveau Warning sont utilisés lorsque le service est dégradé, menacé ou qu’il se comporte peut-être en dehors de ses paramètres attendus.
• Error : un événement Error est utilisé lorsqu’une fonctionnalité est indisponible ou que les attentes ne sont pas satisfaites.
• Fatal : niveau le plus critique, les événements Fatal exigent une attention immédiate.

Enrich : cette propriété permet d’enrichir les événements de journal avec des informations supplémentaires. Dans cet exemple, les événements de journal sont enrichis avec le contexte de journalisation, le nom de la machine et l’identifiant du thread.

WriteTo : la propriété WriteTo définit les récepteurs dans lesquels les événements de journal sont écrits. Deux récepteurs sont configurés : « Console » et « File ». Le récepteur « Console » écrit les événements de journal dans la console. Le récepteur « File » est configuré avec la propriété « path » réglée sur « log.txt », ce qui indique que les événements de journal sont écrits dans un fichier nommé log.txt. En outre, « rollingInterval » est réglé sur « Day », ce qui signifie qu’un nouveau fichier journal est créé chaque jour.

Pour les paramètres plus spécifiques et les configurations avancées de Serilog (filtrage, sous-journaliseurs et autres fonctionnalités), reportez-vous à la documentation officielle de Serilog. Elle décrit en détail les différentes options de configuration, notamment le filtrage et l’enrichissement des événements de journal et la configuration des sous-journaliseurs.

AllowedHosts

Le paramètre « AllowedHosts » du fichier appsettings.json définit le filtrage des hôtes du Babel Licensing Service. C’est une mesure de sécurité importante, qui limite l’accès au service aux seules URL approuvées. La valeur « * » indique que le filtrage des hôtes est désactivé et que toute URL liée à l’hôte peut accéder au service, ce qui peut convenir aux environnements de développement ou de test. En production, il est toutefois recommandé d’indiquer les hôtes explicitement.

Voici quelques exemples de configuration du paramètre « AllowedHosts » :

1. Autoriser un hôte précis :

   "AllowedHosts": "example.com"

   Cette configuration limite l’accès au Babel Licensing Service aux requêtes adressées au domaine « example.com ». Toutes les requêtes adressées à d’autres hôtes reçoivent une réponse 400 indiquant que le nom d’hôte n’est pas valide.

2. Autoriser plusieurs hôtes :

   "AllowedHosts": "example.com;subdomain.example.com"

   Cette configuration autorise l’accès au Babel Licensing Service uniquement depuis « example.com » et « subdomain.example.com ». Les requêtes provenant de tout autre domaine sont refusées.

3. Autoriser plusieurs hôtes avec une expression générique :

   "AllowedHosts": "*.example.com"

   Cette configuration autorise l’accès au Babel Licensing Service depuis n’importe quel sous-domaine de « example.com ». Par exemple, « subdomain.example.com » et « another.subdomain.example.com » sont autorisés, mais les requêtes provenant d’autres domaines ou sous-domaines sont rejetées.

Il est important de configurer le paramètre « AllowedHosts » avec soin, en fonction de votre environnement de déploiement et de vos exigences de sécurité. En limitant l’accès aux hôtes approuvés, vous renforcez la sécurité et l’intégrité de votre Babel Licensing Service.

Kestrel

La section de configuration « Kestrel » du fichier appsettings.json configure le serveur web Kestrel, qui héberge le Babel Licensing Service. Kestrel est un serveur web multiplateforme qui fournit à votre application un environnement d’hébergement rapide et fiable.

"Kestrel": {
  "EndpointDefaults": {
    "Protocols": "Http1AndHttp2"
  },
  "Endpoints": {
    "gRPC": {
      "Url": "http://localhost:5005",
      "Protocols": "Http2"
    }
  }
}

Dans la section « Kestrel », vous pouvez définir différents paramètres pour personnaliser le comportement du serveur. Voici quelques éléments clés de la configuration de Kestrel :

EndpointDefaults : cette sous-section permet de définir la configuration par défaut de tous les points de terminaison. Vous pouvez y indiquer les protocoles pris en charge par le serveur. Dans l’exemple, « Http1AndHttp2 » indique que les protocoles HTTP/1.1 et HTTP/2 sont tous deux activés par défaut.

Endpoints : cette sous-section permet de définir des points de terminaison précis pour le serveur. Dans l’exemple, le point de terminaison « gRPC » est configuré avec l’URL « http://localhost:5005  » et le protocole « Http2 ». Ce point de terminaison est destiné à traiter les requêtes gRPC adressées au Babel Licensing Service avec le protocole HTTP/2.

Une configuration correcte de Kestrel est essentielle au bon fonctionnement de votre Babel Licensing Service. Vous pouvez personnaliser différents aspects, comme les protocoles, les numéros de port ou les certificats SSL, selon vos besoins.

Pour configurer Kestrel, reportez-vous à la documentation officielle et suivez les bonnes pratiques afin d’obtenir des performances, une sécurité et une fiabilité optimales.

Application

La section de configuration « Application » du fichier appsettings.json permet de personnaliser différents aspects du Babel Licensing Service. Voici chaque paramètre en détail :

"Application": {
    "AdminUsername": "",
    "AdminEmail": "",
    "AdminPassword": "",
    "EnableLegacyUserKeyFallback": false,
    "EnableGrpcWeb": true,
    "LogToDatabase": false,
    "LogRetentionPeriod": "1.00:00:00",
    "LicenseFile": "babel.licenses",
    "SigningKey": "",
    "TokenExpiration": "00:30:00",
    "EnableWebApi": true,
    "EnableWebUI": true,
    "ApiKeyHeaderName": "x-api-key",
    "ApiKeyCacheDuration": "00:03:00",
    "EnableSwagger": true,
    "SwaggerRoutePrefix": "swagger",
    "SwaggerEndpointUrl": "/swagger/v1/swagger.json",
    "GeoLocationService": "IpApiIs",
    "HealthCheckEndPoint": "/health",
    "HealthCheckResponseType": "JSON"
}

AdminUsername : avec AdminEmail et AdminPassword, ce sont les identifiants utilisés pour créer l’utilisateur administrateur initial au premier démarrage du service.

À partir de la version 11.7.0, le service est livré avec ces trois valeurs vides : l’ancienne valeur par défaut admin / admin a été supprimée. L’administrateur initial n’est créé que si AdminUsername et AdminPassword sont tous deux renseignés (AdminEmail est facultatif, mais recommandé). Si l’une des deux valeurs obligatoires est vide, le service démarre quand même et les rôles standard sont créés, mais aucun compte administrateur n’est créé et l’application web reste inutilisable tant que vous n’avez pas renseigné ces paramètres et redémarré le service. Utilisez appsettings.json ou les variables d’environnement BABEL_SERVICE_APPLICATION__ADMINUSERNAME / ..._ADMINPASSWORD / ..._ADMINEMAIL, puis changez le mot de passe dans l’application web et effacez AdminPassword de la configuration une fois le compte créé.

LogToDatabase : active ou désactive le stockage des journaux dans une base de données.

LogRetentionPeriod : indique la durée de conservation des journaux, au format jours.heures:minutes:secondes.

EnableGrpcWeb : en réglant cette valeur sur false, vous désactivez la prise en charge de gRPC Web, ce qui signifie que le serveur n’accepte que les requêtes utilisant le protocole HTTP/2. Notez que certaines plateformes clientes, comme UWP ou Unity, peuvent ne pas prendre en charge HTTP/2 ; activer HTTP/1.1 en plus de HTTP/2 assure donc la compatibilité avec toutes les applications clientes. N’oubliez pas que l’activation des deux protocoles sur le même port nécessite TLS pour la négociation de protocole.

LicenseFile : ce paramètre indique le chemin du fichier de licence utilisé par le Babel Licensing Service. Le fichier de licence contient des informations sur les licences accordées et les fonctionnalités associées. La licence détermine aussi l’édition : une licence dotée de la fonctionnalité d’application web (Data Center) déverrouille l’application web incluse dans le paquet. Les autres licences affichent une page de mise à niveau à l’adresse de l’application web. Pour effectuer la mise à niveau, il suffit de remplacer le fichier et de redémarrer le service.

SigningKey : la clé de signature est un secret utilisé pour signer le jeton du porteur (bearer token) utilisé pour l’authentification. Les clients utilisent ce jeton pour accéder au service gRPC de manière sécurisée. Il est essentiel de garder cette clé confidentielle et de choisir une valeur forte et unique.

À partir de la version 11.7.0, ce paramètre est livré vide (l’ancienne valeur codée en dur a été supprimée). Si SigningKey est vide au démarrage, le service génère pour le processus en cours une clé aléatoire de 32 octets, cryptographiquement sûre, et consigne un avertissement dans le journal. C’est pratique pour les tests en local, mais ne convient pas à la production : chaque redémarrage invalide tous les jetons émis précédemment, et des instances placées derrière un équilibreur de charge rejettent les jetons les unes des autres. Les déploiements de production doivent configurer SigningKey explicitement, soit dans appsettings.json, soit au moyen de la variable d’environnement BABEL_SERVICE_APPLICATION__SIGNINGKEY, avec un secret fort géré en dehors du contrôle de code source.

Configurez toujours SigningKey. Dans les versions actuelles (jusqu’à la 11.8.0 incluse), laisser SigningKey vide ne se limite pas à invalider les jetons à chaque redémarrage : le jeton émis après l’authentification n’est pas accepté lors des appels suivants, si bien que l’activation de licence échoue avec :

RpcException: Status(StatusCode="Unauthenticated", Detail="Bad gRPC response. HTTP status code: 401")

Le journal du service montre une authentification réussie (User '' authenticated, token expires in ...) juste avant l’erreur 401, ce qui fait passer l’échec pour un problème du client. Régler SigningKey sur une valeur stable, non vide, d’au moins 32 caractères résout le problème. Ce point sera corrigé dans une prochaine version ; dans tous les cas, configurer la clé explicitement est le bon paramétrage pour la production.

EnableLegacyUserKeyFallback : rétablit la compatibilité de l’authentification pour les applications clientes générées avec un package NuGet Babel.Licensing antérieur à la version qui corrige le problème d’authentification gRPC par UserKey décrit ci-dessous. La valeur par défaut est false.

Authentification par UserKey sur gRPC. Les applications clientes générées avec des versions de Babel.Licensing antérieures au correctif envoient un identifiant client interne comme nom d’utilisateur de connexion, au lieu d’une valeur vide, lorsqu’elles s’authentifient avec la UserKey d’une licence. Avant la version 11.7.0, un mécanisme de repli côté serveur le tolérait silencieusement ; le renforcement de la sécurité de la version 11.7.0 a supprimé ce repli (voir Composants client), si bien que toute authentification gRPC par UserKey provenant d’un client concerné échoue avec « Invalid username or password », que la clé soit ancienne ou nouvellement générée. Mettez à jour vers le package Babel.Licensing actuel pour corriger le problème à la source. Si vous avez de nombreuses applications clientes déployées et que vous ne pouvez pas toutes les mettre à jour immédiatement, réglez EnableLegacyUserKeyFallback sur true comme solution de transition temporaire : le service accepte de nouveau la requête mal formée et émet le même jeton d’application sans rôle que celui qu’un client concerné obtiendrait autrement (il n’accorde aucun rôle et ne permet pas d’atteindre les points de terminaison de gestion, de sorte qu’il ne confère pas plus de privilèges que l’authentification par UserKey normale). Remettez-le sur false une fois tous les clients mis à jour. Chaque fois que le repli est utilisé, le service consigne un avertissement qui identifie le nom d’utilisateur en cause, ce qui vous permet de suivre les anciens clients restants.

TokenExpiration : ce paramètre détermine la durée de validité du jeton du porteur que le client obtient pour s’authentifier. La valeur « 00:30:00 » correspond à une expiration du jeton au bout de 30 minutes. Passé ce délai, le client doit obtenir un nouveau jeton pour conserver son accès.

EnableWebApi : indique si l’interface Web API est activée.

EnableWebUI : indique si le service sert l’application web. Réglez-le sur false pour exécuter le service en mode API uniquement. L’application web nécessite en outre une licence Data Center.

ApiKeyHeaderName : désigne le nom de l’en-tête HTTP qui transmet la clé API.

ApiKeyCacheDuration : détermine la durée pendant laquelle une clé API reste en cache avant d’être validée de nouveau.

EnableSwagger : active ou désactive l’interface Swagger UI de documentation de l’API.

SwaggerRoutePrefix : le segment d’URL auquel l’interface Swagger UI est accessible.

SwaggerEndpointUrl : le chemin du fichier JSON Swagger qui décrit l’API.

GeolocationService : active la détermination de l’emplacement géographique des clients à partir de leur adresse IP, ce qui facilite le contrôle d’accès par région. Services pris en charge : IpApiIs et MaxMind.

HealthCheckEndPoint : configure le chemin du point de terminaison du service de vérification de l’état. Ce point de terminaison fournit des informations sur l’état du système aux outils de surveillance et aux équilibreurs de charge. S’il n’est pas configuré explicitement, le système utilise « /health » par défaut.

HealthCheckResponseType : détermine le format des réponses renvoyées par le point de terminaison de vérification de l’état du Babel Licensing Service. Ce paramètre accepte deux valeurs : « JSON » ou « TEXT ».

En configurant ces paramètres dans la section « Application », vous adaptez le comportement du Babel Licensing Service à vos besoins : activer ou désactiver la prise en charge de certains protocoles, indiquer le chemin du fichier de licence, sécuriser l’authentification avec une clé de signature et définir la durée de validité du jeton.

IpApi.is

Le service IpApi.is assure la géolocalisation en déterminant l’emplacement géographique des utilisateurs à partir de leur adresse IP, ce qui peut être déterminant pour le contrôle d’accès par région, la journalisation et les analyses. Il offre un moyen rapide et fiable d’associer des adresses IP aux données géographiques correspondantes.

Pour en savoir plus, consultez IpApi.is .

Pour configurer le service IpApiIs avec le Babel Licensing Service, procédez comme suit :

1. Dans la section Application, réglez la propriété GeolocationService sur IpApiIs.
2. Ajoutez la section IpApiIs à appsettings.json pour configurer l’accès au service au moyen d’une clé de licence.

"IpApiIs": {
  "Key": "IPAPI.IS WEB API SERVICE LICENSE KEY"
}

MaxMind

MaxMind propose un service de géolocalisation robuste, qui prend en charge à la fois l’accès par API web et l’utilisation d’une base de données locale. L’intégration de MaxMind donne accès à des données de géolocalisation très précises. Le service, disponible sur MaxMind , permet d’obtenir rapidement et de façon fiable des informations sur les adresses IP.

La base de données locale de MaxMind a l’avantage de supprimer la dépendance aux appels d’API externes, ce qui accélère les requêtes et améliore la fiabilité, en particulier dans les environnements où la connexion à Internet est limitée ou instable. Les bases de données locales réduisent en outre les risques liés aux violations de données ou aux pannes de services externes, et renforcent ainsi la sécurité et le contrôle de la confidentialité.

Pour configurer le service de géolocalisation MaxMind avec le Babel Licensing Service, procédez comme suit :

1. Dans la section Application, réglez la propriété GeolocationService sur MaxMind.
2. Ajoutez la section MaxMind à appsettings.json avec les options de configuration requises.

"MaxMind": {
  "AccountID": "MAXMIND ACCOUNT ID",
  "LicenseKey": "MAXMIND WEB API SERVICE LICENSE KEY"
}

Pour configurer la base de données MaxMind, utilisez la configuration suivante :

"MaxMind": {
  "DatabasePath": "wwwroot\\data\\GeoLite2-City.mmdb"
}

Avec cette configuration, le Babel Licensing Service utilise MaxMind pour la géolocalisation et obtient des informations précises et fiables sur les adresses IP.

Filtrage IP

Dans les paramètres de l’application, le filtrage IP est une mesure de sécurité qui contrôle l’accès au service en fonction des adresses IP. Cette section de la configuration garantit que seuls les utilisateurs approuvés peuvent interagir avec votre application, tandis que le trafic malveillant ou indésirable est géré ou bloqué.

Détails de la configuration :

Blacklist : tableau d’adresses IP auxquelles l’accès est refusé. Les adresses IP de la liste de blocage sont toujours rejetées avec 403 Forbidden, quels que soient les autres paramètres.

Whitelist : tableau d’adresses IP approuvées qui sont exemptées de la limitation du débit contre la force brute. Les adresses IP de la liste d’autorisation ne sont soumises ni au quota de requêtes par adresse IP ni au blocage dynamique ; elles restent soumises à la liste de blocage.

Changement de comportement dans la version 11.7.0. Les versions précédentes traitaient une Whitelist non vide comme une liste d’autorisation exclusive : toute adresse IP absente de la liste était rejetée. À partir de la version 11.7.0, la liste d’autorisation est uniquement une exemption de la limitation du débit : la configurer n’empêche plus les adresses IP non répertoriées d’accéder au service. Si vous devez refuser des adresses IP, ajoutez-les à la Blacklist (les motifs d’expressions régulières sont pris en charge).

Les deux listes prennent en charge la correspondance de motifs par expressions régulières, ce qui élargit les possibilités de filtrage IP.

Protection contre la force brute

Cette sous-section sert à configurer les contre-mesures contre les attaques par force brute :

Enabled : valeur booléenne qui, réglée sur true, active la protection contre les attaques par force brute.

MaxRequestsPerTimeFrame : le nombre maximal de requêtes autorisées depuis une même adresse IP pendant l’intervalle de temps indiqué.

TimeFrameDuration : la période sur laquelle le nombre de requêtes est évalué, au format heures:minutes:secondes.

RequestsBlockDuration : la durée pendant laquelle l’adresse IP en cause est bloquée après avoir dépassé le nombre maximal de requêtes.

Protection de l’authentification

Cette sous-section concerne les tentatives de connexion :

Enabled : réglé sur true, ce paramètre active la surveillance des tentatives d’authentification échouées.

MaxFailedAttempts : le nombre de tentatives de connexion échouées consécutives autorisé avant le déclenchement d’un blocage.

LoginBlockDuration : la durée du blocage imposé à l’adresse IP une fois le nombre maximal de tentatives de connexion échouées atteint.

Webhook

Les paramètres Webhook déterminent si les webhooks sont traités, à quelle fréquence le système recherche de nouveaux événements et comment les nouvelles tentatives sont planifiées.

"Webhook": {
  "Enabled": true,
  "ProcessingInterval": "00:00:30",
  "RetryInterval": "00:05:00"
}

• Processing Interval : l’intervalle par défaut de 30 secondes convient à la plupart des déploiements. Une valeur trop basse peut augmenter la charge de la base de données, tandis qu’une valeur trop élevée peut retarder la remise des webhooks.
• Retry Interval : l’intervalle de 5 minutes entre les nouvelles tentatives laisse aux problèmes réseau temporaires le temps de se résoudre, tout en assurant une remise rapide. Vous pouvez envisager d’augmenter cette valeur si les destinataires de vos webhooks subissent souvent des interruptions plus longues.
• Activation et désactivation : vous pouvez désactiver temporairement tout le traitement des webhooks en réglant Enabled sur false. C’est utile pendant les fenêtres de maintenance ou lors du dépannage de problèmes système.

Email

La section « Email » du fichier appsettings.json configure les paramètres d’e-mail du Babel Licensing Service. Elle permet d’activer l’envoi d’e-mails et d’indiquer les informations nécessaires pour que le service en envoie.

EnableSend : indique si l’envoi d’e-mails est activé ou désactivé. Si la valeur est true, le Babel Licensing Service tente d’envoyer des e-mails selon les paramètres configurés. Si la valeur est false, l’envoi d’e-mails est désactivé.

Host : le nom d’hôte ou l’adresse IP du serveur de messagerie ou du serveur SMTP (Simple Mail Transfer Protocol) utilisé pour envoyer les e-mails. Saisissez l’adresse du serveur approprié.

Port : le numéro du port sur lequel le serveur de messagerie écoute les connexions entrantes. Il s’agit généralement du port du serveur SMTP. Le port SMTP par défaut est 587, mais vous pouvez le modifier selon la configuration de votre serveur de messagerie.

UseSsl : indique si le chiffrement SSL/TLS doit être utilisé pour la connexion au serveur de messagerie. Si la valeur est true, le Babel Licensing Service établit une connexion sécurisée avec SSL/TLS. Si la valeur est false, une connexion non sécurisée est utilisée.

LocalDomain : le nom de domaine local utilisé pour l’adressage des e-mails. Ce paramètre est facultatif et peut rester vide s’il n’est pas nécessaire.

Username : le nom d’utilisateur ou le nom du compte utilisé pour s’authentifier auprès du serveur de messagerie. Saisissez le nom d’utilisateur approprié.

Password : le mot de passe associé au compte de messagerie. Saisissez le mot de passe correspondant au nom d’utilisateur fourni pour l’authentification.

FromUser : le nom d’affichage ou le nom d’utilisateur utilisé comme expéditeur des e-mails. Il peut s’agir d’un nom convivial ou d’un nom d’utilisateur réel.

FromAddress : l’adresse e-mail à partir de laquelle les e-mails sont envoyés. Saisissez une adresse e-mail valide pour l’expéditeur.

To : tableau des adresses e-mail et des noms des destinataires. Chaque objet destinataire doit contenir un champ « Name » pour le nom du destinataire et un champ « Email » pour son adresse e-mail. Ajoutez au tableau les destinataires souhaités.

Licensing

La section « Licensing » du fichier appsettings.json configure différents aspects de la gestion des licences dans le Babel Licensing Service. Elle permet de définir les paramètres liés à la gestion et au comportement des licences.

Dans la section « Licensing », vous pouvez définir des paramètres tels que l’intervalle du signal de présence, le format des jetons d’activation et le format des jetons flottants. Voici ces paramètres en détail :

"Licensing": {
  "HeartbeatInterval": "00:05:00",
  "LicenseIdFormat": "lic{HEX:8}",
  "CustomerCodeFormat": "C-{TOKEN:8}",
  "OrderNumberFormat": "O-{TOKEN:8}",
  "UserKeyFormat": "{TOKEN:5}-{TOKEN:5}-{TOKEN:5}-{TOKEN:5}",
  "ActivationTokenFormat": "actk_{token:12}",
  "FloatingTokenFormat": "fltk_{token:12}",
  "ReclaimInactiveActivationDays": 0
}

Heartbeat Interval : ce paramètre détermine la durée entre deux signaux de présence envoyés par le service de licences. Le signal de présence permet de surveiller la santé et l’état du système de gestion des licences. Un jeton flottant que son client ne libère pas expire au bout de cet intervalle.

ReclaimInactiveActivationDays : nouveauté de la version 12.0. Nombre de jours sans contact au bout desquels une activation peut être récupérée lorsqu’une licence a utilisé tous ses postes et qu’une nouvelle machine demande à s’activer. La valeur par défaut 0 désactive la fonctionnalité. Vous pouvez aussi le définir avec la variable d’environnement BABEL_SERVICE_LICENSING__RECLAIMINACTIVEACTIVATIONDAYS. Lisez Jetons de licence avant de l’activer.

Formats des identifiants et des clés

Les formats indiqués dans la configuration combinent des espaces réservés, qui sont remplacés par des valeurs générées aléatoirement. TOKEN, HEX et DEC sont des types d’espaces réservés, et le nombre qui suit les deux-points (:) indique la longueur de la valeur générée. Les majuscules (TOKEN, HEX) génèrent des valeurs en majuscules, et les minuscules (token, hex) des valeurs en minuscules. DEC désigne les nombres décimaux.

LicenseIdFormat : "lic{HEX:8}". Ce format génère des identifiants de licence qui commencent par « lic », suivi de 8 caractères hexadécimaux aléatoires en majuscules.

CustomerCodeFormat : "C-{TOKEN:8}". Les codes client commencent par « C- », suivi de 8 caractères alphanumériques aléatoires en majuscules.

OrderNumberFormat : "O-{TOKEN:8}". Les numéros de commande commencent par « O- », suivi de 8 caractères alphanumériques aléatoires en majuscules.

UserKeyFormat : "{TOKEN:5}-{TOKEN:5}-{TOKEN:5}-{TOKEN:5}". Les clés utilisateur sont générées sous la forme de quatre groupes de 5 caractères alphanumériques aléatoires en majuscules, séparés par des traits d’union.

Activation Token Format : ce paramètre définit le format des jetons d’activation utilisés dans le processus de gestion des licences. Les jetons d’activation sont générés et fournis aux utilisateurs pour qu’ils activent leurs licences et déverrouillent des fonctionnalités précises. La valeur par défaut « actk_{token:12} » définit le format du jeton d’activation comme le préfixe fixe « actk_ » suivi de 12 caractères aléatoires.

Floating Token Format : comme les jetons d’activation, les jetons flottants servent aux licences flottantes, qui permettent de partager des licences entre plusieurs appareils ou utilisateurs au sein d’un pool défini. Le format des jetons flottants définit la structure de ces jetons. La valeur par défaut « fltk_{token:12} » définit le format du jeton flottant comme le préfixe fixe « fltk_ » suivi de 12 caractères aléatoires.

En configurant la section « Licensing », vous adaptez ces paramètres à vos exigences en matière de licences, et la gestion des licences aux besoins de votre application ou de votre logiciel.

Reporting

La section « Reporting » du fichier appsettings.json configure les paramètres liés aux rapports dans le Babel Licensing Service. Elle permet de définir les paramètres des rapports, notamment les clés de chiffrement qui sécurisent leur transmission et leur stockage.

Dans la section « Reporting », vous pouvez définir des paramètres tels que la clé de chiffrement. Voici ce paramètre en détail :

"Reporting": {
  "EncryptionKey": ""
}

Encryption Key : ce paramètre définit la clé de chiffrement utilisée pour chiffrer et déchiffrer les rapports générés par le Babel Licensing Service. Grâce au chiffrement, les informations sensibles contenues dans les rapports restent protégées contre tout accès non autorisé.

La configuration de la section « Reporting » permet de définir la clé de chiffrement, de sorte que les rapports générés par le service de licences sont chiffrés avec un algorithme cryptographique fort. Ce chiffrement ajoute une couche de sécurité aux rapports et protège les données sensibles contre les menaces et les violations éventuelles.

Database

Babel Licensing Service 12.0 prend en charge SQL Server, MySQL/MariaDB, SQLite et PostgreSQL sous Windows, Linux et macOS. Babel Desktop se connecte au service, pas directement à sa base de données.

Choisir le fournisseur

Définissez Database.Provider avec le nom exact du tableau et renseignez l’entrée correspondante de ConnectionStrings. MariaDB utilise MySQL. Postgres, SQL Server et MariaDB ne sont pas des noms de fournisseur valides. Seule l’entrée choisie est utilisée.

Schéma et migrations

{
  "Database": {
    "Provider": "PostgreSQL",
    "EnableMigration": true,
    "EnableDetailedErrors": false,
    "MaxRetryCount": 5,
    "MaxRetryDelay": "00:00:30"
  }
}

EnableMigration=true applique les migrations du fournisseur au démarrage, avec les droits nécessaires. Avec false, le schéma doit déjà être à jour. Changer de fournisseur ne transfère pas les données. Sauvegardez la base et testez la mise à jour sur une copie. Arrêtez l’ancienne application avant de copier un fichier SQLite 11.8, puis testez le service 12.0 sur la copie.

EnableDetailedErrors contrôle les détails d’erreur supplémentaires. MaxRetryCount et MaxRetryDelay configurent les nouvelles tentatives SQL Server, MySQL et PostgreSQL, pas SQLite. Redémarrez le service après une modification de configuration.

Chaînes de connexion par fournisseur

Fusionnez ces objets JSON complets dans appsettings.json. Remplacez hôtes, chemins, utilisateurs et REPLACE_WITH_PASSWORD. Les exemples réseau nécessitent TLS sur le serveur et un certificat de confiance.

SQL Server

{
  "Database": {
    "Provider": "SQLServer"
  },
  "ConnectionStrings": {
    "SQLServer": "Server=db.example.com,1433;Database=licenses;User ID=babel_licensing;Password=REPLACE_WITH_PASSWORD;Encrypt=True;TrustServerCertificate=False;Connect Timeout=30"
  }
}

Server contient l’hôte et éventuellement le port TCP après une virgule. Database, User ID et Password sélectionnent base et compte. Encrypt=True;TrustServerCertificate=False chiffre et valide le certificat. Sous Windows, les identifiants peuvent être remplacés par Integrated Security=True. LocalDB est réservé au développement Windows.

Référence du pilote: SQL Server .

MySQL / MariaDB

{
  "Database": {
    "Provider": "MySQL"
  },
  "ConnectionStrings": {
    "MySQL": "Server=db.example.com;Port=3306;Database=licenses;User ID=babel_licensing;Password=REPLACE_WITH_PASSWORD;SslMode=VerifyFull;Connection Timeout=30"
  }
}

MySQL et MariaDB utilisent MySQL. Server, Port, Database, User ID et Password définissent la connexion. SslMode=VerifyFull valide certificat et nom du serveur. Pour une autorité privée, ajoutez SslCa=/chemin/ca.pem. Utilisez un compte dédié plutôt que root.

MySQL et MariaDB utilisent le fournisseur MySQL sur tous les frameworks. Les services .NET 6 à 9 utilisent Pomelo.EntityFrameworkCore.MySql ; le service .NET 10 utilise Microting.EntityFrameworkCore.MySql 10.0.11, un fork de Pomelo sous licence MIT qui prend en charge Entity Framework Core 10. À partir de la version 12.0, le service .NET 10 fonctionne avec MySQL et MariaDB. Les chaînes de connexion et le schéma de la base de données sont identiques. Testé avec MySQL 8.4 et MariaDB 11.4.

Référence du pilote: MySQL / MariaDB .

PostgreSQL

{
  "Database": {
    "Provider": "PostgreSQL"
  },
  "ConnectionStrings": {
    "PostgreSQL": "Host=db.example.com;Port=5432;Database=licenses;Username=babel_licensing;Password=REPLACE_WITH_PASSWORD;SSL Mode=VerifyFull;Timeout=30"
  }
}

PostgreSQL utilise Npgsql avec Host, Port, Database, Username et Password. Il s’agit d’une chaîne .NET, pas d’une URL postgresql://. SSL Mode=VerifyFull valide certificat et hôte ; pour une autorité privée, ajoutez Root Certificate=/chemin/ca.pem. La base et le rôle doivent exister avec les droits sur le schéma et les tables.

Référence du pilote: PostgreSQL .

SQLite

{
  "Database": {
    "Provider": "SQLite"
  },
  "ConnectionStrings": {
    "SQLite": "Data Source=/var/lib/babel/licenses.db;Mode=ReadWriteCreate;Foreign Keys=True;Default Timeout=30"
  }
}

SQLite fonctionne dans le Licensing Service, sans serveur de base distinct ni identifiants. Data Source est un chemin absolu sur la machine du service. Mode=ReadWriteCreate crée un fichier absent ; Mode=ReadWrite exige un fichier existant. Le compte du service doit pouvoir écrire dans le fichier et le dossier, y compris journal/WAL. Dans Docker, utilisez un volume persistant accessible en écriture.

Chemin Windows échappé pour JSON :

{
  "ConnectionStrings": {
    "SQLite": "Data Source=C:\\Babel\\Data\\licenses.db;Mode=ReadWriteCreate;Foreign Keys=True;Default Timeout=30"
  }
}

Foreign Keys=True active les clés étrangères. Default Timeout=30 est le délai des commandes en secondes. Un chemin relatif comme licenses.db dépend du répertoire de travail du service.

Configurez et démarrez séparément le Licensing Service, même avec SQLite local. Babel Desktop ne l’installe, ne le démarre et ne l’arrête pas ; le profil Desktop utilise son endpoint HTTP/HTTPS.

Référence du pilote: SQLite .

Variables d’environnement

Les variables préfixées par BABEL_SERVICE_ remplacent le JSON. Deux traits de soulignement séparent les niveaux. Définissez uniquement la variable de connexion du fournisseur choisi. Stockez les vrais secrets dans le gestionnaire de secrets du déploiement.

export BABEL_SERVICE_Database__Provider=PostgreSQL
export BABEL_SERVICE_ConnectionStrings__PostgreSQL='Host=db.example.com;Port=5432;Database=licenses;Username=babel_licensing;Password=REPLACE_WITH_PASSWORD;SSL Mode=VerifyFull'

Les valeurs contenant un point-virgule doivent être entre guillemets selon la syntaxe du pilote. Échappez aussi les guillemets internes et les barres obliques inverses Windows dans JSON.