Nomes de usuário qualificados por domínio em credenciais de proxy
Distinga um nome de conta opaco de APIs com campos de domínio separados e evite alterar a identidade de uma conta apenas para satisfazer a sintaxe da URL.
Uma resposta diz para remover DOMAIN\. Outra diz para adicioná-lo. Ambas as alterações podem estar erradas para o seu proxy.
Há duas perguntas: qual identidade o serviço espera e como a API escolhida representa essa identidade.
| Interface | O que estabelecer |
|---|---|
| Um único campo de nome de conta | A sintaxe exata de conta aceita pelo operador |
| Uma API de credenciais com campo de domínio | Se o domínio e o nome de usuário devem ser fornecidos separadamente |
| Componentes de credenciais dentro de um URI | Como os valores pretendidos devem ser codificados para esse contêiner |
Por exemplo, o .NET expõe um construtor NetworkCredential com argumentos separados de nome de usuário, senha e domínio. Colocar um domínio em dois campos sem critério não é uma forma portátil de configurar a autenticação integrada.
A autenticação Basic é outro caso: o servidor interpreta o texto de conta fornecido segundo a própria política. Estar na mesma rede não prova que um prefixo de domínio esteja implícito. Nem um nome qualificado por domínio é automaticamente um protocolo de autenticação diferente.
O escapamento de URL deve preservar a conta pretendida em vez de alterá-la. Uma barra invertida numa string da linguagem de origem, uma barra invertida num nome de conta e sua representação codificada em porcentagem dentro de um URI são camadas separadas.
Obtenha do operador a forma de identidade e o esquema aceitos e use a interface de credenciais correspondente. Alternar ao acaso entre um nome curto, um nome de domínio e um nome semelhante a e-mail produz evidências fracas sobre o 407 original.