Un client non può scegliere un meccanismo di autenticazione solo da un numero di stato. La risposta del proxy deve descrivere che cosa accetta.

HTTP richiede che un proxy che genera 407 invii una sfida Proxy-Authenticate. Per un servizio Basic un esempio semplice è:

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

Lo stato numerico, il nome dell'intestazione e la sintassi specifica dello schema contano tutti. Una pagina di errore brandizzata con la parola authentication nel corpo non sostituisce l'intestazione. Le implementazioni personalizzate devono anche inviare una risposta HTTP 407 completa, compresi il terminatore dell'intestazione e l'inquadratura del corpo.

Ispeziona la risposta arrivata a questo client

Registra i campi di stato e di sfida dopo aver rimosso i valori segreti. Un intermediario potrebbe aver trasformato la risposta, oppure un proxy personalizzato potrebbe aver costruito una sfida non valida. Confronta queste prove con il registro delle transazioni del proxy stesso.

Se il servizio invia invece 405 o un altro errore, non rietichettare ogni risposta di questo tipo come 407 dentro un client personalizzato. Nasconderesti veri guasti della politica dei metodi e non avresti comunque una negoziazione dello schema affidabile. Correggi il comportamento del servizio o usa il suo percorso di autenticazione supportato e documentato.

Più sfide richiedono anche un vero parser HTTP. Una virgola può separare parametri o sfide; dividere alla cieca l'intera intestazione sulle virgole può corrompere un realm tra virgolette. Usa l'implementazione di autenticazione supportata dal client invece di una successione di sostituzioni di stringhe.

Solo quando la sfida è utilizzabile ha senso indagare perché il fornitore di credenziali non ha restituito un account.

Articoli correlati