In SOCKS5-proxy konfigurearje foar de Python-klant fan Azure Blob

Konfigurearje de oanlevere Requests-sesje sels, en hâld dan har libbensdoer bûten de synkrone Blob-klant mei session_owner=False.

import requests
from azure.core.pipeline.transport import RequestsTransport
from azure.storage.blob import BlobServiceClient

with requests.Session() as session:
    session.trust_env = False
    session.proxies["https"] = "socks5h://proxy.example:1080"
    transport = RequestsTransport(session=session, session_owner=False)
    with BlobServiceClient(
        account_url=account_url,
        credential=credential,
        transport=transport,
    ) as client:
        pass

Fier de bedoelde Blob-bewurking út yn plak fan pass, mei de account_url en credential fan 'e applikaasje. De opsjonele SOCKS-ôfhinklikens fan Requests moatte al oanwêzich wêze. socks5h delegetet de bestimming-DNS oan de proxy. Foar in publyk berikber Blob-einpunt dêr't publike tuskenlju tastien binne, leveret de SOCKS5-proxylist kandidaten foar de proxy-URL fan 'e sesje.

Set trust_env op dizze sesje om de omjouwingsyntegraasje fan Requests te kontrolearjen. RequestsTransport past syn omjouwingsinisjalisaasje ta as er in sesje oanmakket, net as der in besteande jûn wurdt. De eksplisite wearde false foarkomt dat proxy-omjouwingsynfier dizze rûte ferfangt.

Dy kar skeakelet ek op omjouwing basearre CA-seleksje út. Jou by needsaak connection_verify="/path/to/ca-bundle.pem" oan RequestsTransport, mei de woartels dy't foar de echte tsjinst nedich binne.

De Blob-klant slút foar de bûtenste sesjekontekst. session_owner=False lit it eigendom by dat bûtenste blok. In apart oanmakke tokenbewiis kin in oare HTTP-transport hawwe; konfigurearje it ek as de ferwerving SOCKS nedich hat.

Relatearre artikelen