I-configure ang SOCKS5 Proxy para sa Python Client ng Azure Blob

I-configure ang ibinigay na Requests session mismo, pagkatapos ay panatilihin ang tagal ng buhay nito sa labas ng synchronous Blob client gamit ang 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

Isagawa ang nilalayong operasyon ng Blob kapalit ng pass, gamit ang account_url at credential ng application. Ang opsyonal na SOCKS dependencies ng Requests ay dapat naroroon na. Itinatalaga ng socks5h ang DNS ng destinasyon sa proxy. Para sa pampublikong naa-access na Blob endpoint kung saan pinapayagan ang mga pampublikong tagapamagitan, ang listahan ng SOCKS5 proxy ay nagbibigay ng mga kandidato para sa proxy URL ng session.

Itakda ang trust_env sa session na ito upang kontrolin ang integrasyon ng Requests sa environment. Inilalapat ng RequestsTransport ang initialization ng environment kapag gumagawa ito ng session, hindi kapag binibigyan ito ng umiiral na. Pinipigilan ng tahasang false na halaga ang mga input ng proxy environment na palitan ang rutang ito.

Hindi rin pinapagana ng pagpipiliang iyon ang pagpili ng CA batay sa environment. Kung kailangan, ibigay ang connection_verify="/path/to/ca-bundle.pem" sa RequestsTransport, kasama ang mga root na kailangan para sa aktwal na serbisyo.

Nagsasara ang Blob client bago ang panlabas na konteksto ng session. Iniiwan ng session_owner=False ang pagmamay-ari sa panlabas na bloke na iyon. Ang token credential na ginawa nang hiwalay ay maaaring may ibang HTTP transport; i-configure din ito kung ang pagkuha nito ay nangangailangan ng SOCKS.

Kaugnay na mga artikulo