I en applikasjon som allerede bruker Azure IoT Python SDK, velges MQTT-transporten og proxyvalgene sammen. Denne konfigurasjonen velger MQTT over 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
)

Klassene kommer fra SDK-ens dokumenterte grensesnitt. Oppgi tilkoblingsstrengen til enheten gjennom applikasjonens hemmelige konfigurasjon og erstatt eksempelendepunktet for proxyen. For et offentlig tilgjengelig IoT Hub-endepunkt der offentlige mellomledd er tillatt, tilbyr HTTP-proxylisten kandidater for HTTP-vert og -port; bekreft at tjenesten tillater ruten til målet. Dette er eksplisitte SDK-valg; en proxy som virker i nettleseren, eller en generell innstilling i operativsystemet, etablerer ikke ruten til enhetsklienten.

Se ProxyOptions-referansen for den valgte proxytypen. Den skiller mellom HTTP-, SOCKS4- og SOCKS5-felt og dokumenterer typeavhengig atferd for brukernavn/passord, inkludert begrensninger for HTTP. At et felt finnes, lover ikke alle autentiseringsmekanismer.

Proxykontoen og enhetsidentiteten autoriserer ulike trinn. En avvist utveksling via mellomledd kan stoppe tilkoblingen før megleren vurderer enhetens legitimasjon. Å velge WebSockets lar også proxyens begrensninger for mål og tilgang gjelde.

Noter den valgte transporten, målet og det første trinnet som feilet. SDK-klienten, proxyimplementasjonen og den tillatte ruten må stemme overens; verken en vellykket nettleserforespørsel eller påstanden om at SOCKS bærer enhver protokoll gir den kompatibiliteten.

Relaterte artikler