Histórico de mensagens em sugestões

Agora, o ideal mesmo seria o BC flexibilizar o mTLS no callback. Usufrui dessa segurança quem quiser. E aí vejo que entraria perfeitamente no gn/config (caso não haja endpoint específico da spec pra isso)...

Faz sentido

O header a gente entrega mais rápido. O gn/config vai levar mais um tempinho.

No config fica bom tb

A única coisa que achei curiosa é ser um header e não uma opção no /gn/config.

Colocando lenha na fogueira, só um parênteses, continuem aí na prosa de vcs pra não embolar os assuntos... Vejo que o debate de flexibilizar o mTLS seria benéfico e cada PSP arbitraria isso junto ao cliente, por exemplo, um contrato adicional de renuncia do mTLS. Nós recomendaríamos então o cliente e vim na Gerencianet a cada Webhook certificar do status, isso é ruim para a infraestrutura, mas tratarmos algum processamento em troca de algum conforto para alguns clientes, pode ser importante para os negócios e plug-ins.

E se o uso de recursos estiver sendo ruim para a Gerencianet, abre-se dialogo com o cliente, situação que ocasionalmente ocorre.

Deixe-me explicar melhor. Precisamos, de qualquer forma, flexibilizar o PUT. Não queremos remover funcionalidade dele, simplesmente permitir o bypass.

Poderíamos tirar do PUT e levar para o callback? Sim, porém enxergamos como ponto negativo remover uma feature dele (mesmo que seja aplicada em outro ponto).
Isso não impede que iniciemos outra discussão: melhorias no callback.

"mexer o menos possível no PUT"? mas quem tá propondo a mudança no PUT não sou eu 🤔

Sim, entendi o seu ponto. A questão é mexer o menos possível no PUT, nesse momento. Sem remover funcionalidades dele, mas dando uma flexibilizada. Certamente voltaremos a falar do callback.

bom, é útil em qualquer um dos dois jeitos. só não entendi o argumento pra ser favorável a ser no PUT e nao no callback.

o argumento a favor de ser no callback é já ficar preparado pra eventual liberação da necessidade do mTLS por parte do BACEN.

outro argumento é permitir que clientes que vão receber callback usando APIs operadas por terceiros (como ERP SaaS) possam adicionar o header quando bem entenderem, sem depender de mudança na API que manda o PUT

Mas de qualquer forma, precisamos ter essa flexibilidade no PUT

O que acha?

a spec não permite hoje, mas aí o cliente já estaria preparado. diferentemente do envio do header no PUT

Desativar de vez somente no callback.

No caso de implementar no ato do callback, eu tô pensando mesmo é em deixar o integrador desativar de vez, se assim permitir a spec.

De qualquer forma, entendo que ter no PUT e também na notificação propriamente dita a funcionalidade do "bypass", é algo que possa coexistir, concorda?

mas o "habilita/desabilita" seria somente na configuração, exatamente como vocês sugeriram. só muda o local da verificação do header

Isso é muito bom <@!440035527127990273> , mas por hora ainda não estamos confortáveis em permitir esse habilita/desabilita. Caso numa /v3 seja opcional, certamente é algo a se implementar, dessa forma que você sugeriu...

Chegamos a pensar nesse nome, mas por algum incômodo tendemos a não utiliza o termo bypass.

eu acho que faz mais sentido o nome ser x-mtls-bypass. se o padrão é checar, o bypass é que deve ser sinalizado (e setado true) e não usar um valor "false" pra negar o que é padrão