Artemis pot saltar-se SOCKS per a un broker de loopback
Comproveu la destinació del broker i el comportament de socksRemoteDNS quan una connexió d'Artemis té èxit malgrat credencials SOCKS deliberadament incorrectes.
Una connexió al broker d'Artemis que té èxit amb la contrasenya SOCKS incorrecta pot haver saltat el gestor de proxy. Comproveu la destinació del broker, no només socksHost.
La documentació del transport descriu les adreces de broker loopback com localhost i 127.0.0.1 com a adreces que se salten la configuració SOCKS. Per a la ruta normal de resolució local, feu servir l'adreça de broker no loopback prevista quan la connexió ha de passar per l'intermediari. Un altre àlies que encara es resolgui a loopback pot tenir el mateix resultat.
Comproveu la condició exacta de la versió del connector
El codi font més recent del connector upstream inclou una excepció explícita de remote-DNS. La condició del gestor de proxy és:
socksEnabled && (socksRemoteDNS || !isTargetLocalHost())Amb socksRemoteDNS activat en una implementació que contingui aquesta condició, el connector manté la destinació sense resoldre i instal·la el gestor SOCKS fins i tot per a una destinació que sembla loopback. Amb el valor predeterminat documentat false, la prova d'adreça local encara importa.
Això canvia el significat d'un nom d'amfitrió com localhost: quan es passa a un servidor SOCKS per resoldre'l, fa referència a la visió de destinació del proxy. Confirmeu que aquesta és la ubicació prevista del broker abans de triar la resolució remota.
Feu coincidir el comportament amb el client Artemis instal·lat. Un cop el gestor és realment a la ruta, distingiu l'autenticació SOCKS de l'autenticació del broker i verifiqueu el camí de connexió resultant en lloc de tractar una sessió de broker reeixida com a prova que s'han utilitzat les credencials del proxy.