De nos jours, le Web est le mécanisme de livraison préféré pour la plupart des applications, mais il existe des scénarios dans lesquels vous souhaiterez peut-être créer une CLI ou une application de bureau que vos clients pourront utiliser. Cependant, une fois que vous quittez les limites du navigateur, votre pauvre application devra gérer toute une série de configurations de proxy si elle doit fonctionner au sein d'un réseau d'entreprise typique.
Pour les besoins de cet article, « réseau d'entreprise typique » signifie que vos utilisateurs exécutent une version de Windows et sont assis derrière un proxy HTTP d'authentification. Bien que cela semble être une configuration assez courante, un nombre surprenant d'applications ne fonctionneront tout simplement pas dans cet environnement.
Heureusement, lors de l'écriture d'une application .NET, les paramètres par défaut vous permettent d'y parvenir gratuitement. Le proxy Web par défaut utilisera automatiquement les paramètres de proxy que l'utilisateur a configurés dans IE. Si possible, c'est sur cela que vous devriez vous appuyer. Il est tentant d'exposer les valeurs de nom d'hôte et de configuration de port du proxy que l'utilisateur peut transmettre à l'application. Toutefois, dans certains cas, un utilisateur d'entreprise peut ne pas disposer d'un seul proxy bien connu à utiliser. Les fichiers WPAD et PAC permettent de configurer dynamiquement les proxys. Voir cet article pour plus de détails sanglants.
Malheureusement, les paramètres par défaut ne gèrent pas l'authentification à votre place. Les requêtes Web échouent généralement avec une erreur 407 ProxyAuthenticationRequired. L'étape suivante consiste à examiner l'en-tête de réponse Proxy-Authenticate renvoyé pour voir quel type d'authentification le proxy accepte. Il s'agira généralement d'une combinaison de Basic, Digest, NTLM ou Négocier. Si le proxy prend en charge NTLM ou Négocier, il est alors possible d'authentifier automatiquement l'utilisateur connecté exécutant votre application en ajoutant simplement l'attribut useDefaultCredentials=true à votre app.config comme décrit. ici:
C'est particulièrement agréable car nous n'avons pas besoin de modifier le code de notre application ni de nous occuper des maux de tête liés à la gestion des informations d'identification. Hélas, cela ne fonctionnera pas si le proxy est configuré pour utiliser l'authentification Basic ou Digest. Bien qu’il s’agisse d’une configuration inhabituelle, c’est quelque chose que vous rencontrerez de temps en temps dans la nature. Si tel est le cas, vous aurez besoin d'un moyen de lire un nom d'utilisateur et un mot de passe, puis de les stocker dans la propriété IWebProxy.Credentials. Comme indiqué ici, cette configuration n'est généralement pas utilisée car elle impose à chaque application la tâche de gérer les informations d'identification du proxy.
En C#, les paramètres de proxy par défaut configurés dans app.config sont reflétés dans la variable statique WebRequest.DefaultWebProxy. Plutôt que de modifier directement ses Credentials, il est plus simple de créer un décorateur pour le proxy qui transmet les requêtes de lecture mais gère son propre ensemble de Credentials sans toucher au proxy sous-jacent :
classe publique ProxyWrapper : IWebProxy {privé en lecture seule IWebProxy _proxy ; public ProxyWrapper (proxy IWebProxy) { _proxy = proxy ; } Informations d'identification publiques ICredentials { get; ensemble; } public Uri GetProxy (Uri destination) { return _proxy.GetProxy (destination); } public bool IsBypassed (hôte Uri) { return _proxy.IsBypassed (hôte); } }
Ensuite, vous pouvez procéder comme suit pour utiliser les paramètres de proxy par défaut avec des informations d'identification personnalisées :
// La façon dont ils sont lus dépend de la chaîne de l'application username = ... SecureString password = ... IWebProxy proxy = new ProxyWrapper(WebRequest.DefaultWebProxy); proxy.Credentials = new NetworkCredential (nom d'utilisateur, mot de passe); WebRequest.DefaultWebProxy = proxy ;
Cela vous permet de revenir facilement aux informations d'identification d'origine configurées dans app.config ou d'utiliser un ensemble différent si nécessaire.
Notez que même si tout cela est assez simple pour les utilisateurs de .NET, il n'est peut-être pas aussi simple de prendre en charge les proxys d'authentification (en particulier ceux qui utilisent uniquement NTLM et Négocier) dans les bibliothèques http utilisées dans d'autres langages. Dans ces scénarios, certaines personnes ont réussi à utiliser cntlm comme proxy pour le proxy d'authentification.
TL;DR : Pour les personnes qui écrivent des applications en .NET, vous devez simplement définir useDefaultCredentials=true dans votre fichier app.config et cela devrait « fonctionner » la plupart du temps.
