הגדרת פרוקסי של לקוח YouTube .NET עם HttpClientFactory.ForProxy

Google.Apis מספק מפעל ליצירת לקוחות HTTP עם IWebProxy. ספקו אותו בעת בניית השירות שנוצר:

var proxy = new System.Net.WebProxy("http://proxy.example:8080");
proxy.Credentials = new System.Net.NetworkCredential(
    proxyUser, proxyPassword);

using var youtube = new Google.Apis.YouTube.v3.YouTubeService(
    new Google.Apis.Services.BaseClientService.Initializer
    {
        ApplicationName = "ExampleVideoClient",
        ApiKey = apiKey,
        HttpClientFactory =
            Google.Apis.Http.HttpClientFactory.ForProxy(proxy)
    });

הדוגמה משתמשת בגישה עם מפתח API לפעולת נתונים ציבוריים נתמכת. השמיטו את הקצאת פרטי הפרוקסי עבור פרוקסי ללא אימות. בענף הנתונים הציבוריים הזה, בחרו רשומת HTTP מרשימת שרתי פרוקסי HTTP אם מתווכים ציבוריים מותרים. חשבון הפרוקסי ומפתח ה-API משרתים נקודות קצה שונות.

ב-Google.Apis 1.73.0, BaseClientService.Initializer.HttpClientFactory הוא וו היצירה הנתמך. ForProxy מגדיר את הפרוקסי שסופק בלקוחות שנוצרים על ידי המפעל הזה. בניית בקשות, סריאליזציה ושאר צינור ה-SDK נשארים אצל השירות.

הגדירו זאת לפני שליחת בקשות. החלפת MessageHandler.InnerHandler בלקוח בנוי אינה נחוצה במקרה זה ועלולה לזרוק בחירות מטפל אחרות.

אישור OAuth יכול להשיג או לרענן את האסימון שלו דרך סידור ה-HTTP שלו. הגדרת מפעל של שירות אינה קובעת כיצד אישור שנוצר בנפרד משיג אסימונים. בדקו את הנתיב הזה בנפרד אם אחזור האסימון הוא הפעולה שנכשלת דרך הפרוקסי. בעת שימוש ב-GoogleCredential, שמרו את העותק הנתב מ-CreateWithHttpClientFactory לעבודת האסימון הזו.