Internet Explorer 11 ersetzt Authorization-Header

Question

Was Internet Explorer verursachen würde den HTTP-Header

Authorization : Bearer <server-provided-token>

mit

Authorization : Negotiate <some token>

ersetzen, wenn eine Anfrage AJAX machen?

Einzelheiten

im Internet Explorer einige AJAX-Anfragen, die von Internet Explorer mit dem Header gesendet, um den Header Authorization: Bearer ... werden Authorization: Negotiate ... stattdessen enthalten konfiguriert sind.

Zum Beispiel zeigt Fiddler, dass die ersten zwei von drei Anfragen den Header Authorization : Bearer... enthalten, während der dritte plötzlich den Header Authorization : Negotiate... enthält. Die ersten beiden Anforderungen sind erfolgreich und die dritte schlägt fehl, da die Anforderung nicht ordnungsgemäß authentifiziert werden kann.

Alle Anforderungen werden mit demselben clientseitigen Code erstellt und nacheinander (innerhalb einer Sekunde) erstellt. Ich habe überprüft, dass der Header Authorization korrekt das Token Bearer in allen drei Fällen enthält, bis zu dem Punkt, an dem die Anfrage an den Browser gesendet wird.

Auch sehe ich nicht das gleiche Verhalten in Chrome; Es tritt nur in IE auf.

Antrag 1

 
GET http://localhost/myapp/api/User HTTP/1.1 
Accept: application/json, text/plain, */* 
Authorization: Bearer oEXS5IBu9huepzW6jfh-POMA18AUA8yWZsPfBPZuFf_JJxq-DKIt0JDyPXSiGpmV_cpT8FlL3D1DN-Tv5ZbT73MTuBOd5y75-bsx9fZvOeJgg04JcO0cUajdCH2h5QlMP8TNwgTpHg-TR9FxyPk3Kw6bQ6tQCOkOwIG_FmEJpP89yrOsoYJoCfrAoZ7M4PVcik9F9qtPgXmWwXB2eHDtkls44wITF_yM_rPm5C47OPCvMVTPz30KwoEPi6fHUcL3qHauP-v9uypv2e48TyPHUwLYmNFxyafMhBx4TkovnRcsdLHZiHmSjMq0V9a2Vw70 
Referer: http://localhost/client/login.html 
Accept-Language: en-US 
Accept-Encoding: gzip, deflate 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko 
Host: localhost 
DNT: 1 
Connection: Keep-Alive 

Antrag 2

 
POST http://localhost/myapp/api/Permissions HTTP/1.1 
Referer: http://localhost/client/#/Dashboard 
Content-Type: application/json 
Authorization: Bearer oEXS5IBu9huepzW6jfh-POMA18AUA8yWZsPfBPZuFf_JJxq-DKIt0JDyPXSiGpmV_cpT8FlL3D1DN-Tv5ZbT73MTuBOd5y75-bsx9fZvOeJgg04JcO0cUajdCH2h5QlMP8TNwgTpHg-TR9FxyPk3Kw6bQ6tQCOkOwIG_FmEJpP89yrOsoYJoCfrAoZ7M4PVcik9F9qtPgXmWwXB2eHDtkls44wITF_yM_rPm5C47OPCvMVTPz30KwoEPi6fHUcL3qHauP-v9uypv2e48TyPHUwLYmNFxyafMhBx4TkovnRcsdLHZiHmSjMq0V9a2Vw70 
Accept: application/json, text/plain, */* 
Accept-Language: en-US 
Accept-Encoding: gzip, deflate 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko 
Host: localhost 
Content-Length: 1419 
DNT: 1 
Connection: Keep-Alive 
Pragma: no-cache 

<Post Data Removed> 

Antrag 3

 
GET http://localhost/myapp/api/UserPreferences/Dashboard HTTP/1.1 
Referer: http://localhost/client/#/Dashboard 
Content-Type: application/json 
Authorization: Negotiate YHsGBisGAQUFAqBxMG+gMDAuBgorBgEEAYI3AgIKBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHqI7BDlOVExNU1NQAAEAAACXsgjiBgAGADMAAAALAAsAKAAAAAYBsR0AAAAPVk1ERVZFTlYtU1JTQ0VSSVM= 
Accept: application/json, text/plain, */* 
Accept-Language: en-US 
Accept-Encoding: gzip, deflate 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko 
Connection: Keep-Alive 
DNT: 1 
Host: localhost 

Die Anforderungen werden über den Dienst AngularJS $http hergestellt werden, und das Back-End ist die in IIS gehostete ASP.NET-Web-API.

Answer 1

Ich hatte das gleiche Problem in einer Knockoutjs-Anwendung, es funktionierte gut in Chrome und Firefox, aber nicht in IE.

Ich benutzte auch Fiddler und bemerkte, dass der erste Ajax-Aufruf Bearer wie beabsichtigt verwendet und erfolgreich zurückgegeben wurde. Aber dann begann IE zu loopen und die nachfolgenden Ajax-Aufrufe immer wieder mit der Negotiate-Berechtigung zu senden!

In meinem Fall war es eine Art von Timing-Problem in IE, ich löste es, indem Sie die Ajax-Aufrufe, die Daten während des Rendern synchron geladen.

me.loadLimits = function() { 
     $.ajax({ 
     type: 'GET', 
     dataType: 'json', 
     contentType: 'application/json', 
     url: '/api/workrate/limits', 
     headers: me.headers, 
     async: false, 
     success: function (result) { 
    ... 

Answer 2

Wir hatten ein Problem, bei dem Internet Explorer Anmeldeinformationen zwischenspeichert.Wir konnten das Problem beheben, indem Sie das folgende Skript verwenden:

document.execCommand('ClearAuthenticationCache', 'false'); 

siehe: Wikipedia

Answer 3

ich auch über dieses Thema gerade gekommen sind.

Was seltsam war, dass es auf meiner Entwicklungsmaschine gut funktionierte, war es, als ich es einsetzte, entstand das Problem. Erneut funktionierte es in Chrome, Firefox usw.

Es stellt sich heraus, dass IE erkannte die Website war in der LocalIntranet-Zone und versuchte daher automatisch versuchen, anmelden (es wurde von Gruppenrichtlinien eingestellt - Dies ist eine interne App).

Meine Abhilfe war, dass (zum Glück) nur lokale Intranetzone Auto-Erkennung wurde, als einen Servernamen verwenden, der nicht ein FQDN war (zB myserver) - aber im Voll A

Answer 4

ich auch dieses Problem auftreten, wenn ich löste mehrere Datenladungen in meiner eckigen App aus.

ich durch Erfassen des Browsers und wenn IE um dies funktioniert, verzögert jede Anfrage von 50ms basierend auf dem Index des Gesprächs:

return $q(function(resolve, reject) { 
var delay = self.widget.useDelayLoading ? self.widget.index * 50 : 0; 

setTimeout(function() { 
    restService.genericApi(self.widget.url, false).queryPost(json).$promise 
    .then(
    function(r) { resolve(r); }, 
    function(e) { reject(e); } 
    ); 
}, delay); 
}); 

Interessant ist, wenn ich $timeout verwendet, musste ich die Verzögerung erhöhen 100ms.

Answer 5

Wir hatten ähnliche Probleme mit eckigen und Web-API konfrontiert. Problem tritt auf, wenn das System versucht, auf eine Ressource auf Root-Ebene zuzugreifen, für die Windows-Authentifizierung aktiviert ist. In unserem Fall versuchte die Anwendung, das Favicon vom IIS-Root zu beziehen. Sobald diese Anfrage unautorisiert wird, wird IE versuchen, die Ressource mit dem Verhandlungs-Header zu bekommen; obwohl es wieder fehlschlägt. Aber ab diesem Zeitpunkt sendet IE weiterhin einen Verhandlungs-Header anstelle unseres Bearer-Tokens. Dies liegt an den Einstellungen in IE, die ich denke, ist in Internetoptionen -> Registerkarte Erweitert -> Integrierte Windows-Authentifizierung aktivieren im Bereich Sicherheit (nicht sicher, ich habe die genauen Sachen vergessen).

Fix wurde entweder geben anonymen Zugriff auf Root-Ebene oder auf den Speicherort der Ressource, auf die app versucht zuzugreifen (schlechte Option) oder document.execommand ('ClearAuthenticationCache', false); in der Datei app.js.

Answer 6

In meinem Fall wechselte IE zwischen dem Senden einer schlechten Anfrage, gefolgt von einer guten Anfrage bei einem zweiten Versuch, gefolgt von einer schlechten Anfrage und so weiter.

Nachdem Sie mehrere Versuche versucht haben, IE erneut zu versuchen, scheint die Rückgabe eines 307 (Temporary Redirect) mit der gleichen Request-URL im Location-Header das Problem zu lösen.

z.B. für einen Antrag auf „http://myUrl/api/service/“

HTTP 307 Temporary Redirect 
Location: http://myUrl/api/service/ 

IE wiederholt den Aufruf mit den richtigen Daten.

Bearbeiten: Diese Methode kann gefährlich sein, da sie eine Endlosschleife erstellen könnte. Eine mögliche Lösung, um dies zu umgehen, besteht darin, einen Zähler als Teil der URL im Location-Header zurückzugeben und diesen beim erneuten Empfangen des Anrufs zu analysieren.