Azure IoT Python: הגדרת MQTT מעל WebSockets דרך פרוקסי
הגדירו את אפשרויות הפרוקסי הנתמכות של לקוח Azure IoT Python ובחרו MQTT מעל WebSockets במכוון.
ביישום שכבר משתמש ב-Azure IoT Python SDK, בחרו את תעבורת MQTT ואת אפשרויות הפרוקסי שלה יחד. תצורה זו בוחרת MQTT מעל WebSockets:
proxy = ProxyOptions(proxy_type='HTTP',
proxy_addr='203.0.113.10', proxy_port=8080)
client = IoTHubDeviceClient.create_from_connection_string(
connection_string, websockets=True, proxy_options=proxy
)
המחלקות מגיעות מממשק ה-SDK המתועד. ספקו את מחרוזת החיבור של ההתקן דרך התצורה הסודית של היישום והחליפו את נקודת הקצה לדוגמה של הפרוקסי. עבור נקודת קצה של IoT Hub הנגישה לציבור שבה מתווכים ציבוריים מותרים, רשימת פרוקסי ה-HTTP מציעה מועמדים עבור מארח ה-HTTP והפורט; ודאו שהשירות מתיר את המסלול ליעד. אלו אפשרויות מפורשות של ה-SDK; פרוקסי שעובד בדפדפן או הגדרה כללית של מערכת ההפעלה אינה מבססת את המסלול של לקוח ההתקן.
עיינו במפנה ProxyOptions עבור סוג הפרוקסי שנבחר. הוא מבדיל בין שדות HTTP, SOCKS4 ו-SOCKS5 ומתעד התנהגות שם משתמש/סיסמה ספציפית לסוג, כולל מגבלות עבור HTTP. נוכחות של שדה אינה מבטיחה כל מנגנון אימות.
חשבון הפרוקסי וזהות ההתקן מאשרים שלבים שונים. חילופי מתווך שנדחו יכולים לעצור את החיבור לפני שהברוקר מעריך את פרטי ההתקן. בחירת WebSockets גם משאירה בתוקף את מגבלות היעד והגישה של הפרוקסי.
תעדו את התעבורה שנבחרה, את היעד ואת השלב הראשון שנכשל. לקוח ה-SDK, מימוש הפרוקסי והמסלול המותר חייבים להסכים; לא בקשת דפדפן מוצלחת ולא טענה כללית ש-SOCKS נושא כל פרוטוקול מספקים את התאימות הזו.