Un login est un moyen de s’authentifier. Un compte est ce qui est facturé. Un compte peut
détenir plusieurs logins, et cette relation est structurellement nécessaire.
Pourquoi le compte, pas le login
Les plafonds de débit, le solde prépayé, les limites de crédit et les relevés sont tous indexés
sur le compte.
Une limite par login permettrait à un client de relever son propre plafond en créant un autre
login. Indexer sur le compte est ce qui donne un sens à la limite.
Les deux protocoles s’authentifient différemment
Pour l’API REST, définissez à la fois systemId et password. Un credential ne détenant
qu’un apiKey est une configuration valide et ne peut pas s’authentifier — il est refusé
avec 403.
Deux champs, défauts opposés
Délibéré. Le product sélectionne le tarif, donc un login qui pourrait nommer n’importe quel
product pourrait choisir son propre prix. Nommer un product qui ne lui a pas été accordé est
refusé plutôt que permis par omission.
Rotation d’un secret
Un client fait tourner le sien depuis le portail, et le nouveau secret est affiché exactement
une fois. Un opérateur peut aussi le faire depuis la page du compte.
Désactiver un login coupe ses binds actifs. C’est le comportement voulu — sinon un credential
révoqué continue d’envoyer jusqu’à ce que la session tombe par hasard — mais cela signifie que le
désactiver pendant les heures ouvrables interrompt le trafic immédiatement.
TLV par défaut sur un credential
Valeurs fournies au nom du client lorsque son submit_sm ne les porte pas.
Appliqués après les tags sur le message — une valeur envoyée par le client gagne toujours —
et avant le contrôle mandatory.tlvs.submit du listener, afin qu’un credential puisse
satisfaire un tag requis au nom d’un client qui n’en envoie jamais.
Les défauts TLV du credential sont figés au bind. Contrairement au routage et aux propriétés,
les éditer s’applique au prochain bind de ce client, pas aux sessions déjà connectées.
1400 et 0x1400 sont des tags différents, se trouve à
Déclarations TLV.
Où vivent les credentials
Basculer vers db face à un app_credential vide refuse chaque bind et chaque appel REST en
même temps. Le chargeur publie la map vide plutôt que de retomber sur le fichier.fireflo import credentials refuse inconditionnellement lorsqu’il ne produirait aucun credential
utilisable, flag ou pas de flag. Ce refus existe précisément pour empêcher cela.
Les clés inconnues sont averties, pas rejetées
Ainsi une configuration plus récente charge sur un build plus ancien. Une faute de frappe est
silencieusement écartée — lisez le log après édition si un champ semble n’avoir aucun effet.
Ce qu’un client voit du sien
Depuis le portail : ses logins, où envoyer, et un bouton de rotation. Jamais celui d’un autre
compte, et jamais un secret qu’il n’a pas juste créé. Voir
Accès au portail. 