HTTP 407 или 401: која пријава не успева?
Разликујте аутентификацију проксија и веб-сајта, проверите права заглавља и не шаљите податке за пријаву погрешној страни.
407 тражи аутентификацију на проксију. 401 је тражи за циљни ресурс. Један захтев може наићи на оба одговора, па пре давања лозинке утврдите ко је тражи.
Упоредите статус и заглавља аутентификационог изазова
| Одговор | Заглавље изазова | Заглавље података за пријаву | Укључена страна |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | Посреднички прокси |
| 401 Unauthorized | WWW-Authenticate | Authorization | Ток аутентификације изворног ресурса |
Статус је важан први траг, али проверите целу размену. Број 407 у тексту странице није стварни HTTP 407 одговор. Исто тако, прилагођена пријавна страница може да врати 200 и још тражи аутентификацију на нивоу апликације.
Зашто HTTPS може да откаже са 407 пре доласка до сајта
Када обичан HTTP прокси преноси HTTPS захтев, клијент обично прво тражи CONNECT тунел. Прокси може да тражи аутентификацију тог CONNECT захтева. Ако није завршена, TLS сесија са одредиштем кроз тунел још није успостављена. Промена API токена сајта зато вероватно неће поправити ту фазу.
Детаљним излазом захтева погледајте где се појављује изазов:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Замените локални интерфејс за ослушкивање својим и прочитајте први изазов у дневнику. 407 током CONNECT-а долази пре TLS-а одредишта; каснији 401 може да уследи након успешне успоставе тунела.
Податке проксија предајте кроз интерфејс за прокси
За крајњу тачку и налог поузданог администратора curl може да договори шему аутентификације проксија и затражи недостајућу лозинку:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Замените пример крајње тачке и корисника подацима услуге коју смете да користите. Навођење само корисника избегава лозинку непосредно у горњој команди. Методе зависе од curl издања и проксија; ако договарање не успе, проверите стварни изазов и могућности издања.
Опција аутентификације проксија одвојена је од curl-ове аутентификације корисника изворног сервера. Не додајте заглавље Authorization за извор уместо одговора на изазов проксија. Не прослеђујте ни ручно заглавља са подацима проксија неповезаним захтевима и не чувајте их у заглављима која користи цела апликација.
Ако прокси стално враћа 407
- Потврдите да користите предвиђени хост и порт проксија.
- Проверите шеме које прокси објављује уместо да претпоставите Basic.
- Потврдите стање налога и посебан формат корисничког имена који услуга можда тражи.
- Проверите пренос посебних знакова ако су подаци у URL-у.
- Утврдите треба ли пословној аутентификацији интегрисаној са прегледачем подршка извршног окружења или платформе.
- Ако докази клијента нису довољни, тражите од администратора идентификатор захтева или серверски запис очишћен од осетљивих података.
403 или одбијени CONNECT може бити одлука правила приступа и после успешне пријаве. Додатни покушаји лозинке неће отворити забрањено одредиште.
HTTPS одредишта не штити сваку размену података проксија
Аутентификација проксија може се десити пре TLS-а одредишта. Ако је веза са самим проксијем нешифрована, а метода на њој открива поново употребљиве податке, HTTPS одредиште не штити ту размену накнадно. Одаберите услузи прикладне пренос и аутентификацију; не шаљите приватне налоге непознатом јавном проксију.
Пре дељења прегледајте детаљне дневнике. И кад алат прикрива уобичајена поља за пријаву, могу остати корисници, називи интерних крајњих тачака, колачићи или други идентификациони подаци.