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.

مقالات ذات صلة