URI можа змяшчаць username:password перад імем хоста. Гэта не азначае, што кожны .NET API, які прымае такі URI, капіруе звесткі карыстальніка ў аб'ект аўтэнтыфікацыі.

Ствараючы WebProxy напрамую, зрабіце прызначэнне ўліковых даных яўным:

var proxy = new WebProxy("http://203.0.113.10:8080")
{
    Credentials = new NetworkCredential(proxyUser, proxyPassword)
};

Зменныя endpoint і ўліковага запісу — ілюстратыўныя. Гэта трымае адрас прызначэння, адрас проксі і ўліковы запіс проксі асобна.

Калі фармат уводу падае URL з уліковымі данымі, разбірайце звесткі карыстальніка свядома. Захоўвайце пароль з двукроп'ямі, раздзяляючы толькі па раздзяляльніку ўліковых даных, і дэкадзіруйце закадаваныя кампаненты на адпаведным этапе. Пазбягайце друку зыходнага URL падчас дыягностыкі гэтага парсера.

URL проксі, які працуе як налада асяроддзя, можа паводзіць сябе інакш пры перадачы ў іншы канструктар. Ініцыялізацыя проксі асяроддзя мае ўласную логіку разбору; гэта не абяцанне, што кожны канструктар спажывае тыя ж поля.

Нарэшце, усталюйце настроены аб'ект проксі на апрацоўшчык, які выконвае запыт. Правільныя ўліковыя даныя на нявыкарыстаным WebProxy не могуць паўплываць на злучэнне.

Падобныя артыкулы