SOCKS5-Proxy fir den Python-Client vun Azure Blob konfiguréieren

Konfiguréiert déi geliwwert Requests-Sessioun selwer, a haalt dann hir Liewensdauer ausserhalb vum synchrone Blob-Client mat 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

Fëllt déi virgesinn Blob-Operatioun amplaz vun pass aus, andeems Dir account_url an credential vun der Applikatioun benotzt. D'optional SOCKS-Ofhängegkeete vun Requests mussen schonn do sinn. socks5h delegéiert den DNS vum Zil un de Proxy. Fir en ëffentlech erreechbaren Blob-Endpunkt, wou ëffentlech Vermëttler erlaabt sinn, bitt d'SOCKS5-Proxy-Lëscht Kandidaten fir d'Proxy-URL vun der Sessioun.

Setzt trust_env op dëser Sessioun, fir d'Ëmweltintegratioun vun Requests ze kontrolléieren. RequestsTransport applizéiert seng Ëmweltinitialiséierung, wann en eng Sessioun erstellt, net wann him eng existéierend gëtt. Den explizite Wäert false verhënnert, datt Proxy-Ëmweltinputen dëse Wee ersetzen.

Dës Wiel deaktivéiert och d'CA-Auswiel op Basis vun der Ëmwelt. Wann néideg, gitt connection_verify="/path/to/ca-bundle.pem" un RequestsTransport, mat de Wuerzelen, déi fir den tatsächlechen Service néideg sinn.

De Blob-Client gëtt virum äusseren Sessiounskontext zougemaach. session_owner=False léisst den Eegentum bei deem äussere Block. En separat erstallte Token-Identitéitsnoweis kann en aneren HTTP-Transport hunn; konfiguréiert en och, wann seng Beschafung SOCKS brauch.

Ähnlech Artikelen