Artemis יכול לעקוף את SOCKS עבור broker ב-loopback

ייתכן שחיבור broker של Artemis שמצליח עם סיסמת SOCKS שגויה עקף את מטפל ה-proxy. בדקו את יעד ה-broker, לא רק את socksHost.

תיעוד ה-transport מתאר כתובות broker מסוג loopback כגון localhost ו-127.0.0.1 ככאלה שעוקפות את תצורת SOCKS. עבור מסלול הפתרון המקומי הרגיל, השתמשו בכתובת ה-broker המיועדת שאינה loopback כאשר החיבור חייב לעבור דרך המתווך. ייתכן שכינוי אחר שעדיין נפתר ל-loopback יניב אותה תוצאה.

בדקו את התנאי המדויק של גרסת ה-connector

קוד המקור החדש יותר של ה-connector upstream כולל חריג remote-DNS מפורש. התנאי של מטפל ה-proxy הוא:

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

כאשר socksRemoteDNS מופעל ביישום שמכיל את התנאי הזה, ה-connector משאיר את היעד לא פתור ומתקין את מטפל SOCKS אפילו עבור יעד שנראה כמו loopback. עם ברירת המחדל המתועדת false, בדיקת הכתובת המקומית עדיין חשובה.

זה משנה את המשמעות של שם מארח כמו localhost: כאשר הוא מועבר לשרת SOCKS לפתרון, הוא מתייחס לתצוגת ה-proxy את היעד. אשרו שזהו מיקום ה-broker המיועד לפני בחירת פתרון מרוחק.

התאימו את ההתנהגות ללקוח Artemis המותקן. לאחר שהמטפל באמת נמצא במסלול, הבחינו בין אימות SOCKS לאימות broker ואמתו את נתיב החיבור המתקבל במקום להתייחס לסשן broker מוצלח כהוכחה לכך שנעשה שימוש בפרטי ה-proxy.