HTTP 407 zonder een bruikbare Proxy-Authenticate-uitdaging

Een client kan geen authenticatiemechanisme kiezen op basis van alleen een statusnummer. De reactie van de proxy moet beschrijven wat deze accepteert.

HTTP vereist dat een proxy die 407 genereert een Proxy-Authenticate-uitdaging stuurt. Voor een Basic-dienst is een eenvoudig voorbeeld:

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

De numerieke status, de headernaam en de schemaspecifieke syntaxis zijn allemaal belangrijk. Een gebrandmerkte foutpagina met het woord authentication in de body vervangt de header niet. Aangepaste implementaties moeten ook een volledig HTTP 407-antwoord sturen, inclusief de headerafsluiting en de body-framing.

Inspecteer het antwoord dat deze client bereikte

Leg de status- en uitdagingsvelden vast nadat geheime waarden zijn verwijderd. Een tussenlaag kan het antwoord hebben omgevormd, of een aangepaste proxy kan een ongeldige uitdaging hebben opgebouwd. Vergelijk dat bewijs met het eigen transactielog van de proxy.

Als de dienst in plaats daarvan 405 of een andere fout stuurt, herlabel dan niet elk dergelijk antwoord als 407 binnen een aangepaste client. Je zou echte fouten in het methodebeleid verbergen en toch geen betrouwbare schema-onderhandeling hebben. Repareer het gedrag van de dienst of gebruik het gedocumenteerde ondersteunde authenticatiepad.

Meerdere uitdagingen vereisen ook een echte HTTP-parser. Een komma kan parameters of uitdagingen scheiden; het hele header blind splitsen op komma's kan een realm tussen aanhalingstekens beschadigen. Gebruik de ondersteunde authenticatie-implementatie van de client in plaats van een reeks stringvervangingen.

Pas wanneer de uitdaging bruikbaar is, is het zinvol om te onderzoeken waarom de credential-provider geen account teruggaf.