Langage C#
  1. Langage C#
  3. Comment arrêter la mise en cache des informations d’identification sur Windows.Web.Http.HttpClient?
Intereting Posts
Rappel du contrôleur asynchrone ASP.NET MVC 4 Calculer toutes les combinaisons possibles d’une chaîne, avec une torsion c # exécuter la ligne de commande comme une invite de commande? Chaîne de caractères Unicode Comment récupérer un sous-ensemble de champs à l’aide du pilote C # MongoDB? Comment utiliser un projet C ++ à partir d’une application .NET? Ensemble protégé en VB.Net pour une propriété définie dans une interface NamedPipeClientStream ne peut pas accéder à NamedPipeServerStream sous la session 0 C #: un élément avec la même clé a déjà été ajouté lors de la compilation d’une expression Comment tester une connexion cassée de TCPClient après avoir été connecté? NHibernate n’enregistre pas une seule propriété LINQ – Trouver tous les articles d’une liste qui ne sont pas dans une autre liste Ajouter un fichier sous forme de lien dans Visual Studio – Debug vs Publish Pack d’agilité HTML pour Windows Phone 8.1 Est-il possible de remplacer une méthode par un paramètre dérivé au lieu d’un paramètre de base?

Comment arrêter la mise en cache des informations d’identification sur Windows.Web.Http.HttpClient?

J’ai un problème lorsqu’une application tente d’accéder aux ressources du même serveur à l’aide de méthodes d’authentification différentes. Les deux méthodes sont les suivantes:

  • Informations d’identification (NTLM, Basic, etc.)
  • OAuth (porteur)

Configuration de HttpBaseProtocolFilter

HttpBaseProtocolFilter est configuré pour:

  • désactiver la mise en cache
  • désactiver le popup automatique de demande d’informations d’identification de l’interface utilisateur

Code 

 HttpBaseProtocolFilter filter = new HttpBaseProtocolFilter(); filter.CacheControl.WriteBehavior = HttpCacheWriteBehavior.NoCache; filter.CacheControl.ReadBehavior = HttpCacheReadBehavior.MostRecent; filter.AllowUI = false;

Ajout d’informations d’identification du serveur

Si la ressource a besoin d’informations d’identification, j’utilise: 

 filter.ServerCredential = new PasswordCredential( RequestUri.ToSsortingng(), UserName, Password); HttpClient httpClient = new HttpClient(filter);

Ajout de jeton OAuth

Si la ressource a besoin d’un jeton porteur, j’utilise: 

 HttpClient httpClient = new HttpClient(filter); httpClient.DefaultRequestHeaders.Authorization = new HttpCredentialsHeaderValue("Bearer", token);

Les ServerCredential sont null 

 filter.ServerCredential = null

Obtenir une réponse du serveur 

 using(httpClient) { using(HttpRequestMessage requestMessage = new HttpRequestMessage(new HttpMethod(method), RequestUri)) { using(HttpResponseMessage response = await httpClient.SendRequestAsync(requestMessage)) { // Do something with response } } }

Le problème

Si la demande HttpClient renvoie 200 (OK) à l’aide de ServerCredential , chaque demande de ServerCredential suivante renvoie également 200 (OK), même si le jeton de filter.ServerCredential est non valide et que filter.ServerCredential est null.

Il semble que le filter.ServerCredential soit mis en cache et que tous les appels suivants soient authentifiés avec les informations d’identification mises en cache.

Je dois redémarrer l’application si je veux effectuer une authentification du Bearer .

Comment puis-je supprimer, désactiver ou effacer le ServerCredential de Windows.Web.Http.HttpClient?

Choses que j’ai essayées:

Supprimer tous les cookies 

 var cookieManager = filter.CookieManager; HttpCookieCollection myCookieJar = cookieManager.GetCookies(RequestUri); foreach (HttpCookie cookie in myCookieJar) { cookieManager.DeleteCookie(cookie); }

La myCookieJar est vide.

Quelque chose avec PasswordCredentialPropertyStore 

 Windows.Security.Credentials.PasswordCredentialPropertyStore credentialPropertyStore = new Windows.Security.Credentials.PasswordCredentialPropertyStore();

credentialPropertyStore est vide.

ET

La méthode Clear de PasswordCredentialPropertyStore est réservée à un usage interne et n’est pas destinée à être utilisée dans votre code.

Des idées?

Ce problème a maintenant été résolu et le correctif est inclus dans la version // build 2016 du SDK. Il y a deux parties à ce correctif:

  1. À partir de la version 10586 de Windows, les nouvelles informations d’identification peuvent remplacer les anciennes valeurs mises en cache dans la même application. Ainsi, si vous utilisiez une instance de HttpClient c1 avec (userA, paswordA), puis que vous créiez une nouvelle instance de client c2 avec (userB, passwdB) dans la même application, cela devrait fonctionner. Les nouvelles informations d’identification écrasent les anciennes mises en cache (cela ne fonctionnerait pas dans les versions précédentes).

  2. Cependant, # 1 n’est toujours pas suffisant pour vous permettre d’effacer les informations d’identification mises en cache d’origine – vous ne pouvez les écraser. Pour prendre en charge la suppression des informations d’identification mises en cache, nous avons ajouté une méthode à HttpBaseProtocolFilter – HttpBaseProtocolFilter.ClearAuthenticationCache (), qui efface toutes les informations d’identification mises en cache. Vous pouvez appeler cela lorsque vous souhaitez effacer les informations d’identification et / ou les certificates clients d’instances antérieures de HttpClient dans votre application. La documentation de cette méthode sera bientôt disponible ici

Merci Sidharth

[Équipe réseau Windows]

Merci d’avoir signalé ce problème. Il s’agit d’un comportement connu dans la stack HTTP WinINet de bas niveau qui se trouve sous l’API Windows.Web.Http.HttpClient dans le système d’exploitation. Une fois qu’une requête HTTP réussit, les informations d’identification sont mises en cache dans la mémoire de processus de cette application. Par conséquent, même si vous créez une nouvelle instance HttpClient et définissez des informations d’identification différentes dans HttpBaseProtocolFilter, les mêmes informations d’identification (d’origine) s’appliquent et seront utilisées tant qu’elles restnt valables côté serveur. (Si les informations d’identification mises en cache ne sont plus valides côté serveur, elles seront écrasées par celles nouvellement fournies.)

Nous sums conscients de ce problème et nous travaillons à le corriger en permettant l’effacement des informations d’identification mises en cache. Malheureusement, la seule solution possible consiste à demander à l’utilisateur de redémarrer l’application, ce qui effacera la mémoire de processus de l’application. Cela permettra d’utiliser un identifiant différent au début. Toutefois, ces informations d’identification restront également “inchangées” pour le rest du processus de candidature, à condition qu’elles soient valides sur le serveur.

Merci,

Sidharth Nabar [Équipe de mise en réseau Windows]

Il suffit d’append 

 uwp_bugs_never_got_fixed={something never repeat}

dans vos parameters de requête d’URL de requête.

Pour quiconque est confronté à ce problème;

J’ai eu le même problème avec les informations d’identification de base sur une application de téléphone UWP; Une fois qu’un utilisateur s’est authentifié une fois avec succès, il a mis ces informations en cache. Même lors de la fermeture de l’application, même lors du redémarrage du téléphone. Honnêtement, j’ai suspecté un bogue sur le serveur, mais il y avait une application similaire qui fonctionnait comme prévu sur le même serveur.

J’ai trouvé cela en ajoutant: 

 filter.CookieUsageBehavior = HttpCookieUsageBehavior.NoCookies

résolu mon problème. Lors de la saisie des informations d’identification appropriées, tout allait bien, lors de la nouvelle tentative avec de fausses informations d’identification, l’authentification a échoué. Exactement comme il est censé le faire!