Messias Bittencourt

Combinado e no aguardo. Muito obrigado!

Bom dia @antonio.carlos. Eles não possuem uma documentação em pdf. Mas acessei aqui o "https://developercielo.github.io/manual/apipix#segurança" com meu usu e senha e te passo abaixo a parte que fala de segurança. Se realizar um cadastro no site "https://desenvolvedores.cielo.com.br/api-portal/" poderá checar a documentação com mais profundidade. Pelo postman eu utilizei os .cer e .key obtendo sucesso. Segurança Devem ser observadas para desenvolver e implementar a API seguindo boas práticas de segurança, atendendo aos requisitos obrigatórios abaixo. Requisitos de segurança obrigatórios: A conexão à API deve ser criptografada utilizando o protocolo TLS versão 1.2 ou superior, permitindo apenas cipher suites que atendam ao requisito de forward secrecy. O PSP deve implementar o framework OAuth 2.0 (RFC 6749) com TLS mútuo (mTLS – RFC 8705) para autenticação na API, conforme especificações abaixo: a. Os certificados digitais dos clientes da API poderão ser emitidos pelo próprio PSP ou por ACs externas, conforme definido por cada PSP. Não deverão ser aceitos certificados auto-assinados pelo cliente. b. Cada PSP deve possuir seu próprio Authorization Server e Resource Server associado à API Pix, e ambos devem implementar TLS mútuo. c. O Authorization Server do PSP deve implementar a técnica de vinculação do certificado do cliente aos access tokens emitidos (“Client Certificate-Bound Access Tokens”), conforme seção 3 da RFC 8705. d. O Resource Server do PSP deve confirmar que o thumbprint do certificado associado ao access token apresentado pelo cliente é o mesmo do utilizado na autenticação TLS (proof-of-possession). e. O fluxo OAuth a ser utilizado é o “Client Credentials Flow”. f. Os escopos OAuth serão definidos na especificação Open API 3.0 da API Pix e permitirão associar diferentes perfis de autorização ao software cliente. O processo de cadastro/onboarding do cliente para acesso à API deve ser realizado em ambiente logado no PSP, e deve incluir um canal seguro para envio das credenciais ao usuário, de forma a permitir a rastreabilidade das ações executadas. A API deve suportar múltiplos níveis de autorização ou papéis, segregando as funcionalidades de acordo com perfis (escopos OAuth) dos usuários clientes. O PSP deve implementar tecnologia que permita garantir a alta disponibilidade da API. A API deve garantir a confidencialidade e a integridade das informações dos usuários e de suas transações, tanto em trânsito como em repouso. O PSP deve manter logs de auditoria dos acessos à API pelo período mínimo de 1 ano. A credencial de acesso utilizada na autenticação (Client_ID) deve ser vinculada ao CNPJ ou CPF do usuário recebedor e deve permitir acesso a recursos apenas de contas transacionais de titularidade do CNPJ ou CPF associado. Para a funcionalidade de webhooks, as notificações oriundas do PSP recebedor ao usuário recebedor trafegarão utilizando um canal mTLS. a. Recomenda-se que os certificados utilizados para autenticação mútua no canal TLS do webhook sejam os mesmos da API Pix. De todo modo, não há objeção quanto à utilização de outros certificados, mediante acordo entre o PSP e o usuário recebedor. O BC entende que os PSPs poderão adotar as tecnologias e soluções de segurança para a API que mais acharem apropriados, desde que sejam atendidos os requisitos obrigatórios de segurança e, sempre que possível, as recomendações descritas acima, com atenção também aos elementos listados nos tópicos a seguir.

Boa noite @antonio.carlos. Vou ver se arrumo esta documentação e lhe passo. De qq forma e antecipadamente, afirmo que existe sim o uso do certificado. Já testei diretamente no Banco via postman. Homologação não precisa. Basta apenas clientId e clientSecret. Em produção, também funcionou, mas além destas credenciais acima descritas, precisei utilizar os certificados que o proprietário da conta me forneceu. Att

Muito obrigado pela ajuda @Juliomar Marchetti. Eu até cheguei a abrir o fonte da config em https://svn.code.sf.net/p/acbr/code/trunk2/Projetos/ACBrLib/Fontes/PIXCD/ACBrLibPIXCDConfig.pas. Sicoob e Bradesco realmente tem estas properties. Mas o Cielo está sem as mesmas. Agradeço se puder dar esta ajuda....

Mesmo problem para ArquivoChavePrivada ou ArqChavePrivada

Boa tarde e obrigado pelo auxílio. E qual é o nome da ACBRSessao que devo utilizar? Eu tentei Cielo mas aparece o erro dizendo que não existe este atributo na Sessão. Já tentei como ArqCertificado e como ArquivoCertificado. 16/10/24 18:01:06:343 - LIB_ConfigGravarValor(Cielo, ArquivoCertificado, C:\dev\pix\certificado\GV-BUS.cer) 16/10/24 18:01:06:354 - SetRetorno(-3, Chave [%s] não existe na Sessão [%s] no arquivo de configuração)

Boa tarde. Gostaria de saber como, no caso do PIX Produção do Banco Cielo, eu passo os dados dos certificados. Como podemos ver na imagem acima não existe a opção de certificados como no Banco Bradesco ou Sicoob por exemplo. Agradeço desde já a atenção e no aguardo.

Boa tarde. Gostaria de saber como, no caso do PIX Produção do Banco Cielo, eu passo os dados dos certificados. Como podemos ver na imagem acima não existe a opção de certificados como no Banco Bradesco ou Sicoob por exemplo. Agradeço desde já a atenção e no aguardo.

Muito obrigado pelos esclarecimentos @EliasCesar. Realmente eu estava achando que era a geração do qrCode para pagamento. Att

Boa tarde à todos. Entramos em contato com o Banco Itaú, para saber se existia algum processo, mais próximo da realidade do ambiente de produção, com o qual poderíamos realizar testes de carga, de preferência sem nos taxar. O mesmo nos informou que poderíamos realizar testes em PRODUÇÃO e sem a cobrança de taxas, desde de que incluíssemos no body da requisição um atributo conforme abaixo: "etapa_processo_boleto" : "validacao" Por um acaso tem alguma forma de a dll / so levar em conta este atributo? Se sim como devo setar o mesmo no ini de forma a ser levado em consideração, conforme orientações do Itaú? No mais agradeço e aguardo retorno. Att

E quando eu tento gerar um txId com 25 ou menos me é retornado um erro dizendo: "detail":"A requisição que busca alterar ou criar uma cobrança para pagamento imediato não respeita o _schema_ ou está semanticamente errada.","violations":[{"reason":"O parâmetro txid informado é inválido. Informe um txid com no mínimo 26 e no máximo 35 caracteres.","property":"txid" Ou seja: na hora de criar tenho de informar txId com 26 ou mais. Mas na hora do qrCode ele diz que tem de ser menos ou igual à 25 caracteres. Como proceder?

Apenas mais uma pergunta: Ao tentar passar meu txId, surge uma mensagem de erro dizendo que meu txId não pode ter mais de 25 caracteres. Mas o Cielo aceita. Quando gero, inclusive sem fornecer txId, onde eles me retornam 1 txId ele vem acima de 25. Este que envio abaixo acabou de ser gerado por eles: CIELO202409110000000000000000000173

Muito obrigado pela ajuda e agilidade Daniel.

Ahhh perfeito. Então eu devo informar sim estes dois dados. Como passo isto via .ini? Tem algum GRUPO específico para estes dois dados? E qual o nome correto de cada atributo no ini?

Boa tarde. O que mais devo passar para o PIXCD_GerarQRCodeEstatico além do "txId" e "valor"? Gerei um método onde a sequencia é (exibo abaixo apenas os mais importantes): ACBrPixLib.INSTANCE.PIXCD_Inicializar(eArqConfig, eChaveCrypt); ACBrPixLib.INSTANCE.PIXCD_ConsultarCobrancaImediata(toUTF8(ATxId), ARevisao, buffer, bufferLen); ACBrPixLib.INSTANCE.PIXCD_GerarQRCodeEstatico(AValor, toUTF8(AinfoAdicional), toUTF8(ATxID), buffer, bufferLen); Os dois primeiros comandos funcionam normalmente. No comando de gerar qrCode eu passo apenas o valor e o txId. Mas surge uma exception dizendo que: java.lang.Exception: Nome do Recebedor não informado Cidade do Recebedor não informada Como passo estes valores para conseguir recuperar o qrCode desta consulta? Att

Eles vão cancelar sua V1 no final de setembro de 2024 agora.

O itau informou que sua API de Boletos vai cancelar sua versão V1 e vai manter apenas a V2. Internamente a ACBR usa qual das versões do Itau?

Boa tarde e obrigado! Quando vc diz que "Você pode inicializar ela só uma vez quando inicia sua aplicação e finalizar ela quando encerra a aplicação." quer dizer da aplicação mesmo? Por exemplo: ao subir o .war no tomcat eu inicializo apenas no start e depois basta usar? Pq meu tomcat ficará meses sem restart por exemplo. Então neste tempo todas as consultas, gerações de boleto, cancelamentos utilizaram aqele obj inicializado no start do server? Ou vc quis dizer chamadas à minha aplicação?

Bom dia Júlio. Obrigado pelas informações e irei testar com estas alterações no tomcat. Em relação ao inicializar observe como está meu método: Este inicializar eu chamo ele a cada serviço executado: No inicio do método que gera um boleto eu chamo este inicializar. Assim como o chamo também no início do método de consultar boleto. Está correto? ou seja, eu inicializo a biblioteca passando um ponteiro a cada serviço chamado certo?

Bom dia. Gostaria de solicitar uma análise no erro citado abaixo. Instalei no mesmo server linux (VERSION="22.04.4 LTS (Jammy Jellyfish)") e no mesmo tomcat (apache-tomcat-10.1.24) os três wars (java 11) consumindo os .so de boleto, pix e cep. Quando utilizo as versões dos wars que consomem os arquivos .so comuns (sem ser Multi Thread) tudo funciona normalmente. Mas quando coloco os 3 wars, ou pelo menos um deles, como sendo Multi Thread acontece a situação abaixo (exemplos): * Executo a chamada de um serviço do BOLETO MT, por exemplo, o gerar cobrança. Este funciona normalmente e gera com sucesso. Qualquer chamada na sequencia que eu execute, se for do próprio BOLETO também funciona. Mas se eu executar qualquer serviço do PIX ou do CEP é gerado um Fatal error na dll do BOLETO. * Executo a chamada de um serviço do PIX MT, por exemplo, o gerar cobrança. Este funciona normalmente e gera com sucesso. Qualquer chamada na sequencia que eu execute, se for do próprio PIX também funciona. Mas se eu executar qualquer serviço do BOLETO ou do CEP é gerado um Fatal error na dll do PIX. * Executo a chamada de um serviço do CEP MT, por exemplo, o consultar por cep. Este funciona normalmente e retorna com sucesso. Qualquer chamada na sequencia que eu execute, se for do próprio CEP também funciona. Mas se eu executar qualquer serviço do BOLETO ou do PIX é gerado um Fatal error na dll do CEP. RESUMO: O primeiro .so MT instanciado funciona normalmente. Quando executo de um segundo .so MT (ou não) ele gera Fatal error no .so do primeiro que funcionou corretamente. Isto acontece apenas quando utilizo mais de um war e que pelo menos um esteja consumindo a versão MT. Não sei se está ocorrendo um conflito entre a primeira e segunda instância... Observação 01: Se eu colocar todos sem consumir o MT todos funcionam normalmente; Observação 02: Quando utilizo mais de 1 war e pelo menos 1 MT, obrigatoriamente tive de copiar os .so para a pasta default de libs do Linux. Se eu usar o comum (sem ser MT), é respeitado o endereço do .so que se encontra no .ini; Observação 03: Ao ser gerado o primeiro Fatal error nenhum mais é possível instanciar; Observação 04: Nada é gerado no log da biblioteca. Apenas no log do tomcat. Seguem os erros separados e que ocorrem de forma alternada. Fatal_libacbrboleto64.logFatal_libacbrpixcd64.logFatal_liblibacbrcep64.log Poderiam me auxiliar nesta? Att

Perfeito e obrigado!

Boa tarde Daniel. E o pior é que continua dando a mesma exception. Eu vi que ele apresenta: "liblibacbrcep64.so: não é possível abrir o arquivo de objeto compartilhado: esse arquivo ou diretório não existe" Mas em local algum eu tenho esta referência. De qq forma como vou implementar ponteiro para uso MT no Boleto, Pix e CEP. Então irei finalizar este do MT primeiro. Vai que o outro desaparece nesta????? kkkkk

Muito obrigado pelo esclarecimento Diego. Eu não sabia desta implementação com uso de ponteiros. Já o estou implementando aqui. Muito obrigado. Muito obrigado pelas orientações Daniel.

Pra não confundir os assuntos, abrimos um post separado o MT não funciona no linux na versão atual:

Boa tarde Srs. Estou utilizando o boleto em um ambiente Linux (arquivo .so). Até então venho utilizando o .so que se encontra na pasta Cdecl ou StdCall. Funcionando tudo normal desta forma. Só pelo fato de eu alterar o .so, utilizando a mesma versão, para o que se encontra na pasta MT/Linux ocorre o erro abaixo. Como deu o erro e já estou em ambiente de produção, voltei com o .so que funciona para dar continuidade. Já viram algo parecido? # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f236ec4c37b, pid=1489, tid=1514 # # JRE version: OpenJDK Runtime Environment (11.0.24+8) (build 11.0.24+8-post-Ubuntu-1ubuntu322.04) # Java VM: OpenJDK 64-Bit Server VM (11.0.24+8-post-Ubuntu-1ubuntu322.04, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # C [libacbrboleto64.so+0x24c37b] # # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/ubuntu/core.1489) # # An error report file with more information is saved as: # /home/ubuntu/hs_err_pid1489.log # # If you would like to submit a bug report, please visit: # https://bugs.launchpad.net/ubuntu/+source/openjdk-lts # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Att