Skip to main content
Um product é uma tag em um login. Ele é combinável na tabela de roteamento, seleciona a tarifa, e decide se os IDs de remetente e o conteúdo da conta são checados. Ele também é opcional, e o caso opcional é o caro.

​
Um product não definido é um estado suportado que envia de graça

Deixar product fora de uma credencial é configuração válida. Ela combina com product:isNull: na tabela de roteamento e é tarifada apenas por regras de tarifa que elas próprias não carregam produto. Essa última cláusula é toda a armadilha. Uma regra sem produto se aplica a todos os produtos, mas uma mensagem sem produto enxerga apenas as regras que também não têm nenhum. Elas não são duas formas de escrever “qualquer”.
Em um deployment cujas regras de tarifa todas carregam um produto, uma mensagem sem produto não combina com nada. Ela fica sem tarifação, e uma mensagem sem tarifação nunca é cobrada — o pricing roda antes do débito, então chargeCredit a ignora inteiramente. A mensagem é entregue e cobrada de ninguém.Nada a recusa e nada gera um erro. Existe uma linha em debug, que é o sinal inteiro de que tráfego está sendo dado de graça.
Duas configurações fecham isso, ambas desligadas por padrão: O roteamento least-cost deliberadamente ainda tolera um fornecedor sem regra de tarifa de custo — essa é uma questão diferente de saber se o cliente pode ser cobrado, e transformar uma linha esquecida de tarifa de fornecedor em uma indisponibilidade seria pior do que o que ela previne.

​
Por que a checagem é de pertinência, não de não-vazio

system_type em um bind SMPP sobrescreve o produto da credencial, e é texto livre que não é validado em nenhum outro lugar. Assim, um cliente que faz bind com prem quando o produto é premium passa perfeitamente em qualquer teste de não-vazio, e cai exatamente no estado sem tarifação acima. Somente checando o nome contra o catálogo é que se pega isso — que é o que conf.product.required faz, e por que ele não é simplesmente “o produto precisa estar definido”. HTTP não tem bind e portanto não tem sobrescrita: nele o product da credencial é a única fonte.
Configuração por arquivo não tem catálogo, então apenas a metade de não-vazio é aplicada. app_product é uma tabela de banco de dados; um gateway rodando com arquivos, ou um cujo banco esteja inacessível, não consegue checar pertinência de forma alguma. Um nome de produto não reconhecível é aceito, e um WARN nomeando a configuração e o valor é logado uma vez por bind.A tolerância é deliberada — recusar todo bind porque uma query falhou seria uma indisponibilidade muito pior do que a que isso previne. Mas significa que a configuração é mais fraca do que seu nome sugere exatamente nos deployments que não têm catálogo para checar.
Antes de ligar qualquer uma delas, leia o relatório de pré-verificação na página Servers do painel: ela lista os logins que deixariam de conectar. Note o que ela não pode ver — para um login SMPP ela checa o fallback da credencial, então um cliente fazendo bind com um system_type digitado errado não aparecerá lá. A página Pricing carrega a outra pré-verificação: o tráfego das últimas 24 horas que não teve preço, nomeado por conta e produto. Isso é precisamente o que smsg.rating.unrated.refuse começaria a recusar. Ela conta mensagens cujo CDR não tem price_rule_id, então uma regra deliberadamente configurada como 0 não está nela — uma rota grátis permanece grátis e continua enviando.

​
Isentando um produto de whitelisting

Ou Products → Edit → Check sender IDs and content. A pergunta “isto precisa ser validado?” geralmente pertence ao que está sendo vendido, e não a cada cliente que compra — senhas descartáveis por um shortcode não têm sender ID registrado a ser checado. E sem isso, cada conta nesse produto precisaria de sua própria linha de política dizendo o mesmo. Três regras surpreendem as pessoas:
  • Um produto isento sobrescreve a conta. Uma conta configurada como ENFORCE ainda envia livremente sob um produto isento.
  • Nenhum produto não é isento. Tráfego nomeando nenhum produto é checado. Caso contrário, a saída de uma whitelist seria simplesmente parar de enviar um system_type.
  • Um produto desconhecido não é isento. Um nome sem linha em app_product é checado. É um erro de digitação em uma credencial muito mais frequentemente do que uma intenção.
Uma aprovação arquivada sob um produto isento não protege nada. O gateway retorna OFF para esse produto antes de qualquer merge acontecer, então a linha é armazenada, visível, e nunca consultada. O painel conta produtos isentos ao decidir se mudar uma conta para ENFORCE é seguro — caso contrário, a proteção contra construir uma indisponibilidade passaria batido em uma conta cujas aprovações são todas inertes.
Retirar da lista um produto (enabled = false) também encerra sua isenção: produtos isentos são lidos como enabled AND NOT whitelist_enabled. Essa direção é a segura — o tráfego começa a ser checado em vez de parar. Mas pode começar a recusar sender IDs que ninguém aprovou, portanto retire da lista um produto isento deliberadamente, e não como arrumação.

​
Nomeando um produto em um envio REST

Um chamador REST pode enviar product em /secure/send, /secure/sendbatch e /secure/rate, e ele é aceito apenas de um login cujo allowedProducts o nomeie. Uma lista de permissão em vez de um simples campo pela mesma razão que tudo mais nesta página: o produto seleciona a tarifa, então um chamador livre para nomear seu próprio produto está livre para escolher seu próprio preço.

How pricing works

Onde cada lado é tarifado, e o que um valor desconhecido significa.

Rolling whitelisting out

Os quatro interruptores, e a ordem em que se aplicam.