Histórico de mensagens sobre webhook

...ou qualquer outra pessoa que esteja fazendo uso do webhook

<@!780500321994539068> o server com o webhook que você usa está "deployado" em algum PaaS? Se sim, qual?

Não é apenas não-repúdio, como há informações financeiras em trânsito, há também questões de sigilo bancário. O próprio BACEN parece amigável a que numa versão 3 o webhook contenha menos dados (por exemplo apenas a chave Pix e o txid) e com isso possa ter requisitos menores de segurança, pois a informação bancária só seria transmitida no GET de /pix ou da cobrança que o causou. Mas para a versão 2.x, ficou assim e não vai mudar.

Uma forma também comum no mercado é, quando registrar um webhook, definir também um secret. E fica a cargo do webhook checar o secret. Isso garantiria também que as requisições vem de uma origem confiável e não precisaria fazer grandes mudanças na arquitetura. Uma solução de mercado que é viável em webhook em PaaS.

O mTLS aí está servindo para "garantir" para o meu back-end que quem está chamando e mandando as requisições para meu webhook é um certificado gerado pela CA que está naquele cert disponibilizado no site da Gerencianet. O que estou "propondo", é que não houvesse essa restrição na chamada do webhook. Logo, o payload da requisição poderia não ser de confiança. Por isso, a chamada ao webhook seria apenas como um ping, como um push notification, contendo uma chave para que só então o webhook fosse, ativamente, buscar pela informação. É uma arquitetura diferente da que está. É como o Pag Seguro faz, por exemplo. E é tão seguro quanto, só que menos dependente de configuração junto à infra. Enfim... é só um pensamento. Vou ver como resolver de outra forma.

Então, <@!522899003663450113>, na verdade eu suponho que a spec do webhook poderia ser melhor. Mas aí já é discussão para envolver Bacen tmb.

Sim concordo. Não estou questionando a necessidade do webhook em prol do polling. Eu inclusive quero usar o webhook. Só que a restrição do client cert, que ao meu ver poderia ser de uma forma que dependesse menos de acesso a infra sem perder a segurança. A exemplo de como é a do PagSeguro.

Vale lembrar também que a ideia é que se tenha controle do ambiente que seu serviço está hospedado, este é um requisito para ter acesso ao Webhook.

O mTLS faz sentindo. Ainda mais quando se tem volume de transações, se a sua comunicação com o PSP é segura, não tanta há necessidade de checagem do evento (apesar de ser um item de segurança a mais). A questão toda é que um volume alto de transações iria gerar números altos de Webhook + números altos de checagem de Pix recebido, isso poderia bater no ratelimit do PSP.

Ao meu ver, toda essa restrição de segurança no webhook só é necessária porque a requisição que chega nele vem com dados da transação pelo que vi no vídeo. Se a requisição chegasse apenas: "olha só webhook, tem coisa nova lá no txid (ou e2eid) tal, então se vira para achar o que há de novo". Daí a implementação do webhook procuraria os dados "sensíveis" consumindo o serviço específico. Pelo que lembro, a API do Pag Seguro, por exemplo, faz assim. Aí, ao meu ver, não precisaria de tanto "cuidado" com o que chega no webhook, uma vez que a informação vai ser checada na fonte a posteriori.

Eu quero evitar fazer polling no serviço /cob/{txid} , mas se não for possível funcionar o webhook nesse cenário, já que é mandatório o client cert no handshake pelo que entendi, não vai ter jeito ☹️

Pessoal, alguém conseguiu fazer funcionar o handshake com client-cert para o webhook no Heroku? Meu back-end não faz o handshake HTTPS pois já recebe pronto do Heroku, que ao final faz um forward da requisição para meu back-end. Ou seja, meu back-end não participa do handshake. Em princípio essa "limitação" seria comum em cenários de uso em PaaS. Quem está usando webhook está usando servidor dedicado ou está em uma PaaS também? Valeu!

#duvida = qual o formato de cadastro da chave no webhook para celular? esquecí isso kkkk e não sei aonde esta mais na documentação, são tantas hoje.

Pessoal da GerenciaNet boa tarde tudo bem? Por favor estou configurando o webhook da minha aplicação, gostaria de usar o google cloud functions para isso. Porém pelo que li não tem como fazer o mtls lá, é isso mesmo? Teria que usar o App Compute só pra isso?

da forma que é hoje, eu precisaria de um subdominio exclusivo, ou de um nível extra no path só pra diferenciar os webhooks de pix

mas veja só.. se eu tiver um subdominio webhook.exemplo.com.br, e cadastrar a raiz dele, eu vou receber os requests em /pix. ese eu tiver que trancar a garagem inteira, não vou poder usar /paypal , /pagseguro, etc. se estiver exigindo o mTLS da GN na raiz

mas eu posso exigir o mTLS em /webhook e não em /webhook/pix

faz sentido que eu faça isso? não. assim como também não faz sentido testar a URL que não é efetiva.

ainda assim. se o que vai ser acionado de fato é /webhook/pix porque testar /webhook na hora do cadastramento? entendo que tem solução, mas não vejo sentido. se não vai testar a URL efetiva, não deveria testar nada.

É só colocar o path para frente, se quiser compartilhar.
Ex: exemplo.com.br -> site
exemplo.com.br/webhook -> rota para webhook
exemplo.com.br/webhook/pix -> path acionado para pix

mas não faz sentido, pra mim. se eu quiser usar "/" como webhook URL como vou validar (e exigir) o client certificate da GN na raiz? somente a GN poderá entrar no meu site?