Hvilke .NET-innloggingsopplysninger tilhører proxyen?

Skill WebProxy.Credentials, målserverens innlogging og DefaultProxyCredentials ved autentisering mot en HTTP-proxy.

For en egen WebProxy skal proxykontoen settes på det objektet. Flere andre .NET-egenskaper for innloggingsopplysninger har andre mottakere:

EgenskapMottaker
WebProxy.CredentialsProxyen som objektet representerer.
HttpClientHandler.CredentialsMålserveren.
DefaultProxyCredentialsSystemets standardproxy når Proxy er null og UseProxy er true.

Dette .NET 10-eksemplet angir en eksplisitt proxy og dens egen 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);

Erstatt dokumentasjonsendepunktet og bruk en konto fra operatøren. En listeoppføring uten autentisering trenger ingen oppdiktet innlogging. Siden handlerens Proxy er eksplisitt satt, erstatter DefaultProxyCredentials ikke WebProxy.Credentials.

UseDefaultCredentials har også et objektspesifikt omfang: en handlers serverautentisering og en WebProxys proxyautentisering er forskjellige. Å sende prosessbrukerens konto er ikke et generelt svar på 407.

Hvis autentiseringsutfordringen fortsetter, kontroller den faktiske mekanismen, det valgte endepunktet og klient-/handlerinstansen. Proxyautentisering kan skje før målets TLS, så nettstedets Authorization-header kan ikke besvare den. Støtten avhenger fortsatt av handler, plattform, tjeneste og distribusjonspolicy; ingen global Windows-proxyendring kreves.

Relaterte artikler