Vir ’n pasgemaakte WebProxy, plaas die proxyrekening op daardie objek. Verskeie ander .NET-geloofsbrief-eienskappe het ander ontvangers:

EienskapOntvanger
WebProxy.CredentialsDie proxy wat deur daardie objek voorgestel word.
HttpClientHandler.CredentialsDie bestemmingsbediener.
DefaultProxyCredentialsDie stelsel se verstekproxy wanneer Proxy null is en UseProxy true is.

Hierdie .NET 10-voorbeeld verskaf ’n uitdruklik ingestelde proxy en sy eie rekening:

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

Vervang die dokumentasie-eindpunt en gebruik ’n rekening wat die operateur verskaf. ’n Lysinskrywing sonder verifikasie benodig nie uitgedinkte aanmeldbesonderhede nie. Omdat die hanteerder se Proxy uitdruklik toegeken is, vervang DefaultProxyCredentials nie WebProxy.Credentials nie.

UseDefaultCredentials het ook ’n objekspesifieke omvang: ’n hanteerder se bedienerverifikasie en ’n WebProxy se proxyverifikasie verskil. Om die prosesgebruiker se rekening te stuur is nie ’n algemene antwoord op 407 nie.

As die verifikasie-uitdaging voortduur, ondersoek die werklike skema, gekose eindpunt en kliënt/hanteerder-instansie. Proxyverifikasie kan vóór bestemmings-TLS gebeur; daarom kan ’n webwerf se Authorization-kop dit nie beantwoord nie. Ondersteunde verifikasie hang steeds van die hanteerder, platform, diens en ontplooiingsbeleid af; dié opstelling vereis geen globale Windows-proxyverandering nie.

Verwante artikels