HTTP 407 sen un desafío Proxy-Authenticate utilizábel
Inspeccione o cabeceiro de autenticación do proxy cando o cliente nunca chama o seu xestor de credenciais ou recibe un estado inesperado no canto dun desafío normal.
Un cliente non pode escoller un mecanismo de autenticación a partir dun número de estado por si só. A resposta do proxy debe describir o que acepta.
HTTP esixe que un proxy que xera un 407 envíe un desafío Proxy-Authenticate. Para un servizo Basic, un exemplo sinxelo é:
HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="Office proxy"O estado numérico, o nome do cabeceiro e a sintaxe específica do esquema importan por igual. Unha páxina de erro de marca coa palabra authentication no seu corpo non substitúe o cabeceiro. As implementacións personalizadas tamén deben enviar unha resposta HTTP 407 completa, incluído o terminador do cabeceiro e o enmarcado do corpo.
Inspeccione a resposta que chegou a este cliente
Capture os campos de estado e desafío despois de eliminar os valores secretos. Pode que un intermediario transformase a resposta, ou que un proxy personalizado construíse un desafío non válido. Compare esa evidencia co rexistro de transaccións do propio proxy.
Se o servizo envía 405 ou outro erro no seu lugar, non reetiquete cada unha destas respostas como 407 dentro dun cliente personalizado. Ocultaría fallos reais da política de métodos e seguiría sen ter unha negociación de esquema fiable. Repare o comportamento do servizo ou use a súa ruta de autenticación compatible documentada.
Os desafíos múltiples tamén requiren un analizador HTTP real. Unha coma pode separar parámetros ou desafíos; dividir todo o cabeceiro a cegas polas comas pode corromper un realm entre comiñas. Use a implementación de autenticación compatible do cliente en lugar dunha sucesión de substitucións de cadeas.
Só cando o desafío é utilizábel ten sentido investigar por que o provedor de credenciais non devolveu unha conta.