Nomes de usuario cualificados por dominio nas credenciais de proxy
Distinga un nome de conta opaco das API con campos de dominio separados, e evite cambiar a identidade dunha conta só para satisfacer a sintaxe da URL.
Unha resposta di que elimine DOMAIN\. Outra di que o engada. Ambos os cambios poden ser erróneos para o seu proxy.
Hai dúas preguntas: que identidade espera o servizo e como representa esa identidade a API escollida.
| Interface | Que hai que establecer |
|---|---|
| Un único campo de nome de conta | A sintaxe exacta de conta que acepta o operador |
| Unha API de credenciais con campo de dominio | Se o dominio e o nome de usuario deben fornecerse por separado |
| Compoñentes de credenciais dentro dun URI | Como deben codificarse os valores previstos para ese contedor |
Por exemplo, .NET expón un construtor NetworkCredential con argumentos separados de nome de usuario, contrasinal e dominio. Poñer un dominio en dous campos sen criterio non é unha forma portátil de configurar a autenticación integrada.
A autenticación básica é outro caso: o servidor interpreta o texto de conta fornecido segundo a súa propia política. Estar na mesma rede non demostra que se presupoña un prefixo de dominio. Nin un nome cualificado por dominio é automaticamente un protocolo de autenticación distinto.
O escapado de URL debe preservar a conta prevista en lugar de cambiala. Unha barra invertida nunha cadea da linguaxe de orixe, unha barra invertida nun nome de conta e a súa representación codificada en porcentaxe dentro dun URI son capas separadas.
Obteña do operador a forma de identidade e o esquema aceptados e despois use a interface de credenciais correspondente. Alternar ao azar entre un nome curto, un nome de dominio e un nome con aspecto de correo electrónico produce probas débiles sobre o 407 orixinal.