Кои .NET податоци за најава му припаѓаат на проксито?
Разликувајте WebProxy.Credentials, податоци на целниот сервер и DefaultProxyCredentials при автентикација на HTTP-прокси.
За сопствен WebProxy поставете ја прокси-сметката на тој објект. Други .NET својства за податоци за најава служат на различни примачи:
| Својство | Примач |
|---|---|
WebProxy.Credentials | Проксито претставено со тој објект. |
HttpClientHandler.Credentials | Целниот сервер. |
DefaultProxyCredentials | Системското стандардно прокси кога Proxy е null, а UseProxy е true. |
Овој .NET 10 пример дава изрично прокси и негова сопствена сметка:
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);
Заменете ја документациската точка и користете сметка од операторот. Запис без автентикација не бара измислена најава. Бидејќи Proxy на обработувачот е изрично зададено, DefaultProxyCredentials не го заменува WebProxy.Credentials.
UseDefaultCredentials исто така има опсег според објектот: серверската автентикација на обработувачот и прокси-автентикацијата на WebProxy се различни. Испраќање на сметката на корисникот на процесот не е општ одговор на 407.
Ако предизвикот за автентикација продолжува, проверете ги вистинската шема, избраната точка и инстанцата клиент/обработувач. Прокси-автентикацијата може да биде пред TLS на целта, па Authorization заглавјето на страницата не може да одговори на неа. Поддршката сѐ уште зависи од обработувачот, платформата, услугата и политиката на примена; не е потребна глобална промена на Windows прокси.