Configurazione

La configurazione del Babel Licensing Service è un aspetto essenziale per predisporre un’infrastruttura di licenze sicura e affidabile. Un elemento chiave di questa configurazione è il file appsettings.json, che ti permette di definire vari parametri e impostazioni del servizio.

Il file di configurazione appsettings.json del Babel Licensing Service contiene diverse impostazioni dell’applicazione. Ecco una panoramica delle sezioni:

1. Serilog: questa sezione configura le impostazioni di logging tramite la libreria Serilog. Specifica i sink dei log (console e file), i livelli di log per i diversi namespace e gli enricher che aggiungono informazioni contestuali.
2. AllowedHosts: serve al filtro degli host, per associare la tua app a nomi host specifici.
3. Kestrel: questa sezione configura le impostazioni del server web Kestrel. Definisce i protocolli predefiniti e gli endpoint del servizio gRPC.
4. Application: questa sezione contiene le impostazioni specifiche dell’applicazione Babel Licensing Service. Specifica se gRPC-Web è abilitato, il percorso del file di licenza, la chiave di firma per la convalida della licenza e la durata di validità del token.
5. Email: queste impostazioni configurano le notifiche email. Comprendono le opzioni per abilitare o disabilitare l’invio delle email, i dettagli del server SMTP (host, porta, SSL), le credenziali di autenticazione e le informazioni su mittente e destinatari.
6. Licensing: questa sezione configura vari aspetti del sistema di licenze. Specifica l’intervallo di heartbeat e i formati dei token per l’attivazione e per le licenze flottanti.
7. Reporting: questa sezione configura il servizio di reporting e include la chiave di cifratura usata per la generazione dei report.
8. Database: questa sezione specifica il provider di database usato dall’applicazione.
9. ConnectionStrings: queste impostazioni definiscono le stringhe di connessione per i diversi provider di database (SQL Server, MySQL/MariaDB, SQLite, PostgreSQL).

Ogni sezione può essere personalizzata in base ai requisiti specifici della distribuzione del Babel Licensing Service.

Serilog

Nel Babel Licensing Service i log sono gestiti con Serilog. Vediamo più da vicino com’è impostata la configurazione di Serilog nel file 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"
      }
    }
  ]
}

Per prima cosa definiamo la sezione "Serilog", che contiene alcuni elementi chiave.

Using: questa proprietà specifica i sink di Serilog usati per i log. In questo esempio abbiamo "Serilog.Sinks.Console" e "Serilog.Sinks.File", quindi i log vengono scritti sia sulla console sia su un file.

MinimumLevel: definisce il livello minimo di log per le diverse origini dei log. Il valore Default è impostato su “Information”, cioè vengono acquisiti tutti i log di livello Information o superiore. C’è inoltre una sezione Override che specifica livelli di log particolari per determinati namespace. I livelli di log disponibili sono:

• Verbose: Verbose è il livello più dettagliato, abilitato raramente (o mai) in produzione.
• Debug: Debug è usato per gli eventi interni del sistema che non sono necessariamente osservabili dall’esterno ma sono utili per capire come è accaduto qualcosa
• Information: gli eventi Information descrivono ciò che accade nel sistema in relazione alle sue responsabilità e funzioni. In genere è usato per registrare le chiamate gRPC.
• Warning: gli eventi di livello Warning vengono usati quando il servizio è degradato, a rischio o potrebbe comportarsi al di fuori dei parametri previsti.
• Error: un evento Error viene usato quando una funzionalità non è disponibile o le aspettative non sono rispettate.
• Fatal: è il livello più critico, e gli eventi Fatal richiedono attenzione immediata.

Enrich: questa proprietà permette di arricchire gli eventi di log con informazioni aggiuntive. In questo esempio gli eventi di log vengono arricchiti con informazioni come il contesto di log, il nome del computer e l’ID del thread.

WriteTo: la proprietà WriteTo definisce i sink su cui vengono scritti gli eventi di log. Sono configurati due sink: “Console” e “File”. Il sink “Console” scrive gli eventi di log sulla console. Il sink “File” è configurato con la proprietà “path” impostata su “log.txt”, quindi gli eventi di log vengono scritti in un file chiamato log.txt. Inoltre “rollingInterval” è impostato su “Day”, cioè ogni giorno viene creato un nuovo file di log.

Per impostazioni più specifiche e configurazioni avanzate relative a filtri, sub-logger e altre funzionalità di Serilog, ti consigliamo di consultare la documentazione ufficiale di Serilog. La documentazione di Serilog fornisce informazioni dettagliate sulle varie opzioni di configurazione, tra cui il filtro degli eventi di log, l’arricchimento e la configurazione dei sub-logger.

AllowedHosts

La configurazione “AllowedHosts” nel file appsettings.json serve a specificare il filtro degli host per il Babel Licensing Service. È una misura di sicurezza importante per limitare l’accesso al servizio ai soli URL attendibili. Il valore ”*” indica che il filtro degli host è disabilitato e che qualsiasi URL associato all’host può accedere al servizio, cosa che può andare bene negli ambienti di sviluppo o di test. In produzione, invece, è consigliabile specificare gli host in modo esplicito.

Ecco alcuni esempi di come puoi configurare l’impostazione “AllowedHosts”:

1. Consentire un host specifico:

   "AllowedHosts": "example.com"

   Questa configurazione limita l’accesso al Babel Licensing Service alle sole richieste dirette al dominio “example.com”. Tutte le richieste verso altri host restituiscono una risposta 400, che segnala un nome host non valido.

2. Consentire più host:

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

   Questa configurazione consente l’accesso al Babel Licensing Service solo da “example.com” e “subdomain.example.com”. Le richieste provenienti da qualsiasi altro dominio vengono rifiutate.

3. Consentire più host con un’espressione con carattere jolly:

   "AllowedHosts": "*.example.com"

   Questa configurazione consente l’accesso al Babel Licensing Service da qualsiasi sottodominio di “example.com”. Per esempio, “subdomain.example.com” e “another.subdomain.example.com” sono consentiti, mentre le richieste provenienti da altri domini o sottodomini vengono rifiutate.

È importante valutare e configurare con attenzione l’impostazione “AllowedHosts” in base al tuo ambiente di distribuzione e ai tuoi requisiti di sicurezza. Limitando l’accesso agli host attendibili puoi migliorare la sicurezza e l’integrità del tuo Babel Licensing Service.

Kestrel

La sezione di configurazione “Kestrel” nel file appsettings.json serve a configurare il server web Kestrel, che ospita il Babel Licensing Service. Kestrel è un server web multipiattaforma che offre alla tua applicazione un ambiente di hosting veloce e affidabile.

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

Nella sezione “Kestrel” puoi definire varie impostazioni per personalizzare il comportamento del server. Vediamo alcuni elementi chiave della configurazione di Kestrel:

EndpointDefaults: questa sottosezione ti permette di impostare le configurazioni predefinite per tutti gli endpoint. Qui puoi specificare i protocolli supportati dal server. Nell’esempio, “Http1AndHttp2” indica che i protocolli HTTP/1.1 e HTTP/2 sono entrambi abilitati per impostazione predefinita.

Endpoints: questa sottosezione ti permette di definire endpoint specifici per il server. Nell’esempio, l’endpoint “gRPC” è configurato con l’URL “http://localhost:5005 ” e il protocollo “Http2”. Questo endpoint è pensato per gestire le richieste gRPC rivolte al Babel Licensing Service con il protocollo HTTP/2.

Configurare correttamente Kestrel è essenziale per il buon funzionamento del tuo Babel Licensing Service. Puoi personalizzare vari aspetti, come i protocolli, i numeri di porta, i certificati SSL e altro ancora, per soddisfare i tuoi requisiti.

Quando configuri Kestrel è importante consultare la documentazione ufficiale e seguire le procedure consigliate, per ottenere prestazioni, sicurezza e affidabilità ottimali.

Application

La sezione di configurazione “Application” in appsettings.json ti permette di personalizzare vari aspetti del Babel Licensing Service. Vediamo ogni impostazione in dettaglio:

"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: insieme a AdminEmail e AdminPassword, sono le credenziali usate per creare l’utente amministratore iniziale al primo avvio del servizio.

A partire dalla 11.7.0 il servizio viene distribuito con tutti e tre i valori vuoti: il valore predefinito storico admin / admin è stato rimosso. L’amministratore iniziale viene creato solo quando AdminUsername e AdminPassword sono entrambi non vuoti (AdminEmail è facoltativo ma consigliato). Se uno dei due valori obbligatori è vuoto, il servizio si avvia comunque e i ruoli standard vengono creati, ma non viene creato alcun account amministratore e l’applicazione web non può essere usata finché non compili le impostazioni e riavvii il servizio. Usa appsettings.json oppure le variabili d’ambiente BABEL_SERVICE_APPLICATION__ADMINUSERNAME / ..._ADMINPASSWORD / ..._ADMINEMAIL, poi cambia la password dall’applicazione web e rimuovi AdminPassword dalla configurazione una volta che l’account esiste.

LogToDatabase: attiva o disattiva il salvataggio dei log in un database.

LogRetentionPeriod: specifica per quanto tempo i log vengono conservati, nel formato giorni.ore:minuti:secondi.

EnableGrpcWeb: impostando questo valore su false disabiliti il supporto gRPC Web, e il server accetta solo le richieste che usano il protocollo HTTP/2. Tieni presente che alcune piattaforme client, come UWP o Unity, potrebbero non supportare HTTP/2, quindi abilitare HTTP/1.1 insieme a HTTP/2 garantisce la compatibilità con tutte le applicazioni client. Ricorda che abilitare entrambi i protocolli sulla stessa porta richiede TLS per la negoziazione del protocollo.

LicenseFile: questa impostazione specifica il percorso del file di licenza usato dal Babel Licensing Service. Il file di licenza contiene informazioni sulle licenze concesse e sulle funzionalità associate. La licenza determina anche l’edizione: una licenza con la funzionalità dell’applicazione web (Data Center) sblocca l’applicazione web inclusa nel pacchetto. Con le altre licenze, all’indirizzo dell’applicazione web compare una pagina di upgrade. Per l’upgrade basta sostituire il file e riavviare il servizio.

SigningKey: la chiave di firma è un segreto usato per firmare il token bearer di autenticazione. I client usano questo token per accedere in modo sicuro al servizio gRPC. È essenziale mantenere riservata questa chiave e scegliere un valore robusto e univoco.

A partire dalla 11.7.0 questa impostazione viene distribuita vuota (il valore storico scritto nel codice è stato rimosso). Se all’avvio SigningKey è vuota, il servizio genera per il processo corrente una chiave di 32 byte crittograficamente casuale e scrive un avviso nel log. È comodo per i test in locale ma non è adatto alla produzione: ogni riavvio invalida tutti i token emessi in precedenza, e le istanze dietro un bilanciatore del carico rifiutano l’una i token dell’altra. Le distribuzioni di produzione devono configurare esplicitamente SigningKey, in appsettings.json oppure tramite la variabile d’ambiente BABEL_SERVICE_APPLICATION__SIGNINGKEY, con un segreto robusto gestito al di fuori del controllo del codice sorgente.

Configura sempre SigningKey: nelle build attuali (fino alla 11.8.0 inclusa), lasciare SigningKey vuota non si limita a invalidare i token a ogni riavvio. Il token emesso dopo l’autenticazione non viene accettato nelle chiamate successive, quindi l’attivazione della licenza fallisce con:

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

Il log del servizio mostra un’autenticazione riuscita (User '' authenticated, token expires in ...) subito prima del 401, e questo fa sembrare l’errore un problema del client. Per risolverlo, imposta SigningKey su un qualsiasi valore stabile e non vuoto di almeno 32 caratteri. Il problema sarà corretto in una versione futura; configurare esplicitamente la chiave è in ogni caso l’impostazione corretta per la produzione.

EnableLegacyUserKeyFallback: ripristina la compatibilità di autenticazione per le applicazioni client compilate con un pacchetto NuGet Babel.Licensing precedente alla versione che corregge il problema di autenticazione con chiave utente (UserKey) su gRPC descritto qui sotto. Il valore predefinito è false.

Autenticazione con chiave utente (UserKey) su gRPC: le applicazioni client compilate con versioni di Babel.Licensing precedenti alla correzione, quando si autenticano con la chiave utente di una licenza, inviano come nome utente di accesso un identificatore interno del client invece di un valore vuoto. Prima della 11.7.0 questo comportamento era tollerato in silenzio da un fallback lato server; il rafforzamento della sicurezza della 11.7.0 ha rimosso quel fallback (vedi Componenti client), e di conseguenza ogni autenticazione gRPC con chiave utente da un client interessato, con chiavi esistenti o appena generate, fallisce con “Invalid username or password”. Aggiorna al pacchetto Babel.Licensing corrente per risolvere il problema all’origine. Se hai molte applicazioni client distribuite e non puoi aggiornarle tutte subito, imposta EnableLegacyUserKeyFallback su true come soluzione temporanea per la migrazione: il servizio accetta di nuovo la richiesta non conforme ed emette lo stesso token applicativo senza ruoli che un client interessato otterrebbe altrimenti (non concede alcun ruolo e non può raggiungere gli endpoint di Management, quindi non ha più privilegi della normale autenticazione con chiave utente). Riportalo a false quando tutti i client sono stati aggiornati. Ogni volta che il fallback viene usato, il servizio scrive nel log un avviso che identifica il nome utente in questione, così puoi tenere traccia dei client legacy rimasti.

TokenExpiration: questa impostazione determina la durata di validità del token bearer di autenticazione ottenuto dal client. Il valore “00:30:00” indica una scadenza del token di 30 minuti. Trascorso questo periodo, il client deve ottenere un nuovo token per continuare ad accedere.

EnableWebApi: indica se attivare l’interfaccia Web API.

EnableWebUI: indica se il servizio espone l’applicazione web. Impostalo su false per eseguire il servizio come sola API. L’applicazione web richiede inoltre una licenza Data Center.

ApiKeyHeaderName: indica il nome dell’intestazione HTTP con cui viene passata la chiave API.

ApiKeyCacheDuration: determina per quanto tempo una chiave API resta nella cache prima di essere convalidata di nuovo.

EnableSwagger: attiva o disattiva la Swagger UI per la documentazione dell’API.

SwaggerRoutePrefix: il segmento di URL a cui è accessibile la Swagger UI.

SwaggerEndpointUrl: il percorso del file JSON di Swagger che descrive l’API.

GeolocationService: abilita la determinazione della posizione geografica dei client in base ai loro indirizzi IP, utile per il controllo degli accessi su base regionale. Sono supportati IpApiIs e MaxMind.

HealthCheckEndPoint: configura il percorso dell’endpoint del servizio di controllo di stato. L’endpoint del controllo di stato fornisce informazioni sullo stato del sistema agli strumenti di monitoraggio e ai bilanciatori del carico. Se non è configurato esplicitamente, il sistema usa “/health” come valore predefinito.

HealthCheckResponseType: controlla il formato delle risposte restituite dall’endpoint del controllo di stato del Babel Licensing Service. Questa impostazione accetta due valori: “JSON” o “TEXT”.

Configurando queste impostazioni nella sezione “Application” puoi adattare il comportamento del Babel Licensing Service alle tue esigenze: abilitare o disabilitare il supporto di protocolli specifici, specificare il percorso del file di licenza, proteggere l’autenticazione con una chiave di firma e definire la durata di validità del token.

IpApi.is

Il servizio IpApi.is permette la geolocalizzazione usando gli indirizzi IP per determinare la posizione geografica degli utenti, cosa che può essere determinante per il controllo degli accessi su base regionale, i log e le analisi. Offre un modo rapido e affidabile per associare gli indirizzi IP ai rispettivi dati geografici.

Per maggiori informazioni, visita IpApi.is .

Per configurare il servizio IpApiIs con il Babel Licensing Service, segui questi passi:

1. Nella sezione Application, imposta la proprietà GeolocationService su IpApiIs.
2. Aggiungi la sezione IpApiIs ad appsettings.json per configurare l’accesso al servizio tramite una chiave di licenza.

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

MaxMind

MaxMind offre un servizio di geolocalizzazione robusto che supporta sia l’accesso tramite API web sia l’uso di un database locale. Integrando MaxMind gli utenti possono contare sull’elevata precisione dei suoi dati di geolocalizzazione. Il servizio, disponibile su MaxMind , permette di recuperare in modo rapido e affidabile le informazioni sugli indirizzi IP.

Un vantaggio del database locale di MaxMind è che elimina la dipendenza dalle chiamate ad API esterne: le query sono più veloci e l’affidabilità aumenta, soprattutto negli ambienti con connettività internet limitata o instabile. Inoltre i database locali riducono i rischi legati alle violazioni dei dati o alle interruzioni dei servizi esterni, e offrono un maggiore controllo su sicurezza e privacy.

Per configurare il servizio di geolocalizzazione MaxMind con il Babel Licensing Service, segui questi passi:

1. Nella sezione Application, imposta la proprietà GeolocationService su MaxMind.
2. Aggiungi la sezione MaxMind ad appsettings.json con le opzioni di configurazione richieste.

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

Per configurare il database MaxMind, usa la seguente configurazione:

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

Con questa configurazione il Babel Licensing Service usa MaxMind per la geolocalizzazione e ottiene informazioni precise e affidabili sugli indirizzi IP.

Filtro IP

Il filtro IP nelle impostazioni dell’applicazione è una misura di sicurezza pensata per controllare l’accesso al servizio in base agli indirizzi IP. Questa sezione della configurazione fa sì che solo gli utenti attendibili possano interagire con la tua applicazione, mentre il traffico dannoso o indesiderato viene gestito o bloccato.

Dettagli della configurazione:

Blacklist: un array di indirizzi IP a cui l’accesso è negato. Gli IP presenti in questo elenco vengono sempre rifiutati con 403 Forbidden, indipendentemente da qualsiasi altra impostazione.

Whitelist: un array di indirizzi IP attendibili esenti dalla limitazione delle richieste contro gli attacchi di forza bruta. Gli IP presenti in questo elenco non sono soggetti alla quota di richieste per IP né al blocco dinamico; restano comunque soggetti alla Blacklist.

Cambio di comportamento nella 11.7.0: le versioni precedenti trattavano una Whitelist non vuota come un elenco esclusivo di indirizzi consentiti e rifiutavano qualsiasi IP non presente nell’elenco. A partire dalla 11.7.0 l’elenco è soltanto un’esenzione dalla limitazione delle richieste: configurarlo non impedisce più agli IP non elencati di accedere al servizio. Se devi negare l’accesso a degli IP, elencali nella Blacklist (sono supportati i modelli di espressione regolare).

Entrambi gli elenchi supportano la corrispondenza tramite espressioni regolari, che amplia le possibilità di filtro degli IP.

Protezione dagli attacchi di forza bruta

Questa sottosezione serve a configurare le contromisure contro gli attacchi di forza bruta:

Enabled: un valore booleano che, se true, attiva la protezione dagli attacchi di forza bruta.

MaxRequestsPerTimeFrame: il numero massimo di richieste consentite da un singolo indirizzo IP nell’intervallo di tempo specificato.

TimeFrameDuration: il periodo in cui viene valutato il numero di richieste, nel formato ore:minuti:secondi.

RequestsBlockDuration: il tempo per cui l’indirizzo IP responsabile resta bloccato dopo aver superato il numero massimo di richieste.

Protezione dell’autenticazione

Questa sottosezione riguarda i tentativi di accesso:

Enabled: se true, abilita il monitoraggio dei tentativi di autenticazione falliti.

MaxFailedAttempts: il numero di tentativi di accesso falliti consecutivi consentiti prima che scatti un blocco.

LoginBlockDuration: la durata del blocco imposto all’IP dopo aver raggiunto il numero massimo di tentativi di accesso falliti.

Webhook

Le impostazioni dei webhook determinano se i webhook vengono elaborati, con quale frequenza il sistema controlla la presenza di nuovi eventi e come vengono pianificati i nuovi tentativi.

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

• Processing Interval: l’intervallo predefinito di 30 secondi va bene per la maggior parte delle distribuzioni. Un valore troppo basso potrebbe aumentare il carico sul database, mentre un valore troppo alto potrebbe ritardare la consegna dei webhook.
• Retry Interval: l’intervallo di 5 minuti tra i nuovi tentativi lascia ai problemi di rete temporanei il tempo di risolversi e garantisce comunque una consegna tempestiva. Puoi valutare di aumentare questo valore se i destinatari dei tuoi webhook subiscono spesso interruzioni più lunghe.
• Abilitazione/disabilitazione: puoi disabilitare temporaneamente tutta l’elaborazione dei webhook impostando Enabled su false. Può essere utile durante le finestre di manutenzione o quando stai risolvendo problemi del sistema.

Email

La sezione “Email” del file appsettings.json configura le impostazioni email del Babel Licensing Service. Con questa configurazione puoi abilitare la funzionalità email e specificare i dettagli necessari per l’invio delle email dal servizio.

EnableSend: specifica se l’invio delle email è abilitato o disabilitato. Se è true, il Babel Licensing Service tenta di inviare le email in base alle impostazioni configurate. Se è false, l’invio delle email è disabilitato.

Host: il nome host o l’indirizzo IP del server di posta o del server SMTP (Simple Mail Transfer Protocol) usato per inviare le email. Inserisci l’indirizzo del server appropriato.

Port: il numero della porta su cui il server di posta è in ascolto per le connessioni in ingresso. Di solito è la porta del server SMTP. La porta predefinita per SMTP è 587, ma puoi cambiarla in base alla configurazione del tuo server di posta.

UseSsl: specifica se usare la cifratura SSL/TLS nella connessione al server di posta. Se è true, il Babel Licensing Service stabilisce una connessione sicura con SSL/TLS. Se è false, viene usata una connessione non sicura.

LocalDomain: il nome di dominio locale usato per l’indirizzamento delle email. Questa impostazione è facoltativa e può restare vuota se non serve.

Username: il nome utente o il nome dell’account usato per autenticarsi sul server di posta. Inserisci il nome utente appropriato.

Password: la password associata all’account email. Inserisci la password corrispondente al nome utente indicato per l’autenticazione.

FromUser: il nome visualizzato o il nome utente usato come mittente delle email. Può essere un nome descrittivo o un nome utente effettivo.

FromAddress: l’indirizzo email da cui vengono inviate le email. Inserisci l’indirizzo email valido del mittente.

To: un array di indirizzi email e nomi dei destinatari. Ogni oggetto destinatario deve contenere un campo “Name” per il nome del destinatario e un campo “Email” per il suo indirizzo email. Aggiungi nell’array i dati dei destinatari desiderati.

Licensing

La sezione “Licensing” del file appsettings.json è dedicata alla configurazione di vari aspetti delle funzionalità di licenza del Babel Licensing Service. In questa sezione puoi definire le impostazioni relative alla gestione e al comportamento delle licenze.

Nella sezione “Licensing” puoi specificare parametri come l’intervallo di heartbeat, il formato del token di attivazione e il formato del token flottante. Vediamo più da vicino queste impostazioni:

"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: questo parametro determina l’intervallo tra un segnale di heartbeat e il successivo inviati dal servizio di licenze. Il segnale di heartbeat aiuta a monitorare l’integrità e lo stato del sistema di licenze. Un token flottante che non viene rilasciato dal suo client scade dopo questo intervallo.

ReclaimInactiveActivationDays: novità della 12.0. Numero di giorni senza contatto dopo i quali un’attivazione può essere recuperata quando una licenza ha usato tutte le sue postazioni e un nuovo computer chiede di attivarsi. Il valore predefinito 0 disabilita la funzionalità. Se preferisci, impostalo con la variabile d’ambiente BABEL_SERVICE_LICENSING__RECLAIMINACTIVEACTIVATIONDAYS. Leggi Token di licenza prima di abilitarla.

Formati di identificatori e chiavi

I formati specificati nella configurazione usano una combinazione di segnaposto che vengono sostituiti con valori generati casualmente. TOKEN, HEX e DEC sono tipi di segnaposto, e il numero dopo i due punti (:) specifica la lunghezza del valore generato. Le maiuscole (TOKEN, HEX) generano valori in maiuscolo, mentre le minuscole (token, hex) generano valori in minuscolo. DEC indica i numeri decimali.

LicenseIdFormat: "lic{HEX:8}" - Questo formato genera ID licenza che iniziano con “lic” seguito da 8 caratteri esadecimali maiuscoli casuali.

CustomerCodeFormat: "C-{TOKEN:8}" - I codici cliente iniziano con “C-” seguito da 8 caratteri alfanumerici maiuscoli casuali.

OrderNumberFormat: "O-{TOKEN:8}" - I numeri d’ordine iniziano con “O-” seguito da 8 caratteri alfanumerici maiuscoli casuali.

UserKeyFormat: "{TOKEN:5}-{TOKEN:5}-{TOKEN:5}-{TOKEN:5}" - Le chiavi utente vengono generate in un formato con quattro gruppi di 5 caratteri alfanumerici maiuscoli casuali, separati da trattini.

Activation Token Format: questa impostazione definisce il formato dei token di attivazione usati nel processo di licenza. I token di attivazione vengono generati e forniti agli utenti per attivare le loro licenze e sbloccare funzionalità specifiche. Il valore predefinito “actk_{token:12}” imposta come formato del token di attivazione un prefisso fisso “actk_” seguito da 12 caratteri casuali.

Floating Token Format: in modo analogo ai token di attivazione, i token flottanti sono usati per le licenze flottanti, che permettono di condividere le licenze tra più dispositivi o utenti all’interno di un pool definito. Il formato del token flottante specifica la struttura di questi token. Il valore predefinito “fltk_{token:12}” imposta come formato del token flottante un prefisso fisso “fltk_” seguito da 12 caratteri casuali.

Configurando la sezione “Licensing” puoi personalizzare questi parametri in base ai tuoi requisiti di licenza. Questa flessibilità ti permette di adattare le funzionalità di licenza alle esigenze della tua applicazione o del tuo software.

Reporting

La sezione “Reporting” del file appsettings.json è dedicata alle impostazioni di reporting del Babel Licensing Service. In questa sezione puoi definire i parametri relativi alle funzionalità di reporting, comprese le chiavi di cifratura per la trasmissione e l’archiviazione sicura dei report.

Nella sezione “Reporting” puoi specificare impostazioni come la chiave di cifratura. Vediamo più da vicino questa impostazione:

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

Encryption Key: questo parametro definisce la chiave di cifratura usata per cifrare e decifrare i report generati dal Babel Licensing Service. Grazie alla cifratura, le informazioni sensibili contenute nei report restano al sicuro e protette dagli accessi non autorizzati.

Configurando la sezione “Reporting” definisci la chiave di cifratura, così i report generati dal servizio di licenze vengono cifrati con un algoritmo crittografico robusto. Questa cifratura aggiunge ai report un ulteriore strato di sicurezza e protegge i dati sensibili da potenziali minacce o violazioni.

Database

Babel Licensing Service 12.0 supporta SQL Server, MySQL/MariaDB, SQLite e PostgreSQL su Windows, Linux e macOS. Il provider si sceglie nella configurazione del servizio; Babel Desktop si collega all’endpoint del servizio, non direttamente al database.

Scegliere il provider

Imposta Database.Provider con uno dei nomi esatti riportati nella tabella e valorizza la corrispondente voce di ConnectionStrings. MariaDB usa MySQL; Postgres, SQL Server e MariaDB non sono nomi di provider validi. Viene usata solo la voce del provider selezionato.

Schema e migrazioni

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

EnableMigration=true applica le migrazioni dello schema del provider all’avvio del servizio. Usalo per la prima configurazione o un aggiornamento pianificato, con i permessi necessari sul database. Con false, lo schema deve essere già aggiornato. Cambiare provider non trasferisce i dati tra database. Esegui un backup e prova l’aggiornamento su una copia. Per un file SQLite della 11.8, arresta la vecchia applicazione prima del backup consistente e prova il servizio 12.0 sulla copia.

EnableDetailedErrors controlla il dettaglio aggiuntivo degli errori del database. MaxRetryCount e MaxRetryDelay configurano i tentativi per errori temporanei con SQL Server, MySQL e PostgreSQL; non abilitano i retry del provider SQLite. Riavvia il servizio dopo una modifica alla configurazione.

Connection string per provider

Gli esempi sono oggetti JSON completi da integrare in appsettings.json, senza creare ulteriori sezioni annidate. Sostituisci host, percorsi, utenti e REPLACE_WITH_PASSWORD. Gli esempi di rete richiedono un server database configurato per TLS con un certificato attendibile.

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"
  }
}

SQL Server usa Server (host e porta TCP facoltativa separata da una virgola), Database, User ID e Password. Encrypt=True;TrustServerCertificate=False cifra la connessione e verifica il certificato. Su Windows puoi sostituire le credenziali SQL con Integrated Security=True per usare l’account del servizio. LocalDB è un’opzione di sviluppo per Windows, non un server multipiattaforma.

Documentazione del driver: 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 e MariaDB usano la stessa chiave MySQL. Server e Port identificano il server; User ID, Password e Database indicano account e schema. SslMode=VerifyFull verifica certificato e nome del server. Con una CA privata aggiungi SslCa=/percorso/ca.pem. Usa un account dedicato invece di root.

MySQL e MariaDB usano il provider MySQL su ogni framework. I servizi .NET 6-9 usano Pomelo.EntityFrameworkCore.MySql; il servizio .NET 10 usa Microting.EntityFrameworkCore.MySql 10.0.11, un fork di Pomelo con licenza MIT che supporta Entity Framework Core 10. A partire dalla 12.0 il servizio .NET 10 funziona con MySQL e MariaDB. Le stringhe di connessione e lo schema del database sono identici. Testato con MySQL 8.4 e MariaDB 11.4.

Documentazione del driver: 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 usa Npgsql: Host, Port, Database, Username e Password. È una connection string .NET, non un URL postgresql://. SSL Mode=VerifyFull verifica certificato e nome host; per una CA privata aggiungi Root Certificate=/percorso/ca.pem. Database e ruolo devono esistere e il ruolo deve poter accedere allo schema e alle tabelle.

Documentazione del driver: PostgreSQL .

SQLite

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

SQLite viene eseguito nel Licensing Service e non richiede un server database separato, host, porta, utente o password. Data Source è un percorso sulla macchina o nel container del servizio. Usa un percorso assoluto. Mode=ReadWriteCreate crea un file mancante; usa Mode=ReadWrite se il database deve già esistere. L’account del servizio deve poter scrivere nel file e nella directory, inclusi i file journal/WAL. In Docker monta la directory su un volume persistente scrivibile.

Percorso Windows con escaping JSON:

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

Foreign Keys=True abilita i vincoli di chiave esterna. Default Timeout=30 indica il timeout dei comandi SQLite in secondi. Un percorso relativo come licenses.db dipende dalla directory di lavoro del servizio e può aprire un file diverso se cambia il modo in cui viene avviato.

Configura e avvia il Licensing Service come servizio autonomo, anche quando usa SQLite locale. Babel Desktop non lo installa, avvia o arresta. Il profilo di connessione Desktop deve indicare l’endpoint HTTP/HTTPS del servizio.

Documentazione del driver: SQLite .

Variabili d’ambiente

Le variabili con prefisso BABEL_SERVICE_ sovrascrivono le impostazioni JSON. Usa due underscore per separare i livelli. Imposta solo la variabile della connection string del provider selezionato. Fornisci i segreti reali tramite il gestore dei segreti del deployment; i valori seguenti sono segnaposto.

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'

Racchiudi tra virgolette i valori contenenti punti e virgola secondo la sintassi del driver scelto. Nel JSON occorre anche eseguire l’escaping delle virgolette interne e delle barre inverse dei percorsi Windows.