Kiuj .NET-akreditaĵoj apartenas al la prokurilo?

Por propra WebProxy metu la prokurilan konton sur tiun objekton. Pluraj aliaj .NET-akreditaĵaj ecoj servas malsamajn ricevantojn:

Ĉi tiu .NET 10-ekzemplo provizas eksplicitan prokurilon kaj ĝian propran konton:

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);

Anstataŭigu la dokumentan finpunkton kaj uzu konton provizitan de la administranto. Neaŭtentikigita listero ne bezonas elpensitan ensaluton. Ĉar Proxy de la traktilo estas eksplicite asignita, DefaultProxyCredentials ne anstataŭas WebProxy.Credentials.

UseDefaultCredentials ankaŭ havas objektspecifan amplekson: servila aŭtentikigo de traktilo kaj prokurila aŭtentikigo de WebProxy estas malsamaj. Sendi la konton de la procezuzanto ne estas ĝenerala respondo al 407.

Se la aŭtentikiga defio daŭras, kontrolu la efektivan skemon, elektitan finpunkton kaj klientan/traktilan instancon. Prokurila aŭtentikigo povas antaŭi celan TLS, do reteja Authorization-kapo ne povas respondi ĝin. Subtenata aŭtentikigo plu dependas de traktilo, platformo, servo kaj deploja politiko; la agordo ne postulas tutmondan ŝanĝon de la Windows-prokurilo.