Ո՞ր .NET մուտքի տվյալներն են պատկանում պրոքսիին

HTTP պրոքսիի նույնականացման ժամանակ տարբերակեք WebProxy.Credentials-ը, նպատակակետի սերվերի տվյալները և DefaultProxyCredentials-ը։

Հատուկ 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-ի պրոքսին գլոբալ փոխելու կարիք չկա։

Առնչվող հոդվածներ