Un client nu poate alege un mecanism de autentificare doar după un număr de stare. Răspunsul proxy-ului trebuie să descrie ce acceptă.

HTTP cere ca un proxy care generează 407 să trimită o provocare Proxy-Authenticate. Pentru un serviciu Basic, un exemplu simplu este:

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

Starea numerică, numele antetului și sintaxa specifică schemei contează toate. O pagină de eroare cu marcă ce conține cuvântul authentication în corp nu înlocuiește antetul. Implementările personalizate trebuie să trimită și un răspuns HTTP 407 complet, inclusiv terminatorul antetului și încadrarea corpului.

Inspectați răspunsul care a ajuns la acest client

Înregistrați câmpurile de stare și de provocare după eliminarea valorilor secrete. Un intermediar poate fi transformat răspunsul, sau un proxy personalizat poate fi construit o provocare invalidă. Comparați acele dovezi cu jurnalul de tranzacții al proxy-ului însuși.

Dacă serviciul trimite în schimb 405 sau altă eroare, nu reevalua fiecare astfel de răspuns ca 407 într-un client personalizat. Ați ascunde eșecuri reale ale politicii de metode și tot nu ați avea o negociere de schemă fiabilă. Reparați comportamentul serviciului sau folosiți calea de autentificare documentată și acceptată a acestuia.

Mai multe provocări necesită și un parser HTTP real. O virgulă poate separa parametri sau provocări; împărțirea orbească a întregului antet pe virgule poate corupe un realm între ghilimele. Folosiți implementarea de autentificare acceptată a clientului în locul unei succesiuni de înlocuiri de șiruri.

Numai după ce provocarea este utilizabilă are sens să investigați de ce furnizorul de acreditări nu a returnat un cont.

Articole similare