Termos mais procurados:
Podia por os 2. As vantagens do pix.ae:
1. mais fácil usar (muitas mídias não tornam clicáveis - ou sequer aceitam - links que não sejam http(s))
2. é acessível para todos os clientes Pix universalmente, inclusive os clientes de PSPs que ainda não suportam a integração "automática" pelo header x-pix-brcode (abre no navegador e escaneia/copia o brcode)
3. se propagará mais rápido devido às vantagens 1 e 2 😁
O app da GN poderia suportar links https://pix.ae nativamente: https://github.com/bacen/pix-api/issues/251#issuecomment-761594651
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.
Uma otimização seria só revalidar os callbacks idle. Os de quem transação a cada alguns minutos logo terão dados de retorno gerados pelas próprias notificações.
a minha pergunta não foi pra cobrar que validem. foi só pra ajudar a fundamentar a tese de que cabe ao PSP oferecer o suporte ao mTLS mas cabe ao EC usar ou não. se não tem como o PSP saber só com um request individual se o EC está exigindo mTLS, acho que bastaria a GN continuar fazendo a validação no momento do cadastro (pro EC saber que tá configurado correto, se quer usar mTLS) e dar a opção de fazer bypass. ou até mesmo inverter o padrão para não exigir o mTLS e só fazer se o teste se o EC passar x-mtls-check: true no PUT
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.
Adianto que estamos pensando em validar esse teste de tempos em tempos, com uma requisição aleatória. (fora do fluxo de callback)
esclarecendo melhor essa pergunta: é possível saber se o EC tá exigindo o mTLS ou se tá ignorando (no próprio callback individual, não em teste prévio)?
<@!780500321994539068> <@!440035527127990273> <@!742492546198143151> muito boa discussão. Obrigado a todos!
Mas além da parte de segurança, gosto do aspecto operacional dessas validações. Tanto que não espero desligarmos essa validação não... 😉
e do lado de vocês, é possível "exigir o mTLS" pra decidir se os dados devem ser enviados (no momento do callback em si)?
Sim, correto. Mas... o manual transfere para o PSP checar algumas coisas do EC, inclusive aderência a OWASP top-N. Mas isso não precisa ser feito chamada a chamada, pode e é mais usual ser scan regular.
Exato. O BC não deixa explícita essa validação do PUT. Foi algo que a gente trouxe.
