Termos mais procurados:
Como eu não tinha feito nada de webhook para receber os retornos sem o postman e com o postman, fiz logo direto a geração do BRCode sem postman e agora vou fazer a parte da inclusão da url e do recebimento do retorno do webhook da GN, o que estava parando tudo era o ID 62 que está errado no SDK 😦 E o bendito do error 403 forbidden no dev do payload.
Pessoal da GN, em um a nova integração o webserver Apache estava configurado para aceitar TLSv1.3 e TLSv1.2, e mesmo assim a conexão não fechava. Assim que foi desativado a versão do TLSv1.3 a conexão se tornou possível e o Webhook foi configurado de forma correta.
Estou na SAGA DO PIX, Capítulo de hoje Webhook, Create no banco de dados da cobrança, montado e feito as relações, "FIZEMOS PROGRESSO" amanhã temos outro capítulo 🙂
Pessoal do Gerencianet, alguma atualizacao sobre o qrcode estatico nao notificar o webhook?
Boa tarde, pessoal! Lembrando que daqui a pouco teremos um webinar gratuito com a <@!671763456487325717>, o <@!671762828046106646> e o <@!775350441965649951>, nossa equipe especializada no Pix para tirar todas as dúvidas sobre integração, explicar sobre o consumo de endpoints via Postman e ensinar a configuração de Webhook. O link para inscrição é o seguinte https://register.gotowebinar.com/register/5141027611253650955. 🧡
Vi a conversa a respeito dos ips e pra mim é a melhor segurança junto ao mTLS, a gerencianet divulga o ip dos servidores que fazem as requisições dos webhooks ?
com optional eu estou dizendo "tem casos que exigo mTLS, tem casos que não" e aí eu determino quando é exigido (no location do webhook)
Rafael, se o seu hostname é webhook.example.com (e ele tem o ssl_verify_client on) enquanto o host example.com não tem nenhuma exigência, eu posso dizer que é "quase mTLS"? Acho que não. Vc vai argumentar "são hosts diferentes, com regras diferentes".
Então se eu tenho um único server {} para o hostname example.com, que aceita requests com/sem mTLS, e valida dentro de um location /webhook, por que o request para /webhook é um "quase mTLS" enquanto o "/" aceita requests sem mTLS? O meu argumento contrário é que "são locations diferentes, com regras diferentes" 😉
Voltando ao assunto do mTLS em relação ao Nginx. <@!440035527127990273> Não seria legal na documentação da GN estar igual ao do Apache por exemplo? Na documentação do Apache (vide acima), há exemplos tanto para um vHost só para o Webhook como também para um Location só para o Webhook. Assim poderia ser implementado o ssl_verify_client on; e ssl_verify_client optional; a preferir pelo usuário.
sugira pra GN que coloquem uma explicação de como fazer o webhook em server{} exclusivo, então. pode até recomendar. só não podem considerar que é o único setup válido. seria tão burrice que eles inclusive testam se o request passa sem mTLS primeiro, então a exigência de mTLS tá sendo cumprida.
E quem for bem paranóico pode colocar um servername não óbvio aleatório e não identificado no DNS (wildcard) como geqew3123h1uhfda.webhook.exemplo.com.br , e só aceita requisição desse, que é passado no webhook.
Talvez colocar na documentação uma versão recomendada, com ssl_verify_client mandatório e server name único, e uma para isso em path específico com optional e aí checagem só no path do webhook.
A questão não é API, que parece estar aceitando tanto restrições globais quanto específicas, mas da documentação sugerida pela GN que dá um exemplo de específica, de apenas no path do webhook ter restrição.
Lembrando que dá para ter server específico com wildcard. Por exemplo, criar .webhook.openpix.com.br no DNS, e aí cada prestador tem host-name/server-name próprio.
mas vc tá usando um server {} específico pra webhook, meu caro. nem todo mundo seguirá isso.
configuramos desta forma http://gerencianet.webhook.openpix.com.br/
se for optional, você pode ter um location / {} com um sistema qualquer... e um location ~ /webhook {} com a exigência do mTLS (que retorna 400 na falta dele)
se você usa o mesmo server{} do nginx para outros fins que não o webhook, se deixar on o server não vai mais funcionar para os seus outros fins...
