Termos mais procurados:
ou usa o meu serviço, campeão. é só fazer um POST para https://pix.ae com tipo=dinamico e location=qrcodes-pix.gerencianet.com.br/......... (pode mandar com https:// incluido, o serviço retira) e receber de volta o QR montadinho 🙂
sim. no dinâmico deveria ser exigido apenas o location, já que ele é a fonte absoluta de informação e os demais conteúdos do qr code devem ser ignorados.
<@!652136709982781470> Dá uma luz ai com isso do error 403 no retorno do payload pegando o location na geração do PIX em modo DEV. 🙂
Seguindo o sdk da GN eu passo os parametros para o metodo emitirPix, esse método emitePix depois vai em montaBrCode e em montaBrCode ele busca pelo payload $dadosPix["loc"]["location"]
Nesse momento acontece o erro 403.
Tem as duas opções (Se for APache) ## Diretório onde hosts virtuais estão armazenados.
SSLCertificateFile /caminho_certificado/server_ssl.crt.pem
SSLCertificateKeyFile /caminho_certificado/server_ssl.key.pem
SSLVerifyClient require
SSLVerifyDepth 1
SSLCACertificateFile /caminho_certificado/chain-pix-prod.crt
## Se preferir deixar apenas uma rota de sua url para notificações você pode adicionar:
SSLVerifyClient none
SSLVerifyClient require
SSLVerifyDepth 3
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)
se fosse problema "descer" a validação do mTLS pra dentro do location, então eu poderia argumentar que o ssl_verify_client deveria subir pra dentro do http {} no seu caso. e aí vc teria que ter um servidor nginx só pra isso 😄
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" 😉
sim. no fim das contas concordei com o Rubens. a orientação poderia ser padrão para server {} isolado, e a alternativa o server {} que tem outras finalidades, com validação dentro do location
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.
recomendo uma leitura dentro da leitura que vc me recomendou:
> The only 100% safe things which may be done inside if in a location context are:
>
> return ...;
> rewrite ... last;
Agora imagina que daqui à 2 anos eu vou ter alguém do nosso time tentando enteder porque tem um IF dentro de um location
mas acho que vc não entendeu o sentido da coisa, Rafael. se é optional, significa que o nginx não vai barrar sozinho o request. ele vai jogar o resultado do mTLS na variavel $ssl_client_verify. aí você rejeita se o mTLS não foi fechado (se não for SUCCESS, dá um 403). o processo é exatamente o mesmo, só muda que a regra não é absoluta (se o mTLS não for fechado, você ainda pode receber requests em outros locations(!)...
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)
Sim, de fato estou usando a 2.1.2. Se fora os escopos cobv e lotecobv e reuso de location há algo mais ainda não suportado na GN, é bom vocês listarem tudo.
