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 мэты не абароніць мінулы абмен заднім чыслом. Выберыце прыдатныя сэрвісу транспарт і аўтэнтыфікацыю; не адпраўляйце прыватныя ўліковыя запісы невядомаму публічнаму проксі.
Перад распаўсюджваннем падрабязных журналаў праглядзіце іх. Нават калі інструмент хавае звычайныя палі ўваходу, могуць застацца карыстальнікі, назвы ўнутраных канцавых пунктаў, cookies ці іншыя ідэнтыфікацыйныя звесткі.