Noms d'utilisateur qualifiés par domaine dans les identifiants proxy
Distinguez un nom de compte opaque des API dotées de champs de domaine séparés, et évitez de modifier l'identité d'un compte uniquement pour satisfaire la syntaxe d'une URL.
Une réponse dit de supprimer DOMAIN\. Une autre dit de l'ajouter. Les deux changements peuvent être erronés pour votre proxy.
Deux questions se posent : quelle identité le service attend, et comment l'API choisie représente cette identité.
| Interface | Ce qu'il faut établir |
|---|---|
| Un champ unique de nom de compte | La syntaxe exacte du compte acceptée par l'opérateur |
| Une API d'identifiants avec un champ de domaine | Si le domaine et le nom d'utilisateur doivent être fournis séparément |
| Composants d'identifiants dans un URI | Comment les valeurs visées doivent être encodées pour ce conteneur |
Par exemple, .NET expose un constructeur NetworkCredential avec des arguments distincts pour le nom d'utilisateur, le mot de passe et le domaine. Placer un domaine dans deux champs sans discernement n'est pas un moyen portable de configurer l'authentification intégrée.
L'authentification de base est un autre cas : le serveur interprète le texte de compte fourni selon sa propre politique. Être sur le même réseau ne prouve pas qu'un préfixe de domaine soit implicite. Un nom qualifié par domaine n'est pas non plus automatiquement un autre protocole d'authentification.
L'échappement d'URL doit préserver le compte visé plutôt que de le modifier. Une barre oblique inverse dans une chaîne du langage source, une barre oblique inverse dans un nom de compte et sa représentation encodée en pourcentage dans un URI sont des couches distinctes.
Obtenez auprès de l'opérateur la forme d'identité et le schéma acceptés, puis utilisez l'interface d'identifiants correspondante. Alterner au hasard entre un nom court, un nom de domaine et un nom ressemblant à une adresse électronique produit des preuves faibles concernant le 407 d'origine.