Skip to main content
Profils d’authentification pour les clients qui se connectent à FireFlo — binds SMPP et appelants REST confondus. Rechargé à chaud : un thread virtuel de fond surveille le fichier et applique un changement en 200 ms environ, avec un débounce, sans redémarrage.

​
Champs

​
Validation, par protocole

Pour l’API REST, configurez à la fois un systemId et un password et envoyez-les en HTTP Basic — la clé de recherche est le nom d’utilisateur Basic.Un credential qui ne détient qu’une apiKey et pas de mot de passe est une configuration valide et ne peut pas s’authentifier. Il est refusé avec 403.

​
allowedIps et allowedProducts ont des défauts opposés

C’est délibéré, et cela vaut la peine d’être lu deux fois. Le produit sélectionne le tarif. Un login qui pourrait nommer n’importe quel produit pourrait choisir son propre prix, donc en nommer un qui ne lui a pas été accordé est refusé plutôt que permis par omission.

​
product, et d’où il vient

Pour un bind SMPP, le system_type sur la requête de bind prend la priorité quand le client en envoie un ; ce champ est le repli. Les appelants HTTP utilisent toujours cette valeur, car il n’y a pas de bind. Un produit non défini est un état supporté. Il correspond à product:isNull: dans la table de routage et est tarifé uniquement par les règles de tarif qui ne portent elles-mêmes aucun produit.
Ce défaut a un coût. RateSnapshot.rulesFor montre à un message sans produit uniquement les règles sans produit — donc sur un déploiement dont toutes les règles de tarif en portent un, un message sans produit ne correspond à rien, reste non tarifé, et un message non tarifé n’est jamais facturé. Il est livré et facturé à personne.conf.product.required et smsg.restapi.product.required le ferment, et les deux sont éteints par défaut.

​
TLVs par défaut

Appliqués à l’entrée, après les tags portés par le submit_sm lui-même — une valeur envoyée par le client l’emporte toujours. Ils tournent avant le contrôle mandatory.tlvs.submit de la passerelle, donc un credential peut satisfaire un tag requis pour le compte d’un client qui n’en envoie jamais. Les clés utilisent la grammaire <name>_<tag> de Déclarations TLV. Les valeurs peuvent être un littéral, MESSAGE:<field> pour copier un attribut de message, ou hex:<bytes>.
Les défauts TLV du credential sont capturés en instantané quand un client se bind — contrairement aux fichiers de routage et de propriétés. Les éditer s’applique au prochain bind de ce client, pas aux sessions déjà connectées.

​
Les clés inconnues sont averties, pas rejetées

Ainsi une configuration plus récente reste chargeable sur un build plus ancien. Chaque clé inconnue est journalisée comme avertissement.
Une faute de frappe est silencieusement ignorée plutôt que refusée. Si un champ semble n’avoir aucun effet, lisez le log après édition.
En mode base de données, ce fichier n’est pas lu après le démarrage ; les mêmes données vivent dans app_credential. Voir Base de données.