تنظیمات پروکسی Authlib: Requests در برابر HTTPX
بسته به یکپارچهسازی Authlib که استفاده میکنید، پروکسیهای نشست Requests یا آرگومان پروکسی کلاینت HTTPX را انتخاب کنید.
پیش از انتخاب آرگومان پروکسی، import مربوط به 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 یک آرگومان سازندهٔ قابلتبدیل نیست. برای نقاط پایانی عمومی token و API روی مسیر پروکسی عمومی مجاز، فهرست پروکسی HTTP نامزدهایی برای URLهای پروکسی HTTP هر دو نمونه فراهم میکند.
هنگام اعمال هر یک از دو پیکربندی، ثبت OAuth موجود برنامه، redirect URI، scopes و مدیریت token را حفظ کنید. از کلاینت پیکربندیشده برای عملیات token و منابع محافظتشده استفاده کنید و آن را از طریق چرخهٔ عمر همگام یا ناهمگام معمولش ببندید.
کمککنندههای چارچوب ممکن است این کلاینتها را به نمایندگی از برنامه بسازند. پیش از فرستادن آرگومانهای زمان درخواست، یکپارچهسازی کمککننده و گزینههای ساخت کلاینت را بررسی کنید. پذیرش واژهٔ کلیدی proxies در یک درخواست token با Requests ثابت نمیکند که یک درخواست ناهمگام HTTPX هم آن را میپذیرد.