O Artemis pode contornar o SOCKS para um broker em loopback

Uma conexão ao broker Artemis que é bem-sucedida com a palavra-passe SOCKS errada pode ter ignorado o gestor de proxy. Verifique o destino do broker, não apenas o socksHost.

A documentação do transport descreve endereços de broker em loopback, como localhost e 127.0.0.1, como endereços que contornam a configuração SOCKS. Para o percurso normal de resolução local, use o endereço de broker não loopback pretendido quando a conexão tiver de passar pelo intermediário. Outro alias que ainda resolva para loopback pode dar o mesmo resultado.

Verifique a condição exata da versão do connector

O código-fonte mais recente do connector upstream inclui uma exceção remote-DNS explícita. A condição do gestor de proxy é:

socksEnabled && (socksRemoteDNS || !isTargetLocalHost())

Com socksRemoteDNS ativado numa implementação que contenha essa condição, o connector mantém o destino por resolver e instala o gestor SOCKS mesmo para um destino que pareça loopback. Com o valor predefinido documentado false, o teste do endereço local continua a ser importante.

Isso altera o significado de um nome de anfitrião como localhost: quando é passado a um servidor SOCKS para resolução, refere-se à vista do destino pelo proxy. Confirme que esta é a localização pretendida do broker antes de escolher a resolução remota.

Alinhe o comportamento com o cliente Artemis instalado. Depois de o gestor estar realmente no percurso, distinga a autenticação SOCKS da autenticação do broker e verifique o percurso de conexão resultante em vez de tratar uma sessão de broker bem-sucedida como prova de que foram usadas credenciais de proxy.