HTTP 407 utan en användbar Proxy-Authenticate-utmaning

En klient kan inte välja autentiseringsmekanism enbart utifrån ett statusnummer. Proxyns svar måste beskriva vad den accepterar.

HTTP kräver att en proxy som genererar 407 skickar en Proxy-Authenticate-utmaning. För en Basic-tjänst är ett enkelt exempel:

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

Den numeriska statusen, huvudets namn och den schemaspecifika syntaxen är alla viktiga. En varumärkt felsida med ordet authentication i brödtexten ersätter inte huvudet. Anpassade implementationer måste också skicka ett fullständigt HTTP 407-svar, inklusive huvudets avslutning och brödtextens inramning.

Undersök svaret som nådde denna klient

Registrera status- och utmaningsfälten efter att hemliga värden tagits bort. En mellanhand kan ha omvandlat svaret, eller en anpassad proxy kan ha byggt en ogiltig utmaning. Jämför dessa bevis med proxyns egen transaktionslogg.

Om tjänsten i stället skickar 405 eller ett annat fel, märk inte om varje sådant svar som 407 i en anpassad klient. Du skulle dölja verkliga fel i metodpolicyn och fortfarande inte ha någon tillförlitlig schemaförhandling. Reparera tjänstens beteende eller använd dess dokumenterade och stödda autentiseringsväg.

Flera utmaningar kräver också en riktig HTTP-parser. Ett kommatecken kan separera parametrar eller utmaningar; att blint dela hela huvudet på kommatecken kan förstöra en realm inom citattecken. Använd klientens stödda autentiseringsimplementation i stället för en följd av strängersättningar.

Först när utmaningen är användbar är det meningsfullt att undersöka varför credential-leverantören inte returnerade ett konto.