Agordi SOCKS5-prokurilon por la Python-kliento de Azure Blob

Agordu la provizitan Requests-sesion mem, poste tenu ĝian vivdaŭron ekster la sinkrona Blob-kliento per 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

Plenumu la celitan Blob-operacion anstataŭ pass, uzante la account_url kaj credential de la aplikaĵo. La nedevigaj SOCKS-dependaĵoj de Requests jam devas ĉeesti. socks5h delegas la celan DNS al la prokurilo. Por publike atingebla Blob-finpunkto, kie publikaj perantoj estas permesataj, la SOCKS5-prokurila listo provizas kandidatojn por la prokurila URL de la sesio.

Starigu trust_env en ĉi tiu sesio por regi la medikunigadon de Requests. RequestsTransport aplikas sian medisimplan inicializadon kiam ĝi kreas sesion, ne kiam oni donas al ĝi ekzistantan. La eksplicita valoro false malhelpas, ke medi-prokurilaj enigoj anstataŭigu ĉi tiun vojon.

Tiu elekto ankaŭ malŝaltas medi-bazitan CA-elekton. Se necese, donu connection_verify="/path/to/ca-bundle.pem" al RequestsTransport, kun la radikoj postulataj por la reala servo.

La Blob-kliento fermiĝas antaŭ la ekstera sesia kunteksto. session_owner=False lasas la posedon ĉe tiu ekstera bloko. Tokena akreditaĵo kreita aparte povas havi alian HTTP-transporton; agordu ĝin ankaŭ se ĝia akiro bezonas SOCKS.

Rilataj artikoloj