Наладзьце SOCKS5-проксі для кліента Python Azure Blob

Наладзьце сам прадастаўлены сеанс Requests, затым трымайце яго жыццёвы цыкл па-за сінхронным кліентам Blob з 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

Выканайце прадугледжаную аперацыю Blob замест pass, выкарыстоўваючы account_url і credential праграмы. Неабавязковыя залежнасці SOCKS для Requests ужо павінны прысутнічаць. socks5h перадае DNS прызначэння проксі. Для публічна даступнай канчатковай кропкі Blob, дзе дазволены публічныя пасярэднікі, спіс проксі SOCKS5 прапануе кандыдатаў для проксі-URL сеанса.

Усталюйце trust_env у гэтым сеансе, каб кіраваць інтэграцыяй Requests з асяроддзем. RequestsTransport прымяняе ініцыялізацыю асяроддзя пры стварэнні сеанса, а не пры атрыманні існуючага. Яўнае значэнне false перашкаджае ўваходам асяроддзя проксі замяняць гэты маршрут.

Гэты выбар таксама адключае выбар CA на аснове асяроддзя. Пры неабходнасці перадайце connection_verify="/path/to/ca-bundle.pem" у RequestsTransport разам з каранямі, патрэбнымі для фактычнай службы.

Кліент Blob закрываецца перад знешнім кантэкстам сеанса. session_owner=False пакідае права ўласнасці за гэтым знешнім блокам. Маркерныя ўліковыя даныя, створаныя асобна, могуць мець іншы HTTP-транспарт; наладзьце іх таксама, калі іх атрыманне патрабуе SOCKS.

Падобныя артыкулы