Skip to main content
Perfiles de autenticación para clientes que se conectan a FireFlo. Binds SMPP y llamantes REST por igual. Recargado en caliente: un hilo virtual en segundo plano vigila el archivo y aplica un cambio en unos 200 ms, con un debounce, y sin reinicio.

​
Campos

​
Validación, por protocolo

Para la API REST, configura tanto systemId como password y envíalos como HTTP Basic. La clave de búsqueda es el usuario Basic.Una credencial que solo tiene un apiKey y sin password es configuración válida y no puede autenticar. Se rechaza con 403.

​
allowedIps y allowedProducts predeterminan en direcciones opuestas

Eso es deliberado, y vale la pena leerlo dos veces. El producto selecciona la tarifa. Un login que pudiera nombrar cualquier producto podría elegir su propio precio, así que nombrar uno que no le ha sido concedido se rechaza en lugar de permitirse por omisión.

​
product, y de dónde viene

Para un bind SMPP, el system_type en la petición de bind tiene precedencia cuando el cliente envía uno; este campo es el fallback. Los llamantes HTTP siempre usan este valor, porque no hay bind. Un producto sin establecer es un estado soportado. Coincide con product:isNull: en la tabla de enrutamiento y se tarifica solo por reglas de tarifa que a su vez no llevan producto.
Ese predeterminado tiene un coste. RateSnapshot.rulesFor muestra a un mensaje sin producto solo las reglas sin producto. Así que en un despliegue cuyas reglas de tarifa todas llevan uno, un mensaje sin producto no coincide con nada, se queda sin tarificar, y un mensaje sin tarificar nunca se cobra. Se entrega y se factura a nadie.conf.product.required y smsg.restapi.product.required lo cierran, y ambos están apagados por defecto.

​
TLVs por defecto

Aplicados en el ingreso, tras los tags llevados en el propio submit_sm. Un valor que el cliente envió siempre gana. Se ejecutan antes de la comprobación mandatory.tlvs.submit de la pasarela, así que una credencial puede satisfacer un tag requerido en nombre de un cliente que nunca envía uno. Las claves usan la gramática <name>_<tag> en Declaraciones TLV. Los valores pueden ser un literal, MESSAGE:<field> para copiar un atributo del mensaje, o hex:<bytes>.
Los defaults TLV de credenciales se snapshotean cuando un cliente hace bind. A diferencia de los archivos de enrutamiento y propiedades. Editarlos aplica en el siguiente bind de ese cliente, no a sesiones ya conectadas.

​
Las claves desconocidas se avisan, no se rechazan

Así que una configuración más nueva permanece cargable en un build más antiguo. Cada clave desconocida se registra como advertencia.
Un error tipográfico se descarta silenciosamente en lugar de rechazarse. Si un campo parece no tener efecto, lee el log tras editar.
En modo base de datos este archivo no se lee tras el arranque; los mismos datos viven en app_credential. Consulta Base de datos.