HTTP 407 vai 401: kumpi kirjautuminen epäonnistuu?
Erota välityspalvelimen ja sivuston todennus, tarkista oikeat otsakkeet ja vältä tunnusten lähettämistä väärälle osapuolelle.
407 pyytää todentautumaan välityspalvelimelle. 401 pyytää todennusta kohderesurssiin. Sama pyyntö voi kohdata molemmat, joten selvitä pyytäjä ennen salasanan antamista.
Vertaa tilakoodia ja todennushaasteen otsakkeita
| Vastaus | Todennushaasteen otsake | Tunnusten otsake | Osapuoli |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | Välittävä välityspalvelin |
| 401 Unauthorized | WWW-Authenticate | Authorization | Alkuperäresurssin todennuskulku |
Tilakoodi on tärkeä ensimmäinen vihje, mutta tutki koko viestinvaihto. Sivun tekstissä näkyvä 407 ei vastaa oikeaa HTTP 407 -vastausta. Samoin mukautettu kirjautumissivu voi palauttaa 200:n ja silti vaatia todennusta sovelluskerroksessa.
Miksi HTTPS voi epäonnistua koodiin 407 ennen sivustoa
Kun tavallinen HTTP-välityspalvelin välittää HTTPS-pyynnön, asiakas pyytää yleensä ensin CONNECT-tunnelin muodostamista. Välityspalvelin voi vaatia todennusta tälle CONNECT-pyynnölle. Ellei todennus valmistu, kohteen TLS-istuntoa ei ole vielä muodostettu tunnelin läpi. Sivuston API-tunnisteen vaihtaminen ei siksi todennäköisesti korjaa tätä vaihetta.
Käytä yksityiskohtaista tulostusta nähdäksesi, missä haaste tulee:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Korvaa paikallinen kuuntelija omallasi ja lue lokin ensimmäinen todennushaaste. CONNECT-vaiheen 407 tulee ennen kohteen TLS:ää; onnistuneen tunnelin jälkeen voi tulla 401.
Anna välityspalvelimen tunnukset sille tarkoitetun rajapinnan kautta
Kun päätepiste ja tili tulevat luotettavalta ylläpitäjältä, curl voi neuvotella välityspalvelimen todennustavan ja kysyä puuttuvan salasanan:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Korvaa esimerkin päätepiste ja käyttäjänimi sen palvelun tiedoilla, jota saat käyttää. Pelkkä käyttäjänimi välttää salasanan kirjoittamisen suoraan yllä olevaan komentoon. Tuetut menetelmät voivat vaihdella curl-koosteen ja välityspalvelimen mukaan; tarkista todellinen haaste ja koosteen ominaisuudet neuvottelun epäonnistuessa.
Välityspalvelimen todennusvalitsin on erillinen curlin alkuperäpalvelimen käyttäjätodennuksesta. Älä lisää alkuperälle tarkoitettua Authorization-otsaketta vastaukseksi välityspalvelimen haasteeseen. Älä myöskään välitä välityspalvelimen tunnusotsakkeita käsin muihin pyyntöihin tai tallenna niitä koko sovelluksen yhteisiin otsakkeisiin.
Jos välityspalvelin palauttaa jatkuvasti 407:n
- Varmista, että käytössä ovat oikea välityspalvelimen nimi ja portti.
- Tarkista palvelimen ilmoittamat todennustavat sen sijaan, että olettaisit Basicin.
- Varmista tilin tila ja mahdollinen käyttäjänimen erityinen muotovaatimus.
- Tarkista erikoismerkkien välitys, jos tunnukset on upotettu URL-osoitteeseen.
- Selvitä, vaatiiko selaimeen integroitu yritystodennus suoritusympäristön tai alustan tukea.
- Pyydä ylläpitäjältä arkaluonteisista tiedoista puhdistettu pyynnön tunniste tai palvelinlokin rivi, jos asiakkaan tiedot eivät riitä.
403 tai hylätty CONNECT voi johtua käyttöoikeuskäytännöstä myös onnistuneen kirjautumisen jälkeen. Uudet salasanayritykset eivät anna pääsyä kiellettyyn kohteeseen.
Kohteen HTTPS ei suojaa kaikkia välityspalvelimen tunnusvaihtoja
Välityspalvelimen todennus voi tapahtua ennen kohteen TLS:n muodostamista. Jos yhteys itse välityspalvelimeen on salaamaton ja menetelmä paljastaa sillä uudelleenkäytettäviä tunnuksia, HTTPS-kohde ei suojaa aiempaa viestinvaihtoa jälkikäteen. Valitse palvelulle sopiva siirtotapa ja todennus, äläkä lähetä yksityisiä tilejä tuntemattomalle julkiselle välityspalvelimelle.
Tarkista yksityiskohtaiset lokit ennen jakamista. Vaikka työkalu peittäisi tavalliset tunnuskentät, lokissa voi olla käyttäjänimiä, sisäisiä päätepisteiden nimiä, evästeitä tai muita tunnistavia tietoja.