მორგებული 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-ის გლობალური პროქსის შეცვლა საჭირო არ არის.

დაკავშირებული სტატიები