Një klient nuk mund të zgjedhë një mekanizëm vërtetimi vetëm nga një numër statusi. Përgjigja e proxy-t duhet të përshkruajë çfarë pranon.

HTTP kërkon që një proxy që gjeneron 407 të dërgojë një sfidë Proxy-Authenticate. Për një shërbim Basic, një shembull i thjeshtë është:

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

Statusi numerik, emri i kokës dhe sintaksa specifike e skemës janë të gjitha të rëndësishme. Një faqe gabimi me markë që përmban fjalën authentication në trup nuk e zëvendëson kokën. Implementimet e personalizuara duhet të dërgojnë gjithashtu një përgjigje të plotë HTTP 407, duke përfshirë përfunduesin e kokës dhe kornizimin e trupit.

Inspektoni përgjigjen që arriti në këtë klient

Regjistroni fushat e statusit dhe të sfidës pasi të hiqni vlerat sekrete. Një ndërmjetës mund ta ketë transformuar përgjigjen, ose një proxy i personalizuar mund të ketë ndërtuar një sfidë të pavlefshme. Krahasoni ato prova me regjistrin e transaksioneve të vetë proxy-t.

Nëse shërbimi dërgon 405 ose një gabim tjetër në vend të kësaj, mos e rietiketoni çdo përgjigje të tillë si 407 brenda një klienti të personalizuar. Do të fshihnit dështime reale të politikës së metodave dhe prapë nuk do të kishit një negociim të besueshëm të skemës. Rregulloni sjelljen e shërbimit ose përdorni rrugën e vërtetimit të dokumentuar dhe të mbështetur.

Sfidat e shumta kërkojnë gjithashtu një analizues të vërtetë HTTP. Një presje mund të ndajë parametra ose sfida; ndarja e verbër e të gjithë kokës në presje mund të dëmtojë një realm brenda thonjëzave. Përdorni implementimin e vërtetimit të mbështetur nga klienti në vend të një radhe zëvendësimesh vargjesh.

Vetëm pasi sfida të jetë e përdorshme ka kuptim të hetohet pse ofruesi i kredencialeve nuk ktheu një llogari.

Artikuj të ngjashëm