Configuración

La configuración del Babel Licensing Service es un aspecto esencial para establecer una infraestructura de licencias segura y fiable. Un elemento clave de esta configuración es el archivo appsettings.json, que permite definir distintos parámetros y ajustes del servicio.

El archivo de configuración appsettings.json del Babel Licensing Service contiene distintos ajustes de la aplicación. Estas son sus secciones:

1. Serilog: esta sección configura el registro mediante la biblioteca Serilog. Especifica los receptores (sinks) del registro (consola y archivo), los niveles de registro de los distintos espacios de nombres y los enriquecedores que añaden información de contexto.
2. AllowedHosts: se usa para el filtrado de hosts, que enlaza su aplicación con nombres de host concretos.
3. Kestrel: esta sección configura el servidor web Kestrel. Define los protocolos predeterminados y los puntos de acceso del servicio gRPC.
4. Application: esta sección contiene los ajustes propios de la aplicación Babel Licensing Service. Especifica si gRPC-Web está activado, la ruta del archivo de licencia, la clave de firma para la validación de licencias y el tiempo de vencimiento del token.
5. Email: estos ajustes configuran las notificaciones por correo electrónico. Incluyen las opciones para activar o desactivar el envío de correos, los datos del servidor SMTP (host, puerto, SSL), las credenciales de autenticación y la información del remitente y de los destinatarios.
6. Licensing: esta sección configura distintos aspectos del sistema de licencias. Especifica el intervalo de señal de actividad y los formatos de token de las licencias de activación y de las licencias flotantes.
7. Reporting: esta sección configura el servicio de informes e incluye la clave de cifrado que se usa en la generación de informes.
8. Database: esta sección especifica el proveedor de base de datos que usa la aplicación.
9. ConnectionStrings: estos ajustes definen las cadenas de conexión de los distintos proveedores de base de datos (SQL Server, MySQL/MariaDB, SQLite, PostgreSQL).

Cada sección se puede personalizar según los requisitos concretos del despliegue del Babel Licensing Service.

Serilog

Serilog se usa para el registro en el Babel Licensing Service. A continuación se describe con más detalle cómo se configura Serilog en el archivo 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"
      }
    }
  ]
}

En primer lugar se define la sección "Serilog", que contiene varios elementos clave.

Using: esta propiedad especifica los receptores de Serilog que se usan para el registro. En este ejemplo figuran "Serilog.Sinks.Console" y "Serilog.Sinks.File", lo que indica que los registros se escriben tanto en la consola como en un archivo.

MinimumLevel: define el nivel de registro mínimo de las distintas fuentes de registro. El valor Default es «Information», lo que significa que se capturan todos los registros de nivel Information o superior. Además, hay una sección Override que especifica niveles de registro concretos para determinados espacios de nombres. Los niveles de registro disponibles son:

• Verbose: es el nivel más detallado, que rara vez (o nunca) se activa en producción.
• Debug: se usa para los eventos internos del sistema que no son necesariamente observables desde el exterior, pero que resultan útiles para determinar cómo ha ocurrido algo
• Information: los eventos de este nivel describen lo que ocurre en el sistema en relación con sus responsabilidades y funciones. Se usa generalmente para registrar las llamadas gRPC.
• Warning: se usa cuando el servicio está degradado, en riesgo o se comporta fuera de los parámetros esperados.
• Error: se usa cuando una funcionalidad no está disponible o no se cumple lo esperado.
• Fatal: es el nivel más crítico; sus eventos exigen atención inmediata.

Enrich: esta propiedad permite enriquecer los eventos de registro con información adicional. En este ejemplo, los eventos de registro se enriquecen con información como el contexto de registro, el nombre del equipo y el identificador del subproceso.

WriteTo: la propiedad WriteTo define los receptores en los que se escriben los eventos de registro. Hay dos receptores configurados: «Console» y «File». El receptor «Console» escribe los eventos de registro en la consola. El receptor «File» se configura con la propiedad «path» establecida en «log.txt», lo que indica que los eventos de registro se escriben en un archivo llamado log.txt. Además, «rollingInterval» tiene el valor «Day», lo que significa que cada día se crea un nuevo archivo de registro.

Para ajustes más específicos y configuraciones avanzadas de filtrado, registradores secundarios y otras funciones de Serilog, se recomienda consultar la documentación oficial de Serilog. Esta ofrece información detallada sobre las distintas opciones de configuración, como el filtrado y el enriquecimiento de los eventos de registro y la configuración de registradores secundarios.

AllowedHosts

El ajuste «AllowedHosts» del archivo appsettings.json especifica el filtrado de hosts del Babel Licensing Service. Es una medida de seguridad importante para restringir el acceso al servicio a las URL de confianza. El valor «*» indica que el filtrado de hosts está desactivado y que cualquier URL enlazada al host puede acceder al servicio, lo que puede ser adecuado en entornos de desarrollo o de prueba. En producción, sin embargo, se recomienda especificar los hosts de forma explícita.

Estos son algunos ejemplos de cómo configurar el ajuste «AllowedHosts»:

1. Permitir un host concreto:

   "AllowedHosts": "example.com"

   Esta configuración restringe el acceso al Babel Licensing Service a las solicitudes dirigidas al dominio «example.com». Todas las solicitudes dirigidas a otros hosts devuelven una respuesta 400 que indica que el nombre de host no es válido.

2. Permitir varios hosts:

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

   Esta configuración permite acceder al Babel Licensing Service solo desde «example.com» y «subdomain.example.com». Las solicitudes de cualquier otro dominio se deniegan.

3. Permitir varios hosts con una expresión con comodín:

   "AllowedHosts": "*.example.com"

   Esta configuración permite acceder al Babel Licensing Service desde cualquier subdominio de «example.com». Por ejemplo, se permiten «subdomain.example.com» y «another.subdomain.example.com», pero las solicitudes de otros dominios o subdominios se rechazan.

Es importante valorar y configurar con cuidado el ajuste «AllowedHosts» según su entorno de despliegue y sus requisitos de seguridad. Al restringir el acceso a los hosts de confianza, mejora la seguridad y la integridad de su Babel Licensing Service.

Kestrel

La sección de configuración «Kestrel» del archivo appsettings.json configura el servidor web Kestrel, que aloja el Babel Licensing Service. Kestrel es un servidor web multiplataforma que ofrece un entorno de alojamiento rápido y fiable para su aplicación.

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

En la sección «Kestrel» puede definir distintos ajustes para personalizar el comportamiento del servidor. Estos son algunos elementos clave de la configuración de Kestrel:

EndpointDefaults: esta subsección permite establecer la configuración predeterminada de todos los puntos de acceso. Aquí puede especificar los protocolos que admite el servidor. En el ejemplo, «Http1AndHttp2» indica que los protocolos HTTP/1.1 y HTTP/2 están activados de forma predeterminada.

Endpoints: esta subsección permite definir puntos de acceso concretos para el servidor. En el ejemplo, el punto de acceso «gRPC» está configurado con la URL «http://localhost:5005»  y el protocolo «Http2». Este punto de acceso está pensado para atender las solicitudes gRPC que se hacen al Babel Licensing Service mediante el protocolo HTTP/2.

Configurar Kestrel correctamente es esencial para el buen funcionamiento de su Babel Licensing Service. Puede personalizar distintos aspectos, como los protocolos, los números de puerto, los certificados SSL y otros, para adaptarlos a sus requisitos.

Es importante consultar la documentación oficial y seguir las prácticas recomendadas al configurar Kestrel para obtener un rendimiento, una seguridad y una fiabilidad óptimos.

Application

La sección de configuración «Application» de appsettings.json permite personalizar distintos aspectos del Babel Licensing Service. A continuación se describe cada ajuste en detalle:

"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: junto con AdminEmail y AdminPassword, son las credenciales que se usan para crear el usuario administrador inicial la primera vez que se inicia el servicio.

A partir de la versión 11.7.0, el servicio se distribuye con los tres valores vacíos: se ha eliminado el valor predeterminado histórico admin / admin. El administrador inicial solo se crea cuando AdminUsername y AdminPassword no están vacíos (AdminEmail es opcional, pero recomendable). Si alguno de los dos valores obligatorios está vacío, el servicio se inicia igualmente y se crean los roles estándar, pero no se crea ninguna cuenta de administrador y la aplicación web no se puede usar hasta que rellene los ajustes y reinicie el servicio. Use appsettings.json o las variables de entorno BABEL_SERVICE_APPLICATION__ADMINUSERNAME / ..._ADMINPASSWORD / ..._ADMINEMAIL; después, cambie la contraseña desde la aplicación web y borre AdminPassword de la configuración una vez que exista la cuenta.

LogToDatabase: indica si los registros se almacenan en una base de datos.

LogRetentionPeriod: especifica cuánto tiempo se conservan los registros, con el formato días.horas:minutos:segundos.

EnableGrpcWeb: si establece este valor en false, desactiva la compatibilidad con gRPC Web, lo que significa que el servidor solo acepta solicitudes mediante el protocolo HTTP/2. Tenga en cuenta que algunas plataformas cliente, como UWP o Unity, pueden no admitir HTTP/2, por lo que activar HTTP/1.1 junto con HTTP/2 garantiza la compatibilidad con todas las aplicaciones cliente. Recuerde que activar ambos protocolos en el mismo puerto requiere TLS para la negociación de protocolos.

LicenseFile: este ajuste especifica la ruta del archivo de licencia que usa el Babel Licensing Service. El archivo de licencia contiene información sobre las licencias concedidas y sus funciones asociadas. La licencia también determina la edición: una licencia con la función de aplicación web (Data Center) desbloquea la aplicación web incluida en el paquete. Con las demás licencias, la dirección de la aplicación web muestra una página de actualización. Para actualizar basta con sustituir el archivo y reiniciar el servicio.

SigningKey: la clave de firma es un secreto que se usa para firmar el token de portador de autenticación. Los clientes usan este token para acceder al servicio gRPC de forma segura. Es esencial mantener esta clave en secreto y elegir un valor seguro y único.

A partir de la versión 11.7.0, este ajuste se distribuye vacío (se ha eliminado el valor histórico incluido en el código). Si SigningKey está vacío al iniciar, el servicio genera para el proceso actual una clave de 32 bytes criptográficamente aleatoria y escribe una advertencia en el registro. Esto resulta cómodo para las pruebas locales, pero no es adecuado para producción: cada reinicio invalida todos los tokens emitidos antes, y las instancias situadas detrás de un equilibrador de carga rechazan los tokens de las demás. Los despliegues de producción deben configurar SigningKey de forma explícita, en appsettings.json o mediante la variable de entorno BABEL_SERVICE_APPLICATION__SIGNINGKEY, con un secreto seguro gestionado fuera del control de código fuente.

Configure siempre SigningKey: en las versiones actuales (hasta la 11.8.0 incluida), dejar SigningKey vacío no solo invalida los tokens entre reinicios: el token emitido tras la autenticación no se acepta en las llamadas posteriores, por lo que la activación de licencia falla con:

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

El registro del servicio muestra una autenticación correcta (User '' authenticated, token expires in ...) justo antes del 401, lo que hace que el fallo parezca un problema del cliente. Para resolverlo, establezca SigningKey en cualquier valor estable y no vacío de al menos 32 caracteres. Se corregirá en una versión futura; en cualquier caso, configurar la clave de forma explícita es el ajuste correcto para producción.

EnableLegacyUserKeyFallback: restablece la compatibilidad de autenticación para las aplicaciones cliente compiladas con un paquete NuGet Babel.Licensing anterior a la versión que corrige el problema de autenticación con UserKey por gRPC descrito más abajo. El valor predeterminado es false.

Autenticación con UserKey por gRPC: las aplicaciones cliente compiladas con versiones de Babel.Licensing anteriores a la corrección envían un identificador interno del cliente como nombre de usuario de inicio de sesión, en lugar de un valor vacío, cuando se autentican con una UserKey de licencia. Antes de la versión 11.7.0, un mecanismo alternativo del servidor lo toleraba sin avisar; el refuerzo de la seguridad de la versión 11.7.0 eliminó ese mecanismo (consulte Componentes de cliente), por lo que toda autenticación con UserKey por gRPC desde un cliente afectado, tanto con claves existentes como con claves recién generadas, falla con «Invalid username or password» (nombre de usuario o contraseña no válidos). Actualice al paquete Babel.Licensing actual para corregirlo en origen. Si tiene muchas aplicaciones cliente desplegadas y no puede actualizarlas todas de inmediato, establezca EnableLegacyUserKeyFallback en true como puente temporal de migración: el servicio vuelve a aceptar la solicitud mal formada y emite el mismo token de aplicación sin roles que obtendría un cliente afectado en condiciones normales (no concede roles y no puede llegar a los puntos de acceso de Management, por lo que no tiene más privilegios que la autenticación normal con UserKey). Vuelva a establecerlo en false cuando todos los clientes estén actualizados. Cada vez que se usa el mecanismo alternativo, el servicio registra una advertencia que identifica el nombre de usuario causante, para que pueda llevar la cuenta de los clientes heredados que quedan.

TokenExpiration: este ajuste determina el tiempo de validez del token de portador de autenticación que obtiene el cliente. El valor «00:30:00» indica que el token vence a los 30 minutos. Pasado ese tiempo, el cliente debe obtener un nuevo token para seguir accediendo.

EnableWebApi: indica si se activa la interfaz Web API.

EnableWebUI: indica si el servicio sirve la aplicación web. Establézcalo en false para ejecutar el servicio solo como API. La aplicación web requiere además una licencia Data Center.

ApiKeyHeaderName: designa el nombre de la cabecera HTTP en la que se envía la clave API.

ApiKeyCacheDuration: determina cuánto tiempo se guarda en caché una clave API antes de volver a validarla.

EnableSwagger: activa o desactiva Swagger UI para la documentación de la API.

SwaggerRoutePrefix: el segmento de la URL en el que se accede a Swagger UI.

SwaggerEndpointUrl: la ruta del archivo JSON de Swagger que describe la API.

GeolocationService: activa la función que determina la ubicación geográfica de los clientes a partir de su dirección IP, lo que facilita el control de acceso por regiones. Se admiten IpApiIs y MaxMind.

HealthCheckEndPoint: configura la ruta del punto de acceso del servicio de comprobación de estado. Este punto de acceso proporciona información del estado del sistema a las herramientas de supervisión y a los equilibradores de carga. Si no se configura de forma explícita, el sistema usa «/health» de forma predeterminada.

HealthCheckResponseType: controla el formato de las respuestas que devuelve el punto de acceso de comprobación de estado del Babel Licensing Service. Este ajuste acepta dos valores posibles: «JSON» o «TEXT».

Al configurar estos ajustes en la sección «Application» puede adaptar el comportamiento del Babel Licensing Service a sus requisitos: activar o desactivar la compatibilidad con determinados protocolos, especificar la ruta del archivo de licencia, proteger la autenticación con una clave de firma y definir el tiempo de vencimiento del token.

IpApi.is

El servicio IpApi.is permite la geolocalización: usa las direcciones IP para determinar la ubicación geográfica de los usuarios, lo que puede ser fundamental para el control de acceso por regiones, el registro y el análisis. Es una forma rápida y fiable de asociar las direcciones IP con sus datos geográficos.

Para más información, visite IpApi.is .

Para configurar el servicio IpApiIs con el Babel Licensing Service, siga estos pasos:

1. En la sección Application, establezca la propiedad GeolocationService en IpApiIs.
2. Añada la sección IpApiIs a appsettings.json para configurar el acceso al servicio mediante una clave de licencia.

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

MaxMind

MaxMind ofrece un servicio de geolocalización sólido que admite tanto el acceso mediante API web como el uso de una base de datos local. Al integrar MaxMind, los usuarios aprovechan la alta precisión de sus datos de geolocalización. El servicio, disponible en MaxMind , permite obtener información de direcciones IP de forma rápida y fiable.

Una ventaja de usar la base de datos local de MaxMind es que elimina la dependencia de las llamadas a una API externa, con lo que las consultas son más rápidas y la fiabilidad aumenta, sobre todo en entornos con una conexión a internet limitada o inestable. Además, las bases de datos locales reducen los riesgos asociados a las filtraciones de datos o a las interrupciones de servicios externos, y ofrecen un mayor control de la seguridad y la privacidad.

Para configurar el servicio de geolocalización MaxMind con el Babel Licensing Service, siga estos pasos:

1. En la sección Application, establezca la propiedad GeolocationService en MaxMind.
2. Añada la sección MaxMind a appsettings.json con las opciones de configuración necesarias.

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

Para configurar la base de datos de MaxMind, use la configuración siguiente:

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

Esta configuración permite al Babel Licensing Service usar MaxMind para la geolocalización, con información precisa y fiable sobre las direcciones IP.

Filtrado de IP

El filtrado de IP de los ajustes de la aplicación es una medida de seguridad que controla el acceso al servicio según la dirección IP. Esta sección de la configuración garantiza que solo los usuarios de confianza interactúen con su aplicación, mientras que el tráfico malicioso o no deseado se gestiona o se bloquea.

Detalles de la configuración:

Blacklist: una matriz de direcciones IP a las que se deniega el acceso. Las IP de la lista de bloqueados se rechazan siempre con 403 Forbidden, sea cual sea el resto de la configuración.

Whitelist: una matriz de direcciones IP de confianza que están exentas de la limitación de frecuencia contra ataques de fuerza bruta. Las IP de la lista de permitidos no están sujetas a la cuota de solicitudes por IP ni al bloqueo dinámico; siguen sujetas a la lista de bloqueados.

Cambio de comportamiento en la versión 11.7.0: las versiones anteriores trataban una Whitelist no vacía como una lista de permitidos exclusiva, de modo que se rechazaba toda IP que no figurase en ella. A partir de la versión 11.7.0, la lista de permitidos es solo una exención de la limitación de frecuencia: configurarla ya no impide que las IP no incluidas accedan al servicio. Si necesita denegar el acceso a determinadas IP, inclúyalas en la Blacklist (se admiten patrones de expresiones regulares).

Ambas listas admiten la coincidencia de patrones mediante expresiones regulares, lo que amplía las posibilidades de filtrado de IP.

Protección contra fuerza bruta

Esta subsección configura las contramedidas frente a los ataques de fuerza bruta:

Enabled: un valor booleano que, cuando es true, activa la protección contra ataques de fuerza bruta.

MaxRequestsPerTimeFrame: el número máximo de solicitudes permitidas desde una misma dirección IP dentro del intervalo de tiempo especificado.

TimeFrameDuration: el período en el que se evalúa el número de solicitudes, con el formato horas:minutos:segundos.

RequestsBlockDuration: el tiempo durante el que se bloquea la dirección IP infractora después de superar el número máximo de solicitudes.

Protección de la autenticación

Esta subsección se refiere a los intentos de inicio de sesión:

Enabled: cuando es true, activa la supervisión de los intentos de autenticación fallidos.

MaxFailedAttempts: el número permitido de intentos de inicio de sesión fallidos consecutivos antes de aplicar un bloqueo.

LoginBlockDuration: la duración del bloqueo que se impone a la IP tras alcanzar el número máximo de intentos de inicio de sesión fallidos.

Webhook

Los ajustes de Webhook determinan si se procesan los webhooks, con qué frecuencia comprueba el sistema si hay eventos nuevos y cómo se programan los reintentos.

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

• Processing Interval: el intervalo predeterminado de 30 segundos funciona bien en la mayoría de los despliegues. Un valor demasiado bajo puede aumentar la carga de la base de datos, mientras que uno demasiado alto puede retrasar la entrega de los webhooks.
• Retry Interval: el intervalo de reintento de 5 minutos da tiempo a que se resuelvan los problemas de red temporales sin renunciar a una entrega puntual. Puede valorar aumentar este valor si los receptores de sus webhooks sufren con frecuencia interrupciones más largas.
• Activación y desactivación: puede desactivar temporalmente todo el procesamiento de webhooks estableciendo Enabled en false. Resulta útil durante las ventanas de mantenimiento o al investigar problemas del sistema.

Email

La sección «Email» del archivo appsettings.json configura los ajustes de correo electrónico del Babel Licensing Service. Con esta configuración puede activar el correo electrónico y especificar los datos necesarios para enviar correos desde el servicio.

EnableSend: especifica si el envío de correos está activado o desactivado. Si es true, el Babel Licensing Service intenta enviar correos según los ajustes configurados. Si es false, el envío de correos queda desactivado.

Host: el nombre de host o la dirección IP del servidor de correo o servidor SMTP (Simple Mail Transfer Protocol) que se usa para enviar los correos. Introduzca la dirección del servidor que corresponda.

Port: el número de puerto en el que el servidor de correo escucha las conexiones entrantes. Suele ser el puerto del servidor SMTP. El puerto predeterminado de SMTP es 587, pero puede cambiarlo según la configuración de su servidor de correo.

UseSsl: especifica si se usa el cifrado SSL/TLS al conectarse al servidor de correo. Si es true, el Babel Licensing Service establece una conexión segura mediante SSL/TLS. Si es false, se usa una conexión no segura.

LocalDomain: el nombre de dominio local que se usa en las direcciones de correo. Este ajuste es opcional y puede dejarse vacío si no se necesita.

Username: el nombre de usuario o de cuenta con el que se autentica en el servidor de correo. Introduzca el nombre de usuario que corresponda.

Password: la contraseña asociada a la cuenta de correo. Introduzca la contraseña correspondiente al nombre de usuario indicado para la autenticación.

FromUser: el nombre para mostrar o el nombre de usuario que figura como remitente de los correos. Puede ser un nombre descriptivo o un nombre de usuario real.

FromAddress: la dirección de correo electrónico desde la que se envían los correos. Introduzca una dirección de correo válida para el remitente.

To: una matriz con las direcciones de correo y los nombres de los destinatarios. Cada objeto de destinatario debe contener un campo «Name» con el nombre del destinatario y un campo «Email» con su dirección de correo electrónico. Añada a la matriz los datos de los destinatarios que desee.

Licensing

La sección «Licensing» del archivo appsettings.json configura distintos aspectos de la funcionalidad de licencias del Babel Licensing Service. Permite definir ajustes relacionados con la gestión y el comportamiento de las licencias.

En la sección «Licensing» puede especificar parámetros como el intervalo de señal de actividad, el formato del token de activación y el formato del token flotante. A continuación se describen estos ajustes con más detalle:

"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: este parámetro determina el tiempo que transcurre entre dos señales de actividad enviadas por el servicio de licencias. La señal de actividad ayuda a supervisar el estado del sistema de licencias. Un token flotante que su cliente no libera vence al cabo de este intervalo.

ReclaimInactiveActivationDays: novedad de la versión 12.0. Número de días sin contacto tras los cuales se puede recuperar una activación cuando una licencia ha usado todos sus puestos y un equipo nuevo solicita activarse. El valor predeterminado 0 desactiva la función. Si lo prefiere, establézcalo con la variable de entorno BABEL_SERVICE_LICENSING__RECLAIMINACTIVEACTIVATIONDAYS. Lea Tokens de licencia antes de activarla.

Formatos de identificadores y claves

Los formatos especificados en la configuración usan una combinación de marcadores de posición que se sustituyen por valores generados aleatoriamente. TOKEN, HEX y DEC son tipos de marcadores de posición, y el número que sigue a los dos puntos (:) indica la longitud del valor generado. En mayúsculas (TOKEN, HEX) se generan valores en mayúsculas, y en minúsculas (token, hex), valores en minúsculas. DEC corresponde a los números decimales.

LicenseIdFormat: "lic{HEX:8}". Con este formato, los id de licencia empiezan por «lic», seguido de 8 caracteres hexadecimales aleatorios en mayúsculas.

CustomerCodeFormat: "C-{TOKEN:8}". Los códigos de cliente empiezan por «C-», seguido de 8 caracteres alfanuméricos aleatorios en mayúsculas.

OrderNumberFormat: "O-{TOKEN:8}". Los números de pedido empiezan por «O-», seguido de 8 caracteres alfanuméricos aleatorios en mayúsculas.

UserKeyFormat: "{TOKEN:5}-{TOKEN:5}-{TOKEN:5}-{TOKEN:5}". Las claves de usuario se generan con un formato de cuatro grupos de 5 caracteres alfanuméricos aleatorios en mayúsculas, separados por guiones.

Activation Token Format: este ajuste define el formato de los tokens de activación que se usan en el proceso de licencia. Los tokens de activación se generan y se entregan a los usuarios para que activen sus licencias y desbloqueen funciones o funcionalidades concretas. El valor predeterminado «actk_{token:12}» define el formato del token de activación como el prefijo fijo «actk_» seguido de 12 caracteres aleatorios.

Floating Token Format: al igual que los tokens de activación, los tokens flotantes se usan con las licencias flotantes, que permiten compartir licencias entre varios dispositivos o usuarios dentro de un grupo de puestos flotantes definido. El formato del token flotante especifica la estructura de estos tokens. El valor predeterminado «fltk_{token:12}» define el formato del token flotante como el prefijo fijo «fltk_» seguido de 12 caracteres aleatorios.

Al configurar la sección «Licensing» puede adaptar estos parámetros a sus requisitos de licencia. Esta flexibilidad permite ajustar la funcionalidad de licencias a las necesidades de su aplicación o software.

Reporting

La sección «Reporting» del archivo appsettings.json configura los ajustes relacionados con los informes en el Babel Licensing Service. Permite definir los parámetros de la funcionalidad de informes, entre ellos las claves de cifrado para la transmisión y el almacenamiento seguros de los informes.

En la sección «Reporting» puede especificar ajustes como la clave de cifrado. A continuación se describe este ajuste con más detalle:

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

Encryption Key: este parámetro define la clave de cifrado que se usa para cifrar y descifrar los informes generados por el Babel Licensing Service. Gracias al cifrado, la información confidencial que contienen los informes permanece segura y protegida frente a accesos no autorizados.

Configurar la sección «Reporting» permite definir la clave de cifrado, de modo que los informes generados por el servicio de licencias se cifren con un algoritmo criptográfico seguro. Este cifrado añade una capa adicional de seguridad a los informes y protege los datos confidenciales frente a posibles amenazas o filtraciones.

Database

Babel Licensing Service 12.0 admite SQL Server, MySQL/MariaDB, SQLite y PostgreSQL en Windows, Linux y macOS. Babel Desktop se conecta al servicio, no directamente a su base de datos.

Seleccionar el proveedor

Asigna a Database.Provider el nombre exacto de la tabla y configura la entrada correspondiente de ConnectionStrings. MariaDB usa MySQL. Postgres, SQL Server y MariaDB no son nombres de proveedor válidos. Solo se utiliza la entrada seleccionada.

Esquema y migraciones

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

EnableMigration=true aplica las migraciones del proveedor al iniciar el servicio, con los permisos necesarios. Con false, el esquema debe estar actualizado. Cambiar el proveedor no transfiere datos. Haz una copia de seguridad y prueba la actualización sobre una copia. Detén la aplicación antigua antes de copiar un archivo SQLite 11.8 y prueba el servicio 12.0 con esa copia.

EnableDetailedErrors controla los detalles adicionales de errores. MaxRetryCount y MaxRetryDelay configuran los reintentos de SQL Server, MySQL y PostgreSQL, no los de SQLite. Reinicia el servicio tras cambiar su configuración.

Cadenas de conexión por proveedor

Integra estos objetos JSON completos en appsettings.json. Sustituye hosts, rutas, usuarios y REPLACE_WITH_PASSWORD. Los ejemplos de red requieren TLS en el servidor y un certificado de confianza.

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 contiene el host y, opcionalmente, el puerto TCP separado por una coma. Database, User ID y Password seleccionan la base de datos y la cuenta. Encrypt=True;TrustServerCertificate=False cifra y valida el certificado. En Windows puedes sustituir las credenciales por Integrated Security=True. LocalDB es una opción de desarrollo exclusiva de Windows.

Referencia 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 y MariaDB usan MySQL. Server, Port, Database, User ID y Password definen la conexión. SslMode=VerifyFull valida certificado y nombre del servidor; con una CA privada, añade SslCa=/ruta/ca.pem. Usa una cuenta dedicada, no root.

MySQL y MariaDB usan el proveedor MySQL en todos los frameworks. Los servicios para .NET 6 a 9 usan Pomelo.EntityFrameworkCore.MySql; el servicio para .NET 10 usa Microting.EntityFrameworkCore.MySql 10.0.11, una bifurcación de Pomelo con licencia MIT que admite Entity Framework Core 10. A partir de la versión 12.0, el servicio para .NET 10 funciona con MySQL y MariaDB. Las cadenas de conexión y el esquema de la base de datos son idénticos. Probado con MySQL 8.4 y MariaDB 11.4.

Referencia 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 con Host, Port, Database, Username y Password. Es una cadena .NET, no un URL postgresql://. SSL Mode=VerifyFull valida certificado y host; para una CA privada añade Root Certificate=/ruta/ca.pem. La base de datos y el rol deben existir y tener permisos sobre el esquema y las tablas.

Referencia 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 se ejecuta dentro del Licensing Service, sin servidor de base de datos ni credenciales. Data Source es una ruta absoluta en el equipo del servicio. Mode=ReadWriteCreate crea un archivo ausente; Mode=ReadWrite exige que ya exista. La cuenta del servicio necesita permisos de escritura en el archivo y directorio, incluidos journal/WAL. En Docker usa un volumen persistente con escritura.

Ruta Windows con escape JSON:

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

Foreign Keys=True activa las claves externas. Default Timeout=30 indica el tiempo de espera de comandos en segundos. Las rutas relativas como licenses.db dependen del directorio de trabajo del servicio.

Configura e inicia el Licensing Service por separado, también para SQLite local. Babel Desktop no lo instala, inicia ni detiene; el perfil Desktop apunta al endpoint HTTP/HTTPS del servicio.

Referencia del driver: SQLite .

Variables de entorno

Las variables con BABEL_SERVICE_ sobrescriben el JSON. Dos guiones bajos separan los niveles. Configura solo la variable de conexión del proveedor seleccionado. Guarda los secretos reales en el gestor de secretos del despliegue.

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'

Los valores con punto y coma requieren comillas según el driver. En JSON también debes escapar las comillas internas y las barras inversas de Windows.