Konfigureer 'n SOCKS5-proxy vir Azure Blob se Python-kliënt

Konfigureer die verskafde Requests-sessie self en hou die leeftyd daarvan buite die sinchroniese Blob-kliënt met 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

Voer die beoogde Blob-bewerking uit in plaas van pass en gebruik die toepassing se account_url en credential. Requests se opsionele SOCKS-afhanklikhede moet reeds teenwoordig wees. socks5h delegeer die bestemming-DNS aan die proxy. Vir 'n publiek bereikbare Blob-eindpunt waar openbare tussengangers toegelaat word, verskaf die SOCKS5-proxylys kandidate vir die sessie se proxy-URL.

Stel trust_env op hierdie sessie om Requests se omgewingsintegrasie te beheer. RequestsTransport pas sy omgewingsinisialisering toe wanneer dit 'n sessie skep, nie wanneer 'n bestaande een gegee word nie. Die eksplisiete valse waarde verhoed dat proxy-omgewingsinsette hierdie roete vervang.

Daardie keuse skakel ook omgewinggebaseerde CA-seleksie af. Indien nodig, gee connection_verify="/path/to/ca-bundle.pem" aan RequestsTransport, met wortels wat vir die werklike diens vereis word.

Die Blob-kliënt sluit voor die buitenste sessiekonteks. session_owner=False laat eienaarskap by daardie buitenste blok. 'n Token-credential wat afsonderlik geskep is, kan 'n ander HTTP-vervoer hê; konfigureer dit ook as die verkryging daarvan SOCKS nodig het.

Verwante artikels