Aseta oman WebProxy-objektin välityspalvelintili tähän objektiin. Useat muut .NET-tunnusominaisuudet palvelevat eri vastaanottajia:

OminaisuusVastaanottaja
WebProxy.CredentialsObjektin edustama välityspalvelin.
HttpClientHandler.CredentialsKohdepalvelin.
DefaultProxyCredentialsJärjestelmän oletusvälityspalvelin, kun Proxy on null ja UseProxy on true.

Tämä .NET 10 -esimerkki määrittää nimenomaisen välityspalvelimen ja sen oman tilin:

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

Korvaa dokumentaation päätepiste ja käytä ylläpitäjän antamaa tiliä. Tunnistautumaton listamerkintä ei tarvitse keksittyä kirjautumista. Koska käsittelijän Proxy on nimenomaisesti asetettu, DefaultProxyCredentials ei korvaa ominaisuutta WebProxy.Credentials.

Myös UseDefaultCredentials on objektikohtainen: käsittelijän palvelintunnistautuminen ja WebProxy-objektin välityspalvelintunnistautuminen ovat eri asioita. Prosessin käyttäjän tilin lähettäminen ei ole yleinen vastaus koodiin 407.

Jos tunnistautumishaaste jatkuu, tarkista todellinen menetelmä, valittu päätepiste ja asiakas-/käsittelijäolio. Välityspalvelintunnistautuminen voi edeltää kohteen TLS:ää, joten sivuston Authorization-otsake ei voi vastata siihen. Tuetut tunnistautumistavat riippuvat yhä käsittelijästä, alustasta, palvelusta ja käyttöönottokäytännöstä; järjestelmän Windows-välityspalvelinta ei tarvitse muuttaa.

Aiheeseen liittyvät artikkelit