HTTP 407 nebo 401: které přihlášení selhává?
Rozlište ověřování proxy a webu, prohlédněte správné hlavičky a neposílejte přihlašovací údaje nesprávnému účastníkovi.
407 požaduje ověření u proxy. 401 požaduje ověření pro cílový prostředek. Jeden požadavek může narazit na oba kódy, proto před zadáním hesla zjistěte, kdo ho žádá.
Porovnejte stav a hlavičky ověřovací výzvy
| Odpověď | Hlavička výzvy | Hlavička přihlašovacích údajů | Účastník |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | Zprostředkující proxy |
| 401 Unauthorized | WWW-Authenticate | Authorization | Ověřovací postup původního prostředku |
Stav je zásadní první vodítko, ale prohlédněte celou výměnu. Číslo 407 v textu stránky není skutečná odpověď HTTP 407. Stejně tak vlastní přihlašovací stránka může vrátit 200 a přesto požadovat ověření na aplikační úrovni.
Proč může HTTPS selhat kódem 407 ještě před dosažením webu
Při přenosu HTTPS přes běžnou HTTP proxy klient obvykle nejprve požádá o vytvoření tunelu CONNECT. Proxy může pro tento požadavek CONNECT vyžádat ověření. Není-li dokončeno, TLS relace s cílem přes tunel ještě nevznikla. Změna API tokenu webu proto tuto fázi pravděpodobně neopraví.
Pomocí podrobného výstupu zjistěte, kde se výzva objeví:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Nahraďte místní naslouchající rozhraní vlastním a přečtěte první výzvu v protokolu. 407 během CONNECT přichází před cílovým TLS; pozdější 401 může následovat po úspěšném vytvoření tunelu.
Předejte údaje proxy přes rozhraní pro proxy
Pro koncový bod a účet od důvěryhodného správce může curl dohodnout ověřovací schéma proxy a vyžádat si chybějící heslo:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Nahraďte ukázkový koncový bod a uživatele údaji služby, kterou smíte používat. Uvedení pouze uživatele zabrání vložení hesla přímo do výše uvedeného příkazu. Podporované metody se liší podle sestavení curl a proxy; při selhání dohody ověřte skutečnou výzvu a možnosti sestavení.
Volba ověřování proxy je oddělená od volby curl pro uživatele původního serveru. Nepřidávejte hlavičku Authorization pro původní server místo odpovědi na výzvu proxy. Ani ručně nepředávejte hlavičky s údaji proxy nesouvisejícím požadavkům a neukládejte je do hlaviček sdílených celou aplikací.
Když proxy stále vrací 407
- Ověřte, že používáte zamýšleného hostitele a port proxy.
- Zkontrolujte schémata nabízená proxy místo předpokladu, že jde o Basic.
- Ověřte stav účtu a požadovaný formát uživatelského jména.
- Zkontrolujte předávání zvláštních znaků, jsou-li údaje vložené do URL.
- Zjistěte, zda podnikové ověřování integrované do prohlížeče potřebuje podporu běhového prostředí nebo platformy.
- Nestačí-li údaje klienta, požádejte správce o identifikátor požadavku nebo serverový záznam zbavený citlivých údajů.
403 nebo odmítnuté CONNECT může vyplývat z pravidel přístupu i po úspěšném přihlášení. Další pokusy o heslo neumožní přístup k zakázanému cíli.
HTTPS cíle nechrání každou výměnu přihlašovacích údajů proxy
Ověření proxy může proběhnout před vytvořením cílového TLS. Pokud je spojení se samotnou proxy nešifrované a metoda na něm odhaluje opakovaně použitelné údaje, HTTPS cíl tuto výměnu zpětně neochrání. Zvolte pro službu vhodný přenos a ověřování; neposílejte soukromé účty neznámé veřejné proxy.
Podrobné protokoly před sdílením prohlédněte. I když nástroj maskuje běžná přihlašovací pole, mohou obsahovat uživatelská jména, interní názvy koncových bodů, cookies či další identifikační údaje.