Une boîte de dialogue d’identification Windows n’authentifie pas le proxy à elle seule
CredUI peut collecter les informations de compte. Le client réseau doit toujours traiter le défi d’authentification du proxy via un mécanisme pris en charge.
L’invite de sécurité Windows familière est une interface utilisateur, pas une fonction universelle « connecter cette application au proxy ».
Les fonctions CredUI peuvent collecter des informations d’identification auprès de l’utilisateur. Votre client réseau doit toujours interpréter le défi du proxy et fournir le compte via un mécanisme qu’il prend en charge.
Pour WinHTTP, la gestion de l’authentification relève du flux de requête et de ses API documentées. Un défi 407 est distinct du 401 d’un serveur d’origine, même si l’application affiche une invite similaire pour les deux.
Déterminez à quel proxy l’invite se rapporte, gérez l’annulation et limitez l’identifiant renvoyé à cet usage. Ne copiez jamais d’exemple de code qui journalise le mot de passe après avoir dépaqueté le tampon d’authentification. Démontrer que la boîte de dialogue a renvoyé du texte n’est pas une raison d’imprimer ce texte.
L’authentification intégrée peut impliquer une représentation différente des identifiants et une identité de processus différente. Ne supposez pas que chaque méthode se réduit à insérer un nom d’utilisateur et un mot de passe dans une URL de proxy.
La frontière utile est claire : l’invite obtient la saisie de l’utilisateur, l’API réseau effectue l’échange d’authentification et le proxy décide de l’accepter ou non.