אילו פרטי גישה של .NET שייכים לפרוקסי?

הבדילו WebProxy.Credentials, פרטי גישה לשרת היעד ו־DefaultProxyCredentials בעת אימות פרוקסי HTTP.

עבור WebProxy מותאם, הגדירו את חשבון הפרוקסי באותו אובייקט. מאפייני פרטי גישה אחרים של .NET משרתים נמענים שונים:

מאפייןנמען
WebProxy.Credentialsהפרוקסי המיוצג בידי אותו אובייקט.
HttpClientHandler.Credentialsשרת היעד.
DefaultProxyCredentialsפרוקסי ברירת המחדל של המערכת כאשר Proxy הוא null ו־UseProxy הוא true.

דוגמת .NET 10 הזאת מספקת פרוקסי מפורש וחשבון משלו:

using System;
using System.Net;
using System.Net.Http;

string password = Environment.GetEnvironmentVariable("PROXY_PASSWORD")
    ?? throw new InvalidOperationException("Set PROXY_PASSWORD");

var proxy = new WebProxy("http://203.0.113.10:8080")
{
    Credentials = new NetworkCredential("proxy-user", password)
};

using var handler = new HttpClientHandler
{
    Proxy = proxy,
    UseProxy = true
};
using var client = new HttpClient(handler)
{
    Timeout = TimeSpan.FromSeconds(15)
};

using var response = await client.GetAsync("https://example.com/");
Console.WriteLine((int)response.StatusCode);

החליפו את נקודת הדוגמה והשתמשו בחשבון שסיפק המפעיל. רשומה ללא אימות אינה זקוקה לפרטי כניסה מומצאים. מכיוון ש־Proxy של המטפל הוקצה במפורש, DefaultProxyCredentials אינו תחליף ל־WebProxy.Credentials.

גם UseDefaultCredentials הוא בעל תחולה תלוית אובייקט: אימות שרת של מטפל ואימות פרוקסי של WebProxy הם דברים שונים. שליחת חשבון משתמש התהליך אינה תגובה כללית ל־407.

אם דרישת האימות נמשכת, בדקו את השיטה בפועל, נקודת הקצה שנבחרה ומופע הלקוח/מטפל. אימות פרוקסי עשוי להקדים את TLS היעד, ולכן כותרת Authorization של האתר אינה יכולה לענות עליו. התמיכה עדיין תלויה במטפל, בפלטפורמה, בשירות ובמדיניות הפריסה; אין צורך לשנות את פרוקסי Windows הכללי.

מאמרים קשורים