کدام اطلاعات ورود .NET مربوط به پروکسی است؟

در احراز هویت پروکسی HTTP، بین WebProxy.Credentials، اطلاعات ورود سرور مقصد و DefaultProxyCredentials تمایز بگذارید.

برای 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 نیست.

مقالات مرتبط