Nombres de usuario cualificados por dominio en credenciales de proxy
Distinga un nombre de cuenta opaco de las API con campos de dominio separados, y evite cambiar la identidad de una cuenta solo para satisfacer la sintaxis de la URL.
Una respuesta dice que elimine DOMAIN\. Otra dice que lo añada. Ambos cambios pueden ser erróneos para su proxy.
Hay dos preguntas: qué identidad espera el servicio y cómo representa esa identidad la API elegida.
| Interfaz | Qué hay que establecer |
|---|---|
| Un único campo de nombre de cuenta | La sintaxis exacta de cuenta que acepta el operador |
| Una API de credenciales con campo de dominio | Si el dominio y el nombre de usuario deben proporcionarse por separado |
| Componentes de credenciales dentro de un URI | Cómo deben codificarse los valores previstos para ese contenedor |
Por ejemplo, .NET expone un constructor NetworkCredential con argumentos separados de nombre de usuario, contraseña y dominio. Poner un dominio en dos campos sin criterio no es una forma portátil de configurar la autenticación integrada.
La autenticación básica es otro caso: el servidor interpreta el texto de cuenta proporcionado según su propia política. Estar en la misma red no demuestra que se presuponga un prefijo de dominio. Ni un nombre cualificado por dominio es automáticamente un protocolo de autenticación distinto.
El escapado de URL debe preservar la cuenta prevista en lugar de cambiarla. Una barra invertida en una cadena del lenguaje de origen, una barra invertida en un nombre de cuenta y su representación codificada con porcentaje dentro de un URI son capas separadas.
Obtenga del operador la forma de identidad y el esquema aceptados y luego utilice la interfaz de credenciales correspondiente. Alternar al azar entre un nombre corto, un nombre de dominio y un nombre con aspecto de correo electrónico produce pruebas débiles sobre el 407 original.