הגדרות פרוקסי ב-Authlib: Requests מול HTTPX

בדקו את הייבוא של 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 אסינכרונית מקבלת אותה.