تحقّق من استيراد Authlib قبل اختيار وسيط الوكيل. فتكاملَا Requests وHTTPX يوفّران إعدادات نقل مختلفة.

يرث OAuth2Session الخاص بـ Requests سلوك Session في Requests:

from authlib.integrations.requests_client import OAuth2Session

client = OAuth2Session(client_id=client_id)
client.proxies.update({
    "http": "http://proxy.example.net:8080",
    "https": "http://proxy.example.net:8080",
})

أما تكامل HTTPX غير المتزامن المقابل فيأخذ وسيط الوكيل على مستوى العميل أثناء الإنشاء:

from authlib.integrations.httpx_client import AsyncOAuth2Client

client = AsyncOAuth2Client(
    client_id=client_id,
    proxy="http://proxy.example.net:8080",
)

يستخدم مثال HTTPX خيار proxy المفرد الذي يدعمه Authlib 1.9.1. ويمرّر ذلك التكامل خيارات النقل المعروفة إلى عميل HTTP الأساسي. وقاموس proxies على طريقة Requests ليس وسيطًا قابلًا للتبادل في الإنشاء. بالنسبة إلى نقاط نهاية الرموز وواجهات API العامة على مسار وكيل عام مسموح به، يوفّر قائمة وكلاء HTTP مرشّحين لعناوين URL الخاصة بوكيل HTTP في أي من المثالين.

حافظ على تسجيل OAuth الحالي للتطبيق وعلى redirect URI والنطاقات (scopes) ومعالجة الرموز عند تطبيق أي من الإعدادين. استخدم العميل المهيّأ لعمليات الرمز والموارد المحمية، وأغلقه عبر دورة حياته المتزامنة أو غير المتزامنة المعتادة.

قد تنشئ أدوات مساعدة في أطر العمل هؤلاء العملاء نيابة عن التطبيق. افحص تكامل الأداة وخيارات إنشاء العميل قبل تمرير وسائط وقت الطلب. فقبول الكلمة proxies في طلب رمز عبر Requests لا يعني أن طلبًا غير متزامن في HTTPX يقبلها.

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