HTTP 407 vagy 401: melyik bejelentkezés hibás?
Különböztesd meg a proxy és a webhely hitelesítését, nézd meg a megfelelő fejléceket, és ne küldd rossz helyre a belépési adatokat.
A 407 a proxynál kér hitelesítést. A 401 a cél erőforráshoz kér hitelesítést. Egy kérés mindkettővel találkozhat, ezért jelszó megadása előtt tisztázd, ki kéri.
Hasonlítsd össze az állapotot és a hitelesítési felszólítás fejléceit
| Válasz | Hitelesítési felszólítás fejléce | Belépési adatok fejléce | Érintett fél |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | Köztes proxy |
| 401 Unauthorized | WWW-Authenticate | Authorization | Az eredeti erőforrás hitelesítési folyamata |
Az állapot fontos első támpont, de nézd át a teljes üzenetváltást. Az oldal szövegében megjelenő 407 nem egyenértékű egy valódi HTTP 407 válasszal. Egy egyedi bejelentkezőoldal ugyanígy adhat 200-at, miközben az alkalmazásrétegben továbbra is hitelesítést követel.
Miért jöhet 407 még azelőtt, hogy a HTTPS-kérés elérné a webhelyet?
Ha egy szokásos HTTP-proxy HTTPS-kérést továbbít, a kliens általában először CONNECT-alagutat kér. A proxy magához a CONNECT-kéréshez is kérhet hitelesítést. Amíg ez nem teljesül, a cél TLS-munkamenete még nem jött létre az alagúton át. A webhely API-tokenjének cseréje ezért valószínűleg nem javítja ezt a szakaszt.
Részletes kimenettel figyeld meg, hol jelenik meg a felszólítás:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Cseréld a helyi figyelőt a sajátodra, és olvasd el a napló első hitelesítési felszólítását. A CONNECT közbeni 407 megelőzi a cél TLS-ét; egy későbbi 401 már a sikeresen létrejött alagút után jöhet.
A proxy adatait a proxy felületén add meg
Megbízható rendszergazdától kapott végpont és fiók esetén a curl egyeztetheti a proxy hitelesítési módját, és bekérheti a hiányzó jelszót:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/A példa végpontját és felhasználónevét cseréld a jogosan használt szolgáltatás adataira. Csak a felhasználónév megadása elkerüli a jelszót közvetlenül a fenti parancsban. A támogatott módszerek a curl összeállításától és a proxytól függnek; sikertelen egyeztetésnél ellenőrizd a tényleges felszólítást és az összeállítás képességeit.
A proxy hitelesítési kapcsolója különálló a curl eredeti kiszolgálóhoz tartozó felhasználóhitelesítésétől. Ne adj hozzá eredeti kiszolgálónak szóló Authorization fejlécet a proxy felszólítására adott válasz helyett. Ne továbbítsd kézzel a proxy belépési fejléceit idegen kérésekhez, és ne tárold az egész alkalmazásban újrahasznált fejlécek között.
Ha a proxy továbbra is 407-et ad
- Ellenőrizd a kívánt proxy gazdagépét és portját.
- Basic feltételezése helyett nézd meg a proxy által hirdetett módszereket.
- Ellenőrizd a fiók állapotát és az előírt felhasználónév-formátumot.
- Vizsgáld meg a különleges karakterek átadását, ha az adatok URL-be vannak ágyazva.
- Tisztázd, igényel-e a böngészőbe integrált vállalati hitelesítés futtatókörnyezet- vagy platformtámogatást.
- Ha a kliens adatai nem elegendők, kérj a rendszergazdától érzékeny adatoktól megtisztított kérésazonosítót vagy kiszolgálónapló-bejegyzést.
A 403 vagy az elutasított CONNECT sikeres bejelentkezés után is lehet hozzáférési szabály döntése. Újabb jelszópróbák nem adnak hozzáférést tiltott célhoz.
A cél HTTPS-e nem véd meg minden proxyhitelesítési adatcserét
A proxy hitelesítése a cél TLS-ének létrejötte előtt is történhet. Ha magához a proxyhoz titkosítatlan a kapcsolat, és a módszer azon újrahasználható adatokat fed fel, a HTTPS-cél utólag nem védi meg ezt az adatcserét. Válassz a szolgáltatásnak megfelelő átvitelt és hitelesítést, és ne küldj magánfiókokat ismeretlen nyilvános proxynak.
Megosztás előtt nézd át a részletes naplókat. A szokásos belépési mezők maszkolása mellett is maradhatnak bennük felhasználónevek, belső végpontnevek, sütik és más azonosító adatok.