HTTP 407 või 401: milline sisselogimine nurjub?
Erista puhverserveri ja veebisaidi autentimist, vaata õigeid päiseid ning ära saada sisselogimisandmeid valele poolele.
407 küsib autentimist puhverserveris. 401 küsib autentimist sihtressursi jaoks. Üks päring võib kohata mõlemat, seega selgita enne parooli andmist, kes seda küsib.
Võrdle olekut ja autentimisväljakutse päiseid
| Vastus | Väljakutse päis | Sisselogimisandmete päis | Osapool |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | Vahepealne puhverserver |
| 401 Unauthorized | WWW-Authenticate | Authorization | Algse ressursi autentimisvoog |
Olek on tähtis esimene vihje, kuid vaata kogu sõnumivahetust. Lehe tekstis olev 407 ei võrdu tegeliku HTTP 407 vastusega. Samuti võib kohandatud sisselogimisleht anda 200 ja nõuda endiselt autentimist rakenduskihis.
Miks HTTPS võib nurjuda koodiga 407 juba enne veebisaiti
Kui tavaline HTTP-puhverserver kannab HTTPS-päringut, palub klient üldjuhul kõigepealt luua CONNECT-tunneli. Puhverserver võib selle CONNECT-päringu jaoks autentimist nõuda. Kui see pole lõpetatud, ei ole sihtkoha TLS-seanssi tunneli kaudu veel loodud. Veebisaidi API-tokeni muutmine seda etappi tõenäoliselt ei paranda.
Kasuta üksikasjalikku väljundit, et näha väljakutse asukohta:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Asenda kohalik kuulaja enda omaga ja loe logi esimest väljakutset. 407 CONNECT-i ajal tuleb enne sihtkoha TLS-i; hilisem 401 võib tulla pärast tunneli edukat loomist.
Anna puhverserveri andmed selleks mõeldud liidese kaudu
Usaldusväärselt haldurilt saadud lõpp-punkti ja konto korral saab curl autentimisskeemi kokku leppida ning puuduva parooli küsida:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Asenda näite lõpp-punkt ja kasutaja teenuse andmetega, mille kasutamiseks sul on luba. Ainult kasutaja määramine väldib parooli otse ülaltoodud käsus. Meetodite tugi sõltub curl-i järgust ja puhverserverist; kui läbirääkimine nurjub, kontrolli tegelikku väljakutset ja järgu võimalusi.
Puhverserveri autentimise valik on curl-i algserveri kasutaja autentimisest eraldi. Ära lisa algserveri Authorization-päist puhverserveri väljakutsele vastamise asemel. Samuti ära edasta puhverserveri andmepäiseid käsitsi mitteseotud päringutele ega salvesta neid kogu rakenduses taaskasutatavatesse päistesse.
Kui puhverserver tagastab pidevalt 407
- Kinnita, et kasutad soovitud puhverserveri hosti ja porti.
- Vaata puhverserveri pakutavaid skeeme, selle asemel et eeldada Basicut.
- Kinnita konto olek ja teenuse nõutav kasutajanime vorming.
- Kontrolli erimärkide edastamist, kui andmed on URL-is.
- Selgita, kas brauseriga integreeritud ettevõtte autentimine vajab käituskeskkonna või platvormi tuge.
- Kui kliendi tõenditest ei piisa, küsi haldurilt tundlikest andmetest puhastatud päringuidentifikaatorit või serverilogi kirjet.
403 või keelatud CONNECT võib olla juurdepääsureeglite otsus ka pärast edukat sisselogimist. Rohkem paroolikatseid ei anna ligipääsu keelatud sihtkohale.
Sihtkoha HTTPS ei kaitse iga puhverserveri andmevahetust
Puhverserveri autentimine võib toimuda enne sihtkoha TLS-i loomist. Kui ühendus puhverserveri endaga on krüptimata ja meetod paljastab seal taaskasutatavaid andmeid, ei kaitse HTTPS-sihtkoht varasemat vahetust tagantjärele. Vali teenusele sobiv transport ja autentimine; ära saada isiklikke kontosid tundmatusse avalikku puhverserverisse.
Kontrolli üksikasjalikke logisid enne jagamist. Isegi kui tööriist varjab tavapäraseid sisselogimisvälju, võivad alles jääda kasutajanimed, sisemised lõpp-punktinimed, küpsised või muud tuvastavad andmed.