HTTP 407 ali 401: katera prijava ne uspe?
Ločite avtentikacijo proxyja od avtentikacije spletnega mesta, preverite prave glave in ne pošiljajte poverilnic napačnemu udeležencu.
407 zahteva avtentikacijo pri proxyju. 401 jo zahteva za ciljni vir. Ena zahteva lahko naleti na oba odgovora, zato pred vnosom gesla ugotovite, kdo ga zahteva.
Primerjajte stanje in glave avtentikacijskega izziva
| Odgovor | Glava izziva | Glava poverilnic | Udeleženec |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | Vmesni proxy |
| 401 Unauthorized | WWW-Authenticate | Authorization | Avtentikacijski tok izvornega vira |
Stanje je pomemben prvi namig, vendar preglejte celotno izmenjavo. Številka 407 v besedilu strani ni enaka dejanskemu odgovoru HTTP 407. Tudi lastna prijavna stran lahko vrne 200 in še vedno zahteva avtentikacijo na ravni aplikacije.
Zakaj lahko HTTPS odpove s 407, še preden doseže spletno mesto
Pri prenosu HTTPS skozi običajen proxy HTTP odjemalec navadno najprej zahteva predor CONNECT. Proxy lahko zahteva avtentikacijo te zahteve CONNECT. Če ni končana, seja TLS s ciljem skozi predor še ni vzpostavljena. Menjava žetona API spletnega mesta zato tega koraka verjetno ne bo popravila.
S podrobnim izpisom preverite, kje se pojavi izziv:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Lokalni poslušalnik zamenjajte s svojim in preberite prvi izziv v dnevniku. 407 med CONNECT je pred TLS cilja; poznejši 401 lahko sledi uspešno vzpostavljenemu predoru.
Poverilnice proxyja podajte prek vmesnika za proxy
Za končno točko in račun zaupanja vrednega skrbnika se curl lahko dogovori za avtentikacijsko shemo proxyja in vpraša za manjkajoče geslo:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Vzorčno končno točko in uporabniško ime zamenjajte s podatki storitve, ki jo smete uporabljati. Samo uporabniško ime prepreči geslo neposredno v zgornjem ukazu. Podprte metode se razlikujejo glede na gradnjo curl in proxy; ob neuspehu pogajanja preverite dejanski izziv in zmožnosti gradnje.
Možnost avtentikacije proxyja je ločena od uporabniške avtentikacije pri izvornem strežniku v curl. Glave Authorization za izvor ne dodajajte kot nadomestilo za odgovor na izziv proxyja. Prav tako glav s poverilnicami proxyja ne posredujte ročno nepovezanim zahtevam in jih ne shranjujte med glave za ponovno uporabo v vsej aplikaciji.
Če proxy še naprej vrača 407
- Potrdite, da uporabljate predvidena gostitelja in vrata proxyja.
- Preverite sheme, ki jih oglašuje proxy, namesto da predpostavite Basic.
- Preverite stanje računa in zahtevano obliko uporabniškega imena.
- Preverite prenos posebnih znakov, če so poverilnice v URL-ju.
- Ugotovite, ali podjetniška avtentikacija, integrirana v brskalnik, potrebuje podporo izvajalnega okolja ali platforme.
- Če dokazi pri odjemalcu ne zadoščajo, skrbnika prosite za identifikator zahteve ali strežniški dnevniški zapis z odstranjenimi občutljivimi podatki.
403 ali zavrnjen CONNECT je lahko odločitev pravil dostopa tudi po uspešni prijavi. Dodatni poskusi gesel ne omogočijo dostopa do prepovedanega cilja.
HTTPS cilja ne varuje vsake izmenjave poverilnic proxyja
Avtentikacija proxyja se lahko zgodi pred vzpostavitvijo TLS cilja. Če je povezava s samim proxyjem nešifrirana in metoda na njej razkrije ponovno uporabne poverilnice, cilj HTTPS te izmenjave ne zaščiti za nazaj. Izberite storitvi primerna prenos in avtentikacijo ter zasebnih računov ne pošiljajte neznanemu javnemu proxyju.
Pred deljenjem preglejte podrobne dnevnike. Tudi če orodje zakrije običajna polja s poverilnicami, lahko ostanejo uporabniška imena, imena notranjih končnih točk, piškotki ali drugi prepoznavni podatki.