تهيئة وكيل 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.