Vilka .NET-inloggningsuppgifter hör till proxyn?

Skilj WebProxy.Credentials, destinationsserverns inloggning och DefaultProxyCredentials vid autentisering mot en HTTP-proxy.

För en egen WebProxy ska proxykontot sättas på det objektet. Flera andra .NET-egenskaper för inloggningsuppgifter har andra mottagare:

EgenskapMottagare
WebProxy.CredentialsProxyn som objektet representerar.
HttpClientHandler.CredentialsDestinationsservern.
DefaultProxyCredentialsSystemets standardproxy när Proxy är null och UseProxy är true.

Detta .NET 10-exempel anger en uttrycklig proxy och dess eget konto:

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

Ersätt dokumentationsändpunkten och använd ett konto från operatören. En listpost utan autentisering behöver ingen påhittad inloggning. Eftersom hanterarens Proxy är uttryckligen satt ersätter DefaultProxyCredentials inte WebProxy.Credentials.

UseDefaultCredentials har också ett objektspecifikt omfång: en hanterares serverautentisering och en WebProxys proxyautentisering är olika. Att skicka processanvändarens konto är inget generellt svar på 407.

Om autentiseringsutmaningen fortsätter, kontrollera den faktiska mekanismen, den valda ändpunkten och klient-/hanterarinstansen. Proxyautentisering kan ske före destinationens TLS, så webbplatsens Authorization-header kan inte besvara den. Stödet beror fortfarande på hanterare, plattform, tjänst och distributionspolicy; ingen global Windows-proxyändring krävs.

Relaterade artiklar