Skip to main content
Authentication profiles for clients connecting to FireFlo — SMPP binds and REST callers alike. Hot reloaded: a background virtual thread watches the file and applies a change within about 200 ms, with a debounce, and no restart.

​
Fields

​
Validation, per protocol

For the REST API, configure both a systemId and a password and send them as HTTP Basic — the lookup key is the Basic username.A credential holding only an apiKey and no password is valid configuration and cannot authenticate. It is refused with 403.

​
allowedIps and allowedProducts default in opposite directions

That is deliberate, and worth reading twice. The product selects the rate. A login that could name any product could pick its own price, so naming one it has not been granted is refused rather than permitted by omission.

​
product, and where it comes from

For an SMPP bind, the system_type on the bind request takes precedence when the client sends one; this field is the fallback. HTTP callers always use this value, because there is no bind. An unset product is a supported state. It matches product:isNull: in the routing table and is priced only by rate rules that themselves carry no product.
That default has a cost. RateSnapshot.rulesFor shows a message with no product only the rules with no product — so on a deployment whose rate rules all carry one, a product-less message matches nothing, is left unrated, and an unrated message is never charged. It is delivered and billed to nobody.conf.product.required and smsg.restapi.product.required close it, and both are off by default.

​
Default TLVs

Applied at ingress, after the tags carried on the submit_sm itself — a value the client sent always wins. They run before the gateway’s mandatory.tlvs.submit check, so a credential can satisfy a required tag on behalf of a client that never sends one. Keys use the <name>_<tag> grammar in TLV declarations. Values may be a literal, MESSAGE:<field> to copy a message attribute, or hex:<bytes>.
Credential TLV defaults are snapshotted when a client binds — unlike the routing and properties files. Editing them applies on that client’s next bind, not to sessions already connected.

​
Unknown keys are warned, not rejected

So a newer configuration stays loadable on an older build. Each unknown key is logged as a warning.
A typo is silently dropped rather than refused. If a field appears to have no effect, read the log after editing.
In database mode this file is not read after startup; the same data lives in app_credential. See Database.