Autenticação Basic preemptiva do proxy para um endpoint conhecido

Um cliente que espera o desafio primeiro aguarda que o proxy o peça. Um cliente Basic preemptivo já conhece o endpoint selecionado e envia a credencial na sua primeira requisição aplicável. Remover essa troca pode ser útil. Ainda assim, é uma decisão sobre para onde vai uma palavra-passe.

Conheça o endpoint antes da otimização

Um proxy privado fixo com uma política de autenticação conhecida é um caso mais claro do que uma camada de encaminhamento que pode escolher um intermediário desconhecido. Vincule a conta à identidade e ao protocolo esperados do proxy. Não construa um callback genérico que responda a cada desafio com uma única palavra-passe da empresa.

O Basic transporta uma representação base64 da conta, não uma prova cifrada. TLS até ao ouvinte do proxy é uma escolha de ligação distinta da sessão HTTPS do site. O túnel HTTPS do site não protege retroativamente uma credencial Basic enviada através de uma ligação cliente-para-proxy sem cifra. Uma LAN privada é um local, não uma propriedade de cifra.

Mantenha o mecanismo específico

O Basic preemptivo não é um atalho universal para Digest, NTLM ou Negotiate. Esses mecanismos têm os seus próprios requisitos de troca. Um cliente que descobre esquemas suportados pode realizar transações adicionais de forma legítima.

Use a interface de autenticação de proxy da biblioteca escolhida e depois inspecione o esquema e o âmbito efetivos. Uma definição de pré-autenticação de destino pode não controlar o aperto de mão do proxy. Uma ligação autenticada existente também pode esconder se uma nova ligação realizaria um desafio.

Compare a operação completa: número de trocas, tempo de conclusão, proteção de transporte necessária e o comportamento quando o proxy muda. Um registo mais limpo só é útil se a aplicação continuar a autenticar-se no intermediário pretendido e parar quando esse arranjo não puder ser estabelecido.