Skip to main content
Perfis de autenticação para clientes conectando ao FireFlo. Binds SMPP e chamadores REST juntos. Hot reload: uma virtual thread em background observa o arquivo e aplica uma mudança em cerca de 200 ms, com debounce, sem restart.

​
Campos

​
Validação, por protocolo

Para a REST API, configure systemId e password e envie via HTTP Basic. A chave de lookup é o username do Basic.Uma credencial só com apiKey e sem senha é configuração válida e não consegue autenticar. É recusada com 403.

​
allowedIps e allowedProducts têm padrões em direções opostas

De propósito, e vale ler duas vezes. O produto seleciona a tarifa. Um login que pudesse nomear qualquer produto poderia escolher o próprio preço, então nomear um que não foi concedido é recusado em vez de permitido por omissão.

​
product, e de onde vem

Para um bind SMPP, o system_type na requisição de bind tem precedência quando o cliente envia um; este campo é o fallback. Chamadores HTTP sempre usam este valor, porque não há bind. Um produto não definido é um estado suportado. Casa com product:isNull: na tabela de roteamento e é precificado só por regras de tarifa que também não carregam produto.
Esse padrão tem custo. RateSnapshot.rulesFor mostra a uma mensagem sem produto somente as regras sem produto. Então numa implantação cujas regras de tarifa todas carregam produto, uma mensagem sem produto não casa com nada, fica sem tarifa, e uma mensagem sem tarifa não é cobrada. Ela é entregue e billada a ninguém.conf.product.required e smsg.restapi.product.required fecham isso, e os dois são off por padrão.

​
TLVs default

Aplicados na entrada, depois das tags carregadas no próprio submit_sm. Um valor que o cliente enviou sempre vence. Rodam antes do check mandatory.tlvs.submit do gateway, então uma credencial pode satisfazer uma tag obrigatória em nome de um cliente que nunca envia uma. Chaves usam a gramática <name>_<tag> em declarações de TLV. Valores podem ser um literal, MESSAGE:<field> para copiar um atributo da mensagem, ou hex:<bytes>.
Defaults de TLV de credencial são snapshotados quando um cliente faz bind, diferente dos arquivos de routing e properties. Editar aplica no próximo bind daquele cliente, não em sessões já conectadas.

​
Chaves desconhecidas geram warning, não rejeição

Assim uma configuração mais nova continua carregável em um build mais antigo. Cada chave desconhecida é logada como warning.
Um typo é silenciosamente descartado em vez de recusado. Se um campo parece não ter efeito, leia o log depois de editar.
Em modo de banco este arquivo não é lido depois do startup; os mesmos dados vivem em app_credential. Veja Banco de dados.