HTTP 407 vai 401: kura pieteikšanās neizdodas?
Nošķiriet starpniekservera un vietnes autentifikāciju, pārbaudiet pareizās galvenes un nesūtiet pieteikšanās datus nepareizajai pusei.
407 pieprasa autentifikāciju starpniekserverī. 401 to pieprasa galamērķa resursam. Viens pieprasījums var sastapt abus, tāpēc pirms paroles došanas noskaidrojiet, kas to prasa.
Salīdziniet statusu un autentifikācijas izaicinājuma galvenes
| Atbilde | Izaicinājuma galvene | Pieteikšanās datu galvene | Iesaistītā puse |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | Starpniekserveris starp savienojuma pusēm |
| 401 Unauthorized | WWW-Authenticate | Authorization | Izcelsmes resursa autentifikācijas plūsma |
Statuss ir svarīga pirmā norāde, bet izpētiet visu apmaiņu. Skaitlis 407 lapas tekstā nav īsta HTTP 407 atbilde. Tāpat pielāgota pieteikšanās lapa var atgriezt 200 un joprojām prasīt autentifikāciju lietotnes līmenī.
Kāpēc HTTPS var beigties ar 407 vēl pirms vietnes sasniegšanas
Kad parasts HTTP starpniekserveris pārsūta HTTPS pieprasījumu, klients parasti vispirms prasa CONNECT tuneli. Starpniekserveris var prasīt autentifikāciju šim CONNECT pieprasījumam. Kamēr tā nav pabeigta, TLS sesija ar galamērķi caur tuneli vēl nav izveidota. Vietnes API pilnvaras maiņa šo posmu, visticamāk, neizlabos.
Izmantojiet detalizētu izvadi, lai redzētu izaicinājuma vietu:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Aizstājiet lokālo klausītāju ar savu un izlasiet pirmo izaicinājumu žurnālā. 407 CONNECT laikā ir pirms galamērķa TLS; vēlāks 401 var sekot pēc veiksmīgas tuneļa izveides.
Starpniekservera datus dodiet caur tam paredzēto saskarni
Uzticama administratora dotam galapunktam un kontam curl var vienoties par autentifikācijas shēmu un palūgt nenorādīto paroli:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Aizstājiet parauga galapunktu un lietotāju ar atļautā pakalpojuma datiem. Tikai lietotāja norādīšana novērš paroles ierakstīšanu tieši augšējā komandā. Metodes var atšķirties pēc curl būvējuma un starpniekservera; ja vienošanās neizdodas, pārbaudiet īsto izaicinājumu un būvējuma iespējas.
Starpniekservera autentifikācijas opcija ir atsevišķa no curl lietotāja autentifikācijas izcelsmes serverī. Nepievienojiet izcelsmei domātu Authorization galveni atbildes uz starpniekservera izaicinājumu vietā. Arī manuāli nepārsūtiet starpniekservera datu galvenes nesaistītiem pieprasījumiem un neglabājiet tās visā lietotnē atkārtoti izmantojamās galvenēs.
Ja starpniekserveris turpina atgriezt 407
- Pārliecinieties par paredzēto starpniekservera resursdatoru un portu.
- Pārbaudiet servera paziņotās shēmas, nevis pieņemiet Basic.
- Pārbaudiet konta statusu un pakalpojuma prasīto lietotājvārda formātu.
- Pārbaudiet īpašo rakstzīmju pārsūtīšanu, ja dati ir URL.
- Noskaidrojiet, vai pārlūkā integrētai uzņēmuma autentifikācijai vajag izpildvides vai platformas atbalstu.
- Ja klienta pierādījumu nepietiek, lūdziet administratoram pieprasījuma identifikatoru vai servera žurnāla ierakstu bez sensitīviem datiem.
403 vai noraidīts CONNECT var būt piekļuves politikas lēmums arī pēc veiksmīgas pieteikšanās. Vairāk paroles mēģinājumu nedos piekļuvi aizliegtam galamērķim.
Galamērķa HTTPS neaizsargā katru starpniekservera datu apmaiņu
Starpniekservera autentifikācija var notikt pirms galamērķa TLS. Ja savienojums ar pašu starpniekserveri ir nešifrēts un metode tajā atklāj atkārtoti izmantojamus datus, HTTPS galamērķis iepriekšējo apmaiņu neaizsargā ar atpakaļejošu spēku. Izvēlieties pakalpojumam piemērotu pārsūtīšanu un autentifikāciju; nesūtiet privātus kontus nezināmam publiskam starpniekserverim.
Pirms koplietošanas pārskatiet detalizētus žurnālus. Pat ja rīks slēpj parastos datu laukus, var palikt lietotāji, iekšējo galapunktu nosaukumi, sīkfaili vai citi identificējoši dati.