HTTP 407 ou 401: qual login está falhando?

Um 407 pede autenticação no proxy. Um 401 pede autenticação no recurso de destino. A mesma requisição pode encontrar os dois, então descubra quem está pedindo antes de fornecer uma senha.

Compare o status e os cabeçalhos de desafio

O status é uma primeira pista essencial, mas examine toda a troca. Uma página com 407 escrito no texto não equivale a uma resposta HTTP 407 real. Da mesma forma, uma página de login personalizada pode retornar 200 e ainda exigir autenticação na camada da aplicação.

Por que uma requisição HTTPS pode falhar com 407 antes de chegar ao site

Quando um proxy HTTP comum transporta uma requisição HTTPS, o cliente normalmente pede primeiro que ele estabeleça um túnel CONNECT. O proxy pode exigir autenticação para essa requisição CONNECT. Se ela não for concluída, a sessão TLS com o destino ainda não foi estabelecida pelo túnel; portanto, trocar o token de API do site provavelmente não resolverá essa etapa.

Use uma requisição com saída detalhada para ver onde o desafio aparece:

curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/

Troque o listener local pelo seu e leia o primeiro desafio no log. Um 407 durante CONNECT acontece antes do TLS do destino; um 401 posterior pode surgir depois que o túnel foi estabelecido com sucesso.

Forneça credenciais pela interface do proxy

Para um endpoint e uma conta fornecidos por um administrador de confiança, o curl pode negociar o esquema de autenticação do proxy e solicitar uma senha que não foi informada:

curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/

Substitua o endpoint e o usuário de exemplo pelos dados do serviço que você tem autorização para usar. Informar só o usuário evita colocar a senha diretamente no comando acima. Os métodos aceitos podem variar entre builds do curl e proxies; se a negociação falhar, confira o desafio real e as capacidades do build.

A opção de autenticação do proxy é separada da opção de autenticação do usuário na origem no curl. Não adicione um cabeçalho Authorization da origem como substituto para responder ao desafio do proxy. Evite também encaminhar manualmente cabeçalhos de credenciais do proxy a requisições sem relação ou salvá-los em cabeçalhos reutilizados por toda a aplicação.

Se o proxy continuar retornando 407

• Confirme que está usando o host e a porta do proxy pretendidos.
• Confira os esquemas anunciados pelo proxy em vez de presumir autenticação Basic.
• Confirme o estado da conta e se o serviço exige um formato específico de usuário.
• Confira como os caracteres especiais são passados se as credenciais estiverem em uma URL.
• Determine se a autenticação corporativa integrada ao navegador precisa de suporte do ambiente de execução ou da plataforma.
• Quando as evidências do cliente forem insuficientes, peça ao administrador um identificador de requisição ou uma entrada de log do servidor com os dados sensíveis removidos.

Um 403 ou CONNECT negado pode ser uma decisão da política de acesso mesmo depois de um login bem-sucedido. Mais tentativas de senha não darão acesso a um destino proibido.

O HTTPS do destino não protege toda troca de credenciais do proxy

A autenticação do proxy pode ocorrer antes de estabelecer o TLS do destino. Se a conexão com o próprio proxy for sem criptografia e o método expuser credenciais reutilizáveis nesse trecho, um destino HTTPS não protege essa troca retroativamente. Escolha um transporte e uma autenticação adequados ao serviço, e não envie contas particulares a um proxy público desconhecido.

Revise os logs detalhados antes de compartilhá-los. Mesmo que uma ferramenta oculte campos comuns de credenciais, os logs ainda podem conter usuários, nomes de endpoints internos, cookies ou outros dados que identifiquem alguém.