Termos mais procurados:
se vc não quiser forçar o TLSv1.2 para todo o domínio (somente para os webhooks), vc pode continuar usando 2 vhosts separados, e apontar o DirectoryRoot do subdomínio para /var/www/autum-idelivery/public, que o request vai cair no seu Laravel também, e você não precisará fazer um novo POST internamente para a sua API
quando você manda o PUT para o /webhook na API da GN, o que aparece nos logs de acesso (deve aparecer 1 ou 2 requests da GN no momento que vc manda o PUT)?
Bom dia pessoal! Ainda sobre essa questão.
Eu consegui contornar criando um arquivo .php independente, em outro vhost, embora usando o "mesmo arquivo .conf", alterando apenas o subdominio. A conclusão que cheguei, foi a de que, por meu projeto original ser um framework (laravel), o mesmo se utiliza de arquivos .htaccess pra obfuscar a URL. e de alguma forma, isso interfere no processo de handshake da autenticacão mútua.
Então: Criei outro vhost, com certificado proprio no subdominio, recebendo o POST do webhook da GN, e retransmitindo para meu app principal via requisição post. Isso é provisório enquanto descubro o "ponto de falha" entre o framework e o protocolo mTLS.
não funcionam. não dá pra mandar um callback de webhook fake (ainda)
então os webhooks não funcionam em ambiente de homologacao?
alguém sabe de algum artigo ou video que me explique oq é webhook ou como ele funciona na pratica, para mim conseguir integrar os da gerencianet com menos dificuldade?
vc por acaso tá enviando um novo PUT para o endpoint /webhook da API quando recebe o request? 🤔
<@!440035527127990273> eu recebo isso do webhook:
{"evento":"teste_webhook","data_criacao":"2021-01-17T20:09:40.808Z"}
depois não recebo mais nada kkk fico só aguardando
@Deleted User você pode utilizar isso https://webhook.site/
Pra quem tem dificuldades de implementar os webhooks por falta de suporte em hospedagem compartilhada para configurar mTLS, o Pix.ae agora oferece proxy de callbacks com mTLS.
Pra usar é muito simples: é só prefixar o seu domínio com mtls.pix.ae/. Por exemplo:
Para: https://exemplo.com.br/webhookpix
Use: https://mtls.pix.ae/exemplo.com.br/webhookpix
Obs: no ambiente de homologação, prefixe com mtls-h.pix.ae/
Na realidade no meio da conversa trouxe uma reflexão, que caberia até em off-topic, o que gerou duas linhas de debates. O debate real é sobre a validação no cadastro do Webhook, como está no https://www.notion.so/509e46e40bca45be896f4600f26023ea?v=36eb7c30b76b479c96af9ababe718b69&p=8444fb4eaed2412592510e60a492c924
A validação do mTLS que a parte técnica está pensando, de tempo em tempo, se consolidando, será amplamente debatida aqui no Discord antes, não precisa ser objeto de preocupação.
Lembrando que a fluxo atual, com a segurança adicional de validação será o modelo padrão. As implementações que validam isso no cadastro do Webhook são referências.
Essa foi uma preocupação minha inicial. Vejo como problema em um fluxo grande de webhooks ter que validar milhares de webhooks de tempos em tempos... Uma sugestão de isso for implementado e tiver por exemplo 2 chaves com o mesmo Webhook é que só verifique uma vez.
A validação no cadastro do Webhook que fazemos é um atributo de melhoria de segurança nosso, não está no regulamento e o ignorar ou não do lado do cliente, é algo que não temos controle.
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.
