HTTP 407 bez izmantojama Proxy-Authenticate izaicinājuma

Klients nevar izvēlēties autentifikācijas mehānismu tikai pēc statusa numura. Starpniekservera atbildē ir jāapraksta, ko tas pieņem.

HTTP prasa, lai starpniekserveris, kas ģenerē 407, nosūtītu Proxy-Authenticate izaicinājumu. Basic pakalpojuma vienkāršs piemērs ir:

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="Office proxy"

Skaitliskais statuss, galvenes nosaukums un shēmai raksturīgā sintakse ir vienlīdz svarīgi. Zīmola kļūdas lapa ar vārdu authentication tās pamattekstā neaizstāj galveni. Pielāgotām implementācijām arī jānosūta pilnīga HTTP 407 atbilde, iekļaujot galvenes noslēdzēju un pamatteksta ietvaru.

Pārbaudiet atbildi, kas sasniedza šo klientu

Reģistrējiet statusa un izaicinājuma laukus pēc slepeno vērtību noņemšanas. Starpnieks varēja pārveidot atbildi, vai pielāgots starpniekserveris varēja izveidot nederīgu izaicinājumu. Salīdziniet šos pierādījumus ar paša starpniekservera darījumu žurnālu.

Ja pakalpojums tā vietā sūta 405 vai citu kļūdu, nepārdēvējiet katru šādu atbildi par 407 pielāgotā klientā. Jūs slēptu īstas metodes politikas neveiksmes un joprojām jums nebūtu uzticamas shēmas sarunu. Izlabojiet pakalpojuma uzvedību vai izmantojiet tā dokumentēto atbalstīto autentifikācijas ceļu.

Vairāki izaicinājumi arī prasa īstu HTTP analizatoru. Komats var atdalīt parametrus vai izaicinājumus; akli sadalot visu galveni pa komatiem, var sabojāt realm pēdiņās. Izmantojiet klienta atbalstīto autentifikācijas implementāciju, nevis virkni virkņu aizvietojumu.

Tikai pēc tam, kad izaicinājums ir izmantojams, ir jēga izmeklēt, kāpēc akreditācijas datu nodrošinātājs neatgrieza kontu.