Artemis può aggirare SOCKS per un broker in loopback

Una connessione al broker Artemis che riesce con la password SOCKS sbagliata potrebbe aver saltato il gestore proxy. Controllate la destinazione del broker, non solo socksHost.

La documentazione del transport descrive gli indirizzi broker in loopback, come localhost e 127.0.0.1, come indirizzi che aggirano la configurazione SOCKS. Per il normale percorso di risoluzione locale, usate l'indirizzo broker non loopback previsto quando la connessione deve passare attraverso l'intermediario. Un altro alias che si risolve ancora in loopback può dare lo stesso risultato.

Controllate la condizione esatta della versione del connector

Il codice sorgente più recente del connector upstream include un'eccezione remote-DNS esplicita. La condizione del gestore proxy è:

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

Con socksRemoteDNS abilitato in un'implementazione che contiene quella condizione, il connector lascia la destinazione non risolta e installa il gestore SOCKS anche per una destinazione che sembra loopback. Con il valore predefinito documentato false, il test dell'indirizzo locale conta ancora.

Ciò cambia il significato di un nome host come localhost: quando viene passato a un server SOCKS per la risoluzione, si riferisce alla vista della destinazione del proxy. Confermate che questa sia la posizione prevista del broker prima di scegliere la risoluzione remota.

Allineate il comportamento al client Artemis installato. Una volta che il gestore è realmente nel percorso, distinguete l'autenticazione SOCKS dall'autenticazione del broker e verificate il percorso di connessione risultante invece di considerare una sessione broker riuscita come prova che le credenziali proxy siano state usate.