Histórico de mensagens sobre webhook

Eu sugiro ssl_verify_client on se todo o vhost for exclusivo do webhook. Aí não precisa da parte de location /webhook.

A GN sugere esta:
server {
#
# ...
#
listen [::]:443 ssl ipv6only=on;
listen 443 ssl;
ssl_certificate server_ssl.crt.pem;
ssl_certificate_key server_ssl.key.pem;
ssl_client_certificate /root/chain-pix-webhooks-prod.crt;
ssl_verify_client optional;
#
# ...
#
location /webhook {
if ($ssl_client_verify != SUCCESS) {
return 403;
}
rewrite ^(.)$ /webhook;
}
}

Pessoal vamos encerrando por hoje, amanhã estamos de volta. na issue 239 colocamos uma proposta para o debate acerca dos cadastros de chaves no webhook. Verifiquem por favor e comentem o que acham.

Um testador de pagamentos no modo DEV, para pagar BRCodes. Ai recebo o retorno do webhook e testo, mais rapido , do que ter que entrar em modo produção, abrir aplicativo, digitar ou escanear, colocar senha, pagar, e ter o retorno do webhook para testar, um botao faz isso agora.

Acho que no sentido dele chamar o webhook e ele ativar...

Finalmente ambiente de teste montado , aprovado e testado com o bendito retorno do webhook em json atualizado e em modo DEV. Pagador executado com sucesso 🙂 Quem venham os POST ´s 🙂 . Estou muito feliz por ter conseguido com a ajuda de todos 🙂

Ufa... finalmente cheguei no ultimo

<@!781134406680838216> Não vão mais enviar o infoPagador no retorno json do webhook ?

ok, é que eu não tinha prestado atenção no true. Ai fiquei na cabeça com o retorno $webhook->parametro e é $webhook['parametro'] 🙂 Com a nova documentação mudou a maioria das posições dos array que tinha aqui feito, estou mudando os create para o db.

sem o true o $webhook será um objeto stdClass, com o true, será um array. como objeto, vc acessa $webhook->parametro, como array, acessa $webhook['parametro']

A parte mais interessante do retorno do json é que ao utilizar sem o parametro , true no json decode, não vem em array o decode, agora que ví isso no código, vivendo e aprendendo.

Não citei THE BIBLE, trata-se de meus princípios de confiança em nossos semelhantes. 😉 Estou implementando o retorno do webhook 🙂 Capítulo mudar os parametros do json para a documentação nova. 🙂

Sim, eu faço essa checagem. Se estiver faltando, exibo mensagem na hora para o usuário e gero uma nova cobrança com o valor restante. No meu caso não uso webhook. Faço a consulta na tela enquanto o usuário paga, pois não tenho como habilitar o mTLS. Daí testo o valor recebido antes mesmo do usuário sair da tela

Acredito que se a página de callback do webhook estiver bem implementada, vai rejeitar o POST, pois precisa recusar a primeira requisição sem certificado da GN. Entretanto, se estiver mal implementada, vai acabar baixando a cobrança

Essa questão já foi levantada. Atualmente há uma trava e nenhuma chave que foi gerada fora da Gerencianet consegue ser utilizada em nosso ambiente. A issue principal é a utilização do webhook por terceiros que tem conta na Gerencianet.

Se eu mudar o webhook da tua conta, apenas a nova url vai receber notificação.. então não serve para nada...

Agora se eu pegar sua url e enviar uma notificação de RECEBIDO, você deve consultar...

Sem um certificado, qualquer um poderia fazer um for com getTxID() e enviar notificação..

Com o certificado, qualquer um que já tenha o certificado...

O mTLS garante que veio da Gerencianet, não de qualquer lugar do mundo. O que esse issue alerta é que é possível hoje fazer a Gerencianet fazer chamadas para o webhook a pedido de outros.

para registrar um webhook você deve passar o acess token..

Claro que não, qualquer um com minha url, meu certificado pode mudar o retorno do webhook e mandar status de "RECEBIDA", isso é o de menos, kkkkk

Tenho, pois existe a vulnerabilidade de registro da url do retorno de webhook !