Histórico de mensagens sobre webhook em sugestões

Em um questionamento aqui com o <@!793123559874494465>... Se a GN retira a validação no cadastro do Webhook, conforme a proposta inicial, o cliente pode renunciar do lado dele, ou seja, toda questão está resolvida.

a GN valida webhook sempre com o mesmo certificado. só precisa webhook e webhook-h

Na verdade, .webhook.pix.ae. Precisa do servername para decidir qual certificado apresentar.

webhook.pix.ae

acho que faz sentido. se for uma renúncia do cliente, a GN nao está deixando de cumprir com a determinação de segurança do BACEN. levem ao Bacen pra ver no que dá.

mas até que o Bacen confirme isso, eu vejo essa possibilidade de bypass (seja no PUT ou no próprio callback) como uma mera facilitação do processo de cadastro do webhook (útil principalmente quando tem um terceiro no processo, além da GN e o EC). não vejo utilidade prática nenhuma enquanto o Bacen exige mTLS nos callbacks

Na verdade, chave Pix e txid, para evitar o problema do webhook pilantra. 😉

Colocando lenha na fogueira, só um parênteses, continuem aí na prosa de vcs pra não embolar os assuntos... Vejo que o debate de flexibilizar o mTLS seria benéfico e cada PSP arbitraria isso junto ao cliente, por exemplo, um contrato adicional de renuncia do mTLS. Nós recomendaríamos então o cliente e vim na Gerencianet a cada Webhook certificar do status, isso é ruim para a infraestrutura, mas tratarmos algum processamento em troca de algum conforto para alguns clientes, pode ser importante para os negócios e plug-ins.

E se o uso de recursos estiver sendo ruim para a Gerencianet, abre-se dialogo com o cliente, situação que ocasionalmente ocorre.

Integrador precisa validar por exemplo se o webhook é de test ou transacional para enviar o x-mtls-check da forma correta.

O BACEN parece bem propenso a continuar com mTLS no webhook na v2. Porém, parece haver espaço para na v3 simplificar as webhook para notificação apenas, e aí em algo que só tenha notificação, se quem mandou o aviso foi o PSP ou o Gasparzinho, dá na mesma.

isso dá mais flexibilidade pra um integrador que recebe os webhooks de ligar/desligar o mTLS bypass sem interferência no script que tá fazendo o envio do PUT

ou seja, o header seria enviado pelo script que RECEBE o callback e não pelo script que consume o PUT /webhook

Pelo que entendi o fluxo seria:
PUT /webhook
Headers:["x-mtls-check": false]
----
Webhook de teste é enviado sem certificado e configurado normalmente.
---
Webhook normal é enviado com o certificado.

Mas ai eles enviariam o webhook de teste com o certificado...

a proposta da GN é passar o header x-mtls-check: false na hora de fazer o PUT /webhook. esse header poderia ser enviado pelo servidor/script que recebe os callbacks

A ideia é na hora que for inserir um webhook e você for enviar o PUT /webhook, informar no header que não quer que seja verificado.

sugestão: em vez de mandar o header que determina o bypass no consumo da API (PUT /webhook), esse header poderia ser enviado pela página que recebe o request da GN

Inclusive eu já faço uma verificação de se o Webhook está configurado certo...

Eu não entendi o raciocínio. Se na hora da notificação eu tenho que validar o mTLS de qualquer forma, melhor que a validação aconteça no cadastro da URL, mesmo, como está hoje. É um benefício gigante eu não precisar gerar o acionamento de webhooks pra saber se a configuração tá correta!

Eu tenho testado isso, Francisco, mas todas as questões se tornaram necessárias alguma configuração no webserver, por exemplo, dito isso essa integração vale a pena? Hoje como está podemos observar se o Webhook está de fato funcionando ou não...

<@!793123559874494465> poderia dissertar melhor sobre isso: "- Permitir o cadastro da URL no PUT /webhooks sem validação ativa do mTLS no momento do consumo;"?