Histórico de mensagens em pix

Request de Browser costuma ter content accept

É que eles não estáo apertando as mãos, o servidou aqui deve ter feito careta e o outro ficou com raiva, ai proibiu o meu server de entrar lá. 🙂

se fosse pra rejeitar por falta do cabeçalho:
- deveria rejeitar igualmente das duas origens; e
- o erro não deveria ser 403, mas 400

está sem o content-accept; mas o comportamento é:
- request local: OK
- request a partir do servidor: 403

É exatamente ai que estou a mais de 4 dias 😦 403 forbidden.

Content accept está application-jose ?

peço ajuda da equipe GN: o hostname qrcodes-pix-h.gerencianet.com.br está retornando 403 Forbidden a partir do meu servidor enquanto consigo abrir normalmente direto da minha conexão local

ainda é possível usar um endereço de callback "externo" ao ambiente que lança as cobranças, mas sendo mTLS é mais seguro do que fazer o PSP enviar requests para qualquer destino desconhecido. o mTLS poderia não se justificar nos casos em que a iniciação é do PSP, mas na iniciação externa fica mais garantido que é intencional o uso de determinada URL para callback

estava refletindo e entendi porque os locations são abertos. para permitir a existência das soluções de "iniciação pix" por parte de empresas que não são instituição de pagamento ou instituição financeira. e aí até faz algum sentido o callback ser obrigatoriamente por um canal mTLS. dá mais controle ao processo, impedindo que eles sejam direcionados a destinos "selvagens" que não foram pre-acordados com o PSP recebedor quando a iniciação também não for via cobranças armazenadas no próprio PSP

perfeito. obrigado

<@!440035527127990273> acessa o location que vai baixar o arquivo, baixou aqui aqui normalmente agora.

Com o modo dev. eu consigo criar cobranças normalmente , fiz a consulta deste QR acima e retornou: {
"parametros": {
"inicio": "2020-11-28T16:01:35.000Z",
"fim": "2020-11-29T16:01:35.000Z",
"paginacao": {
"paginaAtual": 0,
"itensPorPagina": 100,
"quantidadeDePaginas": 1,
"quantidadeTotalDeItens": 8
}
},
"cobs": [
{
"calendario": {
"criacao": "2020-11-29T11:43:03.000Z",
"expiracao": 200000
},
"txid": "GSEH5xD2SF3k1KN5KoqXcQMlQxorderid",
"revisao": 0,
"loc": {
"id": "29",
"location": "https://qrcodes-pix-h.gerencianet.com.br/v2/3a3fa476e6824db58dd9a3afc1d974e7",
"tipoCob": "cob",
"criacao": "2020-11-29T11:43:03.000Z"
},
"location": "https://qrcodes-pix-h.gerencianet.com.br/v2/3a3fa476e6824db58dd9a3afc1d974e7",
"status": "ATIVA",
"devedor": {
"cpf": "12345678909",
"nome": "Francisco da Silva"
},
"valor": {
"original": "124.45"
},
"chave": "fc9a4366ff3d4964b5dbc6c91a8722d18",
"solicitacaoPagador": " Renato Frota Pix ae."
},

a questão não é a "obtenção da URL". a questão é você precisa de mTLS para "injetar" uma cobrança no sistema da GN, vinculada à sua conta GN. por isso o nível de segurança maior.

o fato da URL de cobrança ser aberta é o que vai permitir soluções como a minha obterem os dados da cobrança e formar uma página de fatura, por exemplo (mesmo eu não tendo criado a cobrança nem tendo as suas credenciais). mas por mais que eu me beneficie disso e faça um uso responsável, acho que foi errado ficar aberto.

Blz, entendi, vou estudar mais aqui , não tem lógica ter que mudar de servidor para receber um arquivo .jws. Coisa que acessando diretamente esta mesma url da location o arquivo é baixado sem precisar de nada, isso que não entendo.

o que eu achei errado foi justamente o location estar desprotegido de mTLS (deveria haver um ponto central de autoridade para obtenção dos dados de uma cobrança quando o QR é lido, para que apenas os PSPs pudessem obter esses dados, não qualquer pessoa com acesso ao QR, assim poderia implantar limitação de consumo, por exemplo) e o webhook estar protegido (esse, não deveria ter essa exigência de mTLS, já que é apenas meramente informativo, e quem define a URL de callback já fez uso das credenciais e do canal mTLS pra isso)

na verdade a exigência de mTLS me pareceu interessante para o fluxo de criação de cobrança. fica bem mais restritivo e difícil alguém criar as cobranças por você, mesmo que sua aplicação tenha uma brecha que permita a obtenção de suas credenciais, não tendo o certificado em si (que normalmente só o acesso root poderia dar)

Blz, quero te ajudar, mais ainda não fiz a maquina virtual para gerar o certificado .pem em produção, criar o token, criar a cobrança 😦 , eu não confio nestes sites que fazem online, pois trata-se do certificado de produção, que mesmo assim ainda fica vulneravel, o bacen complica tanto, para no final deixar a mesma brecha de antes, não entendo isso.

nem precisa ser da GN

qualquer QR dinâmico que esteja "pagável" me ajuda