Artemis może ominąć SOCKS dla brokera loopback

Połączenie z brokerem Artemis, które kończy się sukcesem z błędnym hasłem SOCKS, mogło pominąć procedurę proxy. Sprawdź miejsce docelowe brokera, nie tylko socksHost.

Dokumentacja transportu opisuje adresy brokera loopback, takie jak localhost i 127.0.0.1, jako adresy omijające konfigurację SOCKS. W normalnej ścieżce rozwiązywania lokalnego użyj zamierzonego adresu brokera innego niż loopback, gdy połączenie musi przechodzić przez pośrednika. Inny alias, który nadal rozwiązuje się do loopback, może dać ten sam wynik.

Sprawdź dokładny warunek wersji connectora

Nowszy kod źródłowy connectora upstream zawiera jawny wyjątek remote-DNS. Warunek procedury proxy to:

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

Gdy socksRemoteDNS jest włączony w implementacji zawierającej ten warunek, connector pozostawia miejsce docelowe nierozwiązane i instaluje procedurę SOCKS nawet dla celu wyglądającego jak loopback. Przy udokumentowanej wartości domyślnej false test adresu lokalnego nadal ma znaczenie.

To zmienia znaczenie nazwy hosta takiej jak localhost: gdy jest przekazywana do serwera SOCKS do rozwiązania, odnosi się do widoku miejsca docelowego przez proxy. Potwierdź, że jest to zamierzone położenie brokera, zanim wybierzesz rozwiązywanie zdalne.

Dopasuj zachowanie do zainstalowanego klienta Artemis. Gdy procedura rzeczywiście znajduje się w trasie, odróżnij uwierzytelnianie SOCKS od uwierzytelniania brokera i zweryfikuj wynikową ścieżkę połączenia, zamiast traktować udaną sesję brokera jako dowód użycia danych proxy.