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

  1. Прачытайце ўвесь абмен аўтэнтыфікацыі. Адзін 407 з наступнай прынятай спробай можа быць нармальным. Пераканайцеся, што канчатковы вынік па-ранейшаму 407, перш чым лічыць уваход адхіленым.
  2. Параўнайце маршрут і межы ўліковых даных. Супастаўце фактычны хост/порт і іншыя палі, вызначаныя разгорнутым HttpClient 5 AuthScope. Няправільны порт можа пакінуць BasicCredentialsProvider без прыдатнага запісу.
  3. Праверце метад і ідэнтычнасць. Ці прапанаваў проксі падтрыманы метад? Ці выкарыстала спроба чаканае злучэнне? Ці патрабуе аператар уліковы запіс з даменам або іншы дакументаваны фармат?

Выкарыстоўвайце ўсталяваны API асноўнай версіі. Рэцэпт кэша аўтэнтыфікацыі HttpClient 4 не пераносіцца нязменна ў версію 5. Выкарыстоўвайце патрабаванні аператара да ўліковага запісу, а не перабірайце адвольныя варыянты імя карыстальніка.

Папярэдняя аўтэнтыфікацыя — яшчэ адзін свядомы выбар. Для сумяшчальнай схемы яна можа прыбраць адзін круг, але змяняе момант выхаду ўліковых даных і патрабуе падтрыманых меж. Яна не можа быць першым рашэннем для няправільнай канчатковай кропкі або непадтрыманага метаду.

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

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