Histórico de mensagens em sugestões

mas o txid tem um conjunto bem definido de caracteres, não?

Mas em tempo: a idéia de tornar mais restritivo é super positiva. É sim um risco operacional ter quase uma máquina de Turing com uma fita qualquer para executar... 😉

<@!370847985199742977> pensamos nisso, mas ainda sim é muito inseguro, pois o problema possui 2 variáveis importantes: regex e txid. Testar a regex com uma amostragem aleatória de txids não nos trouxe segurança.

Ou múltiplos, ou se for um só, tem que separar por chaves. Dá para fazer dos dois jeitos.

<@!780500321994539068> é muito tranquilo aceitarmos vários "comecaCom" e varios "terminaCom". É uma ideia! Se atender seu caso de uso, fará sentido pra gente.

Ou seja, além de ter várias classes, cada classe só seria usada numa chave.

descarta ela

cria um test case por ex, roda contra a expressão desejada... se passar do tempo definido

Mas talvez possa ser feito por chave.

uma sugestão simples, mas não seria mais fácil testar a expressão?

O caso que tínhamos pensado tinha várias classes... 😦

Não vi necessidade de serem múltiplos, pensei em ser um só. Porém, é possível aceitarmos múltiplos e aplicarmos OR ou AND entre eles, se vocês virem como positivo.

Os comecaCom/terminaCom/contem são múltiplos ? Ou seja, poderia ser:
"recebimento": {
"txid": {
"comecaCom": "gnPix",
"comecaCom": "BACEN",
"aceitarVazio": false
}
}
?

Eu acredito que resolveríamos com outra flag, <@!780500321994539068> , algo nesse sentido:

Como é um match de txid nulo nessa versão restrita ? Pq os casos de txid com regras de formação que tínhamos pensado se enquadram nas regras mais restritas (ou seja, atendem).

Boa tarde @everyone !

Retomando o assunto endpoint de configurações (https://www.notion.so/Endpoint-de-configura-es-0a97faee68f845ab96ec21551862fe6c).

Nosso time de engenharia observou que existem possíveis situações em que o match do regex com a string do txid pode demorar muitos segundos ou até minutos. Existem situações inclusive de crash da aplicação. Em outras palavras: não é seguro recebermos via input qualquer regex.

Um exemplo que vocês podem testar no browser:

"Alguns perfis" leia-se "Os menos paranóicos que o Rubens" 😉

Esse primeiro deploy traz uma versão mais simples, na qual a Gerencianet resolve tudo. Isso atenderá a alguns perfis de clientes. Lembrando que nós não armazenamos a chave privada.

Mas a sugestão de aceitar um CSR é tão boa que já tá até no Roadmap, neste card: https://www.notion.so/Gera-o-de-certificados-API-Pix-a-partir-de-um-CSR-de6f5650a5d44ed092af81d6b830ed66

Foi colocado no sistema a geração de certificados, mas ela gera tanto a parte secreta quanto pública. O usual de CAs é que apenas o titular tenha a parte secreta, envia sua chave pública para a CA e essa assina a chave pública. Sugiro que seja alterado para usar um CSR e não gerar a chave.

Olá @Deleted User Tudo bem?
Vou te chamar no privado.