Termos mais procurados:
resumidamente, o proxy mtls.pix.ae "derruba" a necessidade de você se preocupar com mtls. se quiser uma garantia de o request entrante é da GN, você tem alternativas:
1- enviar um request de consumo na API Pix da GN pra constatar a informação recebida;
2- anotar o IP usado pelo pix.ae nos requests que recebe e depois validar se estão vindo sempre desse mesmo IP;
3- usar uma rota com uma string aleatória menos previsível do que "/webhookpix" (e não torná-la pública).
no momento eu só não estou tratando timeouts absolutos do seu lado (site totalmente off do seu lado e sem uma cdn ou load balancer pra responder 502, por exemplo). eu vou responder 200 mesmo, depois de uns 10 segundos. pra evitar sobrecarga no servidor do pix.ae com retentativas que provavelmente seriam frustradas de qualquer forma. de resto, tudo que vc responder, eu repasso pra GN.
não precisa retornar nada. a resposta http padrão é 200. só se você responder algo diferente (mandar um header 503 por ex), o mtls.pix.ae vai repassar o mesmo status (pra indicar que eles precisam retentar a notificação mais tarde), por exemplo
Então eu não preciso da rota webhookpix POST, na verdade eu preciso apenas de uma rota webhookpix/pix POST. Correto?
é um "proxy transparente". o mtls.pix.ae responde "em seu nome" para a GN, como se o domínio mtls.pix.ae fosse seu mesmo
essa etapa 3 eu acho que não está bem descrita. o mtls.pix.ae não faz redirecionamento. ele vai repassar o request vindo da GN para https://cardapio-api.herokuapp.com/webhookpix/pix (lembre-se que a GN adiciona /pix no callback, conforme documentação do BACEN).
o serviço de gerar qrcodes do site pix.ae só tem 1 action POST e é "self-documented", envia o curl pra pix.ae que ele responde com instruções
o proxy mtls não tem docs pq é basicamente só prefixar seu URL de notificação com mtls.pix.ae
correto, no request enviado com o certificado, vai passar pro seu servidor. o que o seu servidor responder, o mtls.pix.ae devolve pra GN
Ai a comunicação entre o mtls.pix.ae e o seu servidor recomendo que mande algum secret para confirmar que veio do local certo
Então, eu não sei como tu fez a configuração nesse caso do servidor que responde pelo mtls.pix.ae, mas sim, você deveria responder com o 403 nesse servidor caso viesse sem certificado, e se viesse, o servidor deveria validar a CA usando o certificado que a gerencianet emitiu pra você, ai sim ele enviaria pro seu backend cardapio-api.heroku...
Bom dia. Tudo bem com vocês?
Estou buscando uma solução alternativa para o mTLS de um backend hospedado no Heroku.
Uso o AdonisJS.
Um prefixo na webhookUrl => https://mtls.pix.ae/cardapioo-api.herokuapp.com/webhookpix
Mas não sei qual o fluxo nesse cenário. Eu imaginava que fosse assim:
1- O GN envia o primeiro request para a webhookUrl cadastrado pelo Postman, retorna com 403;
2- Faz um novo request em https://mtls.pix.ae/cardapioo-api.herokuapp.com/webhookpix junto com o certificado;
3- Ao bater no webhookUrl com o prefixo mtps.pix.ae é direcionado para a url respondida pelo meu backend;
4- Lá encontra a rota https://cardapioo-api.herokuapp.com/webhookpix POST já pronta;
5- Eu apresento ao GN a minha parte do certificado e pronto.
Mas o que acontece na verdade é => "nome": "webhook_invalido", "mensagem": "A requisição na URL informada falhou com o erro: HPE_INVALID_CONSTANT"
Alguém pode me ajudar por favor?
Através do aplicativo mobile da Gerencianet, no menu lateral, toque em Pix, e então em Minhas Chaves.
E através da API, você pode listar suas chaves Pix, mas neste caso, somente as do tipo aleatória.
https://dev.gerencianet.com.br/docs/api-pix-endpoints#section-listar-chaves-evp
