Hokker .NET-ynloggegevens hearre by de proxy?

Set foar in eigen WebProxy it proxyakkount op dat objekt. Oare .NET-eigenskippen foar ynloggegevens hawwe oare ûntfangers:

Dit .NET 10-foarbyld jout in eksplisite proxy en it eigen akkount dêrfan op:

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

Ferfang it dokumintaasje-einpunt en brûk in akkount fan de behearder. In fermelding sûnder autentikaasje hat gjin betochte login nedich. Om’t Proxy fan de handler eksplisyt tawiisd is, ferfangt DefaultProxyCredentials de eigenskip WebProxy.Credentials net.

UseDefaultCredentials hat ek in objektspesifyk berik: serverautentikaasje fan in handler en proxyautentikaasje fan in WebProxy ferskille. It akkount fan de prosesbrûker ferstjoere is gjin algemien antwurd op 407.

Bliuwt de autentikaasje-útdaging bestean, kontrolearje dan it echte skema, keazen einpunt en kliïnt/handler-eksimplaar. Proxyautentikaasje kin foar bestimmings-TLS plakfine, dus in Authorization-kop fan de webside kin dêr net op antwurdzje. Stipe autentikaasje hinget noch fan handler, platfoarm, tsjinst en ynsetbelied ôf; in globale Windows-proxywiziging is net nedich.