Millised .NET-i pääsuandmed kuuluvad puhverserverile?

Erista HTTP-puhverserveri autentimisel WebProxy.Credentials, sihtserveri pääsuandmeid ja DefaultProxyCredentials.

Oma WebProxy puhul määra puhverserveri konto sellele objektile. Teistel .NET-i pääsuandmete omadustel on erinevad saajad:

OmadusSaaja
WebProxy.CredentialsSelle objekti esindatud puhverserver.
HttpClientHandler.CredentialsSihtserver.
DefaultProxyCredentialsSüsteemi vaikimisi puhverserver, kui Proxy on null ja UseProxy on true.

See .NET 10 näide annab otseselt määratud puhverserveri ja selle enda 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);

Asenda dokumentatsiooni lõpp-punkt ja kasuta haldaja antud kontot. Autentimiseta loendikirje ei vaja väljamõeldud sisselogimist. Kuna käitleja Proxy on otseselt määratud, ei asenda DefaultProxyCredentials omadust WebProxy.Credentials.

UseDefaultCredentials ulatus sõltub samuti objektist: käitleja serveri autentimine ja WebProxy puhverserveri autentimine on eri asjad. Protsessi kasutaja konto saatmine pole üldine vastus koodile 407.

Kui autentimisnõue püsib, kontrolli tegelikku skeemi, valitud lõpp-punkti ja kliendi/käitleja eksemplari. Puhverserveri autentimine võib eelneda sihtkoha TLS-ile, nii et veebisaidi Authorization-päis ei saa sellele vastata. Toetatud autentimine sõltub endiselt käitlejast, platvormist, teenusest ja juurutuspoliitikast; üleüldist Windowsi puhverserverimuudatust pole vaja.

Seotud artiklid