Pesquisar na Comunidade

Olá pessoal, Estou enfrentando dificuldades para instalar e operar o PayGo Desktop (SetupPayGo_full_v5.1.47.2) em um ambiente corporativo que utiliza proxy para controle de tráfego, e gostaria de compartilhar o cenário e ouvir experiências da comunidade. Cenário técnico Durante os testes, observei os seguintes pontos: O instalador (aparentemente desenvolvido em Delphi) tenta acessar os endereços listados na documentação oficial https://paygodev.readme.io/docs/rede-e-conectividade sem respeitar o proxy configurado no sistema operacional. Inicialmente considerei que fosse uma limitação apenas do programa de teste. Para avançar, fiz um bypass temporário (ambiente isolado / “Q.G”) apenas para concluir a instalação. Antes que perguntem: Todas as portas indicadas no manual já estavam liberadas no proxy; Um chamado foi aberto junto ao suporte (SETSIS), mas não houve retorno técnico conclusivo — apenas postergação. Durante a análise de tráfego, identifiquei dois endereços adicionais não documentados, que também são acessados pelo sistema: Isso por si só já indica inconsistência ou incompletude da documentação oficial. cef.dfnofd.com.br global.dfnofd.com.br Realizei testes de conectividade via PowerShell, validando todas as portas do manual + os dois endereços acima. Resultado: conectividade OK em todos os casos, quando respeitado o proxy. A conclusão técnica foi objetiva: o PayGo Desktop não funciona atrás de proxy corporativo. Isso levanta alguns pontos críticos: 6.1) O manual não deixa isso explícito; 6.2) A solução parece depender de instalação de componentes adicionais (ex.: Warshall), operando fora de um modelo minimamente seguro — basicamente “libera tudo, instala um antivírus e torce”. Diante dessa controvérsia, a homologação foi encerrada internamente (CERTIFICAÇÃO CANCELADA). Independentemente do hardware adquirido (ex.: GERTEC), não houve interesse do fornecedor em: corrigir o manual, ou ajustar o comportamento do software. Nota: Mesmo que o cliente opte por realizar um bypass no proxy exclusivamente para os endereços indicados no manual oficial, não há qualquer garantia de estabilidade operacional. Parte significativa desses endpoints está hospedada em infraestruturas Cloud (Cloudflare / AWS / Azure), cujos endereços IP são dinâmicos e podem ser alterados a qualquer momento, sem aviso prévio. Isso inviabiliza tecnicamente a criação de regras estáticas de bypass baseadas em IP, pois: As regras podem deixar de funcionar de forma imprevisível; O PDV pode falhar subitamente em produção; O cliente passa a operar em modo reativo, correndo atrás de incidentes; Há impacto direto em SLA, suporte e operação. Em outras palavras, mesmo aceitando a “aberração” de furar o proxy, o cliente não obtém confiabilidade, apenas mais risco operacional e mais manutenção. Esse modelo transfere para o cliente: o ônus da instabilidade, a responsabilidade por falhas de conectividade, e o risco de interrupção de serviço crítico (meio de pagamento), sem qualquer controle técnico real. Perguntas objetivas Alguém aqui utiliza PayGo Desktop atrás de proxy corporativo? Se sim, qual foi a abordagem técnica adotada? É considerado normal o PDV operar com acesso direto e irrestrito à internet, sem proxy, em ambientes produtivos? Como justificar esse modelo para clientes de grande porte, com requisitos rígidos de Compliance, Segurança e Auditoria? Alguém já enfrentou esse cenário em clientes enterprise? Eles aceitaram essa limitação como “restrição tecnológica” do produto? É aceitável, do ponto de vista de mercado, operar senha e cartão em uma máquina totalmente liberada para internet? A solução técnica seria simples: Liberar geral (PDV fique exposto diretamente à internet inviabiliza completamente a adoção em ambientes corporativos sérios.) Corrigir o PayGo - para usar rotinas que respeite o proxy desde que sigam o manual l Agradeço desde já qualquer relato ou experiência compartilhada. Nota: Se já não bastasse, alguns endereços são CloudFare/AWS/Azure (que podem trocar de IP) inviabilizando uma regra de "bypass" para o que está no manual - Gerando transtorno no cliente que aceitar essa abominação

Pessoal, boa tarde! Estou com um problema que ainda não consegui entender. Tenho um emissor de nfe que pode rodar tanto como aplicação quanto como serviço. Rodando como serviço está tudo ok, porém quando rodo como aplicação e tento enviar uma nota a janela de proxy abre requisitando usuário e senha, e essas são informadas devidamente. Ao continuar a emissão recebo o erro: First chance exception at $758D4B32. Exception class ESOAPHTTPException with message 'É necessário um certificado para concluir a autenticação do cliente - URL:https://homologacao.nfe.fazenda.pr.gov.br/nfe/NFeAutorizacao3?wsdl - SOAPAction:http://www.portalfiscal.inf.br/nfe/wsdl/NfeAutorizacao'. A aplicação continuar e apenas salvo essa informação para o usuário. Em seguida se tento consultar a nota começo a receber alguns AV: First chance exception at $0040AEFA. Exception class $C0000005 with message 'access violation at 0x0040aefa: write of address 0x00430002'. O erro acontece na unit "ACBrDFeCapicom" dentro do método "function TDFeCapicom.Enviar(const ConteudoXML: String; const URL: String; const SoapAction: String; const MimeType: String): String;", na chamada do método "Executar(ConteudoXML, Resp);" O certificado está devidamente configurado, tanto que ao rodar como serviço ele emite as notas.

Olá, sou novo no grupo e estou migrando projeto NFe_Util (c#) para ACBrNFe. Estamos com problemas em relação aos clientes que utilizam proxy (praticamente todos) pois anteriormente, ainda que o IE estivesse configurado para proxy, nosso sistema ignorava o proxy e utilizava o WebProxy.GetDefaultProxy e NetworkCredential. Com isto, o sistema estabelecia conexão com os webservices da Sefaz mas o usuário não tinha permissão de navegar na internet pelo browser. Mas com ACBr os clientes precisam configurar as propriedades de proxy (host,port,user,passw), caso contrário dá erro Proxy 407 (não autenticado). Entretanto, uma vez que a conexão é estabelecida (Ex: ConsultarStatus) o usuário passa a ter acesso à internet e pode navegar de boa. Minha dúvida: 1) Este é o comportamento comum de conexão com proxy para HttpReqResp? Ou estou fazendo algo errado? 2) Sendo este o comportamento, teria como fazer o logoff nesta autenticação do IE para novamente bloquear à internet? Obrigado,

Bom dia amigos, não estou conseguindo enviar email, quando tem proxy, o retorno recebido é esse: Erro ao enviar email SMTP ERROR: Login:???-Other undefined Status se alguém puder ajudar agradeço.