In einer Anwendung, die bereits das Azure IoT Python SDK verwendet, werden der MQTT-Transport und seine Proxy-Optionen gemeinsam gewählt. Diese Konfiguration wählt MQTT über 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
)

Die Klassen stammen aus der dokumentierten Schnittstelle des SDK. Übergeben Sie die Verbindungszeichenfolge des Geräts über die geheime Konfiguration der Anwendung und ersetzen Sie den Beispiel-Proxyendpunkt. Für einen öffentlich erreichbaren IoT Hub-Endpunkt, an dem öffentliche Vermittler zulässig sind, bietet die HTTP-Proxy-Liste Kandidaten für HTTP-Host und -Port; bestätigen Sie, dass der Dienst die Route zum Ziel zulässt. Dies sind ausdrückliche SDK-Optionen; ein im Browser funktionierender Proxy oder eine allgemeine Betriebssystemeinstellung legt die Route des Geräteclients nicht fest.

Prüfen Sie die ProxyOptions-Referenz für den gewählten Proxytyp. Sie unterscheidet Felder für HTTP, SOCKS4 und SOCKS5 und dokumentiert das typspezifische Verhalten von Benutzername und Kennwort, einschließlich Einschränkungen für HTTP. Das Vorhandensein eines Feldes verspricht nicht jedes Authentifizierungsverfahren.

Das Proxy-Konto und die Geräteidentität autorisieren unterschiedliche Stufen. Ein abgelehnter Austausch über einen Vermittler kann die Verbindung beenden, bevor der Broker die Geräte-Anmeldedaten auswertet. Die Wahl von WebSockets lässt auch die Ziel- und Zugriffsbeschränkungen des Proxys in Kraft.

Halten Sie den gewählten Transport, das Ziel und die erste fehlgeschlagene Stufe fest. SDK-Client, Proxy-Implementierung und zulässige Route müssen übereinstimmen; weder eine erfolgreiche Browseranfrage noch die allgemeine Behauptung, SOCKS trage jedes Protokoll, liefert diese Kompatibilität.

Ähnliche Artikel