SOCKS5 პროქსის კონფიგურაცია Azure Blob-ის Python კლიენტისთვის

კონფიგურეთ მოწოდებული 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 გამოყენებით. Requests-ის არასავალდებულო SOCKS დამოკიდებულებები უკვე უნდა იყოს წარმოდგენილი. 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-ს მოითხოვს.

დაკავშირებული სტატიები