HTTP Post et Put renvoie 401 Non autorisé sur des postes de travail spécifiques lors de l'authentification en utilisant l'authentification intégrée Negotiate on IIS windows

Question

Nous avons un comportement étrange sur une petite quantité de postes de travail (Windows 7). Notre client .NET communique avec le service REST Api (API Web 2) hébergé dans IIS. Le client utilise System.Net.Http.HttpClient pour accéder à l'API et cible le .NET Framework 4.5.2. Api est configuré pour utiliser Windows Integrated Authentication (Négocier, NTLM).

Lorsque le client appelle Api à l'aide de HTTP GET/DELETE, tout fonctionne. Lorsque le client appelle Api à l'aide de HTTP POST/PUT (les données sont envoyées via le corps de la demande). L'IIS répond avec 401 non autorisé.

Ce problème disparaît:

• lors de l'exécution proxy sur le poste de travail Fiddler client.
• IIS authentification est configuré pour utiliser NTLM

Je suis passé par de nombreux articles du blog et des articles mais n'a pas trouvé une solution.

• Fiddler fixe mon application http://www.telerik.com/blogs/help!-running-fiddler-fixes-my-app-
• Dépanner authentification Kerberos https://blogs.msdn.microsoft.com/friis/2009/12/31/things-to-check-when-kerberos-authentication-fails-using-iisie/

SignalR montre le même comportement bizarre. Le client communique également avec le service à l'aide de SignalR. Le client peut se connecter au Hub et recevoir des messages. Mais obtient 401 en essayant d'invoquer une méthode (appel signalR est fait en utilisant POST). Puisque le client est sur Windows 7, il ne supporte pas WebSockets. Le même comportement est sur les deux transports (événements envoyés par le serveur, interrogation longue). C'est un comportement similaire à SignalR net45 gives 401 Unauthorized on specific user/machine combinations. Le correctif (utilisation de Microsoft.AspNet.SignalR.Client.2.2.0 \ lib \ net40 \ Microsoft.AspNet.SignalR.Client.dll) à partir de ce post fonctionne également pour SignalR.

Modifier: SignalR net40 n'utilise pas HttpClient de System.Net.Http. L'erreur doit donc être connectée à la bibliothèque System.Net.Http.

Un grand merci pour vos suggestions.

Answer 1

solution de contournement possibles sont:

• Définir System.Net.ServicePointManager.Expect100Continue = false; avant de créer une instance de HttpClient

• Désactiver cette 100Continue sur HttpClient

  var c = new HttpClient(); 
  c.DefaultRequestHeaders.ExpectContinue = false;