Ir para conteúdo
  • Cadastre-se

dev botao

  • Este tópico foi criado há 1228 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Recommended Posts

Postado (editado)

Olá pessoal.

De uns tempos pra cá venho tendo alguns chamados relativos a problemas de comunicação com o TLS1.2 usando a httpWinHttp, grande maioria devido as atualizações do windows(ou a falta delas), estive buscando então alternativas para evitar esse transtorno:

A httpWinINet depende de configurações do IE,  que de vez em quando são alteradas por outros aplicativos e acabam causando o mesmo problema.

A httpOpenSSL além de causar dependências das Dlls acho que só vai de A1 e infelizmente tem uns que insistem no A3.

Um opção seria usar a HttpIndy, que não depende de configurações do IE e aparentemente não é afetada pelos updates do windows,  porém nos Delphi mais novos não estava funcionando direito devido a mudanças na RTL. Apresentava o erro "Erro ao ajustar INTERNET_OPTION_CLIENT_CERT_CONTEXT".

Dei uma mexida nela e consegui fazer funcionar, nos testes com a NFe transmitiu normalmente no Rio 10.3.1, inclusive estou testando em alguns clientes onde a httpWinHttp estava apresentando problemas,  porém não tenho outras versões do Delphi instaladas aqui pra testar.

 

Vou deixar em anexo se alguém quiser testar/melhorar e enviar para  repositório.

 

ACBrDFeHttpIndy.pas

Editado por Delcio
Erro de digitação
  • Curtir 4
  • Fundadores
Postado

Obrigado pela implementação... ficou muito bacana...

Mas notei que no método "OnNeedClientCertificate", ele somente irá considerar os certificados que estão instalados no Windows... e com isso não há como informar o certificado que já foi carregado pelo ACBr,  e está em "FpDFeSSL.CertContextWinApi"

Sabe se haveria alguma possibilidade dessa implementação trabalhar com Arquivo PFX, externo ?

Consultor SAC ACBr

Daniel Simões de Almeida
O melhor TEF, é com o Projeto ACBr - Clique e Conheça
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Postado
1 hora atrás, Daniel Simoes disse:

... no método "OnNeedClientCertificate", ele somente irá considerar os certificados que estão instalados no Windows....

Pois é, não me atentei a esse detalhe, nos meus clientes estão todos instalados,  vou verificar se tem como resolver isso.

Postado

Olá.

Consegui fazer funcionar com o Context do TDFeSSL, porém teria que ver se o inicio da assinatura da classe TWinHTTPClient não mudou nas versões mais novas, tenho só o D10.3.1 aqui.

Está em anexo, se quiser dar uma olhada.

Talvez fosse melhor implementar uma classe HTTP do zero, baseada em Indy ou outra biblioteca mais independente da RTL, já que a TDFeHttpIndy atualmente nem usa Indy mais.

Assim que conseguir um tempo vou dar uma pesquisada sobre algo nesse sentido.

Em um cenário ideal ela teria que:

  • Compilar em x68 e x64;
  • Não depender da API do S.O, isso permitiria:
    • Compilar para Linux;
    • Não depender de configurações do S.O.;
    • Não depender de atualizações do S.O;
  • Ser compatível com FPC;
  • Permitir certificado de cliente sem instalação;
  • Permitir certificados A3 e A1;
  • Suportar SSL, TLS, mais algum?
  • Evitar dependência de bibliotecas externas(DLLs);

Esqueci de algo?

 

ACBrDFeHttpIndy.pas

  • Curtir 1
Postado

Fiz mais uns testes por aqui criando uma classe http 100% Indy, tive alguma evolução, mas acho que vou ter que partir pra outra biblioteca.

O Indy usa OpenSSl para a conexão segura, consegui fazer o Indy funcionar com o certificado carregado no ACBr usando OpenSSl, funcionou tanto com Certificado A3 quanto com A1 carregado em memória, mas fui barrado por outro problema:

Parece que o Indy ainda não suporta as versões mais novas da OpenSSL, daí só funcionou com TLS 1.1, que não nos atende.

Vou tentar outro caminho: Alterar a TDFeHttpOpenSSL para suportar certificado A3, se der certo acho que teríamos quase todas as vantagens:

 

Em 23/05/2020 at 17:52, Delcio disse:
  • Compilar em x68 e x64;
  • Não depender da API do S.O, isso permitiria:
    • Compilar para Linux;
    • Não depender de configurações do S.O.;
    • Não depender de atualizações do S.O;
  • Ser compatível com FPC;
  • Permitir certificado de cliente sem instalação;
  • Permitir certificados A3 e A1;
  • Suportar SSL, TLS, mais algum?
  • Evitar dependência de bibliotecas externas(DLLs);

 

 

 

Postado (editado)
24 minutos atrás, Juliomar Marchetti disse:

...estão descontinuando as dependencias que existem do Indy para códigos nativos...

 

Percebi isso, boa parte está sendo direcionada para System.Net, mas acho ela muito "dependente" das APIs do SO, e muito fechada também, por exemplo a implementação para o windows está em System.Net.HttpClient.Win e fica toda na seção implementation da Unit, muito engessada na minha opinião.

Não consigo usar o certificado carregado no ACBr com ela, e não consigo herdar para sobrescrever algo, até consigo registrar outra classe com  TURLSchemes.RegisterURLClientScheme para usar com o windows por exemplo, mas tem que implementar toda ela. 

Minha ideia inicial com Indy seria fazer uma implementação independente e talvez colocar na pasta terceiros, para ficar independente das IDEs. mas acho que não vai dar com Indy, vamos ver com o Synalist, que já tem no ACBr inclusive.

Editado por Delcio
  • Curtir 1
  • 2 meses depois ...
Postado (editado)

Experimentei o mesmo problema relatado pelo @Delcio na primeira mensagem.

Baixei a implementação da unit disponibilizada neste post e o erro foi sanado, a NFe é emitida sem erro, compilando no 10.3.3.
Fiz apenas uma alteração, que foi a remoção do uses da Winapi.WinHTTP.

Pesquisei um pouco a respeito da origem do problema e encontrei a resposta que foi definitiva para mim: A partir do Delphi Rio (10.3) o evento 

THTTPReqResp.OnBeforePost

teve a sua assinatura alterada de 

OnBeforePost(const HTTPReqResp: THTTPReqResp; ARequest: Pointer)

para

OnBeforePost(const HTTPReqResp: THTTPReqResp; Client: THTTPClient);

Como é visível, não temos mais o ponteiro do Request para acionar o método InternetSetOption que era utilizado até então para informar o certificado digital.
Na nova implementação, o @Delcio estendeu THTTPClient para ter acesso ao FWinCertList, se valendo disto e do evento OnNeedClientCertificate para setar o certificado digital.
As configurações de proxy continuam sendo setadas em OnBeforePost mas de uma forma diferente, setando direto no THTTPClient, visto que não há mais acesso ao Pointer.
 

A questão que trago é que estes ajustes necessários para se adequar às novas versões do Delphi, em especial, às novas implementações do Indy, ainda não estão disponíveis no SVN do ACBr.

Seria possível disponibilizar no SVN?
Há alguma pendência a ser resolvida na unit antes que seja disponibilizada?

Editado por Eliezer Riani de Andrade
  • Curtir 2
  • Consultores
Postado
17 horas atrás, Eliezer Riani de Andrade disse:

Há alguma pendência a ser resolvida na unit antes que seja disponibilizada?

Me parece que o próprio Delcio mencionou esses pontos como pendências, veja:

Em 23/05/2020 at 17:52, Delcio disse:

Em um cenário ideal ela teria que:

  • Compilar em x68 e x64;
  • Não depender da API do S.O, isso permitiria:
    • Compilar para Linux;
    • Não depender de configurações do S.O.;
    • Não depender de atualizações do S.O;
  • Ser compatível com FPC;
  • Permitir certificado de cliente sem instalação;
  • Permitir certificados A3 e A1;
  • Suportar SSL, TLS, mais algum?
  • Evitar dependência de bibliotecas externas(DLLs);

 

  • Curtir 1

[]'s

Consultor SAC ACBr

Elton
Profissionalize o ACBr na sua empresa, conheça o ACBr Pro.

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Um engenheiro de Controle de Qualidade(QA) entra num bar. Pede uma cerveja. Pede zero cervejas.
Pede 99999999 cervejas. Pede -1 cervejas. Pede um jacaré. Pede asdfdhklçkh.
Postado
3 horas atrás, EMBarbosa disse:

Me parece que o próprio Delcio mencionou esses pontos como pendências, veja:

Eu entendo que ele citou qual seriam as características ideais para uma biblioteca, sendo que, até o momento, nenhuma das que o ACBr utiliza atende a todas as características. Nem por isso elas deixam de estar funcionais para um ou outro ambiente, estando sempre atualizadas no SNV.

O que está acontecendo neste momento com a versão da ACBrDFeHttpIndy disponível no SVN é que ela sempre vai lançar o Exception no Delphi Rio, pois chama a procedure InternetSetOption passando no primeiro parâmetro um THTTPClient, quando na verdade, deveria passar um hInternet, ou seja, está inutilizável.

Com a alteração proposta pelo @Delcio, temos a ACBrDFeHttpIndy funcional novamente, ainda que continue não tendo as "características ideais", ela mentém a implementação atual para os compiladores < 33 (até Delphi Tokyo) e introduz a nova implementação adequada ao Delphi Rio.

 

  • 10 meses depois ...
Postado

Obrigado Delcio ,estava sofrendo aqui com uma migração do delphi xe3 onde usavamos o beforepost para inserir o certificado, na versão 10.3 não funciona mais. o InternetSetOption
percebo que este codigo esta inserido no acbr, mais não funciona no Rio.
Uma coisa que acho curioso e que esta como TDFeHttpIndy, acredito que não tenha nada a ver com indy esta implementação pois o componente

e na verdade um THTTPReqResp 100% nativo do delphi, inclusive no meu projeto eu usava diretamente  o THTTPReqResp sem nem mesmo usar indy ou o acbr.

 

  • Este tópico foi criado há 1228 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Crie uma conta ou entre para comentar

Você precisar ser um membro para fazer um comentário

Criar uma conta

Crie uma nova conta em nossa comunidade. É fácil!

Crie uma nova conta

Entrar

Já tem uma conta? Faça o login.

Entrar Agora
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.