Internet Explorer 11 ersetzt Authorization-header

Was würde dazu führen, dass Internet Explorer zu ersetzen, um die HTTP-header

Authorization : Bearer <server-provided-token>

mit

Authorization : Negotiate <some token>

wenn Sie einen AJAX-request?

Details

In Internet Explorer, einige AJAX-requests, die konfiguriert sind, enthalten die header Authorization: Bearer ... gesendet werden, die von Internet Explorer mit dem header Authorization: Negotiate ... statt.

Beispielsweise Fiddler zeigt, dass die ersten zwei von drei Anfragen enthalten die Authorization : Bearer... header, während das Dritte plötzlich enthält die Authorization : Negotiate... header. Die ersten beiden Anfragen sind erfolgreich, und die Dritte schlägt fehl, da der Antrag nicht ordnungsgemäß authentifiziert.

Alle Anfragen sind konstruiert unter Verwendung der gleichen client-seitigen code, und werden einer nach dem anderen (innerhalb der Zeitspanne von einer Sekunde). Ich habe überprüft, dass die Authorization header korrekt enthält die Bearer token in allen drei Fällen bis zu dem Punkt der Anfrage an den browser.

Auch, ich bin nicht zu sehen, das gleiche Verhalten in Chrome, es ist nur, auftreten im IE.

Anfrage 1

BEKOMMEN http://localhost/myapp/api/User HTTP/1.1 
Akzeptieren: 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

Anfrage 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 
Akzeptieren: 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-Daten Entfernt>

Anfrage 3

BEKOMMEN http://localhost/myapp/api/UserPreferences/Dashboard HTTP/1.1 
Referer: http://localhost/client/#/Dashboard 
Content-Type: application/json 
Authorization: Negotiate YHsGBisGAQUFAqBxMG+gMDAuBgorBgEEAYI3AgIKBgkqhkiC9xIbagigcsqgsib3egecagykkwybbagcnwichqi7bdlovexnu1nqaaeaaacxsgjibgagadmaaaalaasakaaaaaybsr0aaaapvk1ervzftlytu1jtq0vssvm= 
Akzeptieren: 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 die AngularJS $http service und das back-end ASP.NET Web-API in IIS gehostet.

Hi shrichards - hast du jemals herausfinden? Ich zu sein scheinen Begegnung mit dem gleichen Problem mit dem IE 11.
Ich war nie in der Lage, um zu bestimmen, die Ursache des Problems. Ich arbeitete, um das problem durch das erstellen einer separaten Dienst mit der einzigen Verantwortung der Ausgabe von Token. In IIS das token-Dienst so konfiguriert wurde, dass die Unterstützung sowohl von Windows als auch die Anonyme Authentifizierung. Der Dienst, der verwendet Token-auth war dann so konfiguriert, verwenden Sie nur die Anonyme Authentifizierung in IIS (als auth verarbeitet wurde, die über den Token in der middleware). Dies hielt IE aus versucht werden, um eine integrierte auth mit IIS, wenn die gesicherten Dienst zugegriffen wurde.
Würden Sie bitte ein detailliertes Beispiel, wie Sie diesen service, der in github oder pastebin). Ich verlor mehr als zwei Wochen mit diesem problem und immer noch nicht finden können, ein work-around. Vielen Dank im Voraus.
Martin - ich hatte bereits das gleiche setup, dass shrichards beschreibt. Ich folgte bitoftech.net/2014/09/24/..., um dies einzurichten. Ich war immer noch auftreten dieses Problems für einige Anforderungen, die der client machen (siehe meinen verlinkten Frage).
Um ein besseres feedback zu diesem Problem wäre es hilfreich zu wissen, wie der Header werden Hinzugefügt.
Ich sehe das auch, und ich bin auf der Suche nach einer guten Lösung. Nach diesem thread und werde, wenn ich eine Lösung finde

InformationsquelleAutor shrichards | 2015-02-19

17

Hatten wir ein problem mit dem Internet Explorer war das Zwischenspeichern von Anmeldeinformationen. Wir konnten das problem beheben, indem Sie mithilfe des folgenden Skripts:
```
document.execCommand('ClearAuthenticationCache', 'false');
```
finden Sie unter: Wikipedia
- Vielen Dank. Perfekte Lösung. Fügen Sie einfach diese Zeile in index.html nach dem html-tag <script>Dokument.execCommand('ClearAuthenticationCache');</script>
- Dies hat nicht funktioniert .. für uns zumindest. Es war der Auslöser der erneuten Abfrage der Authentifizierung, die auf jede Anfrage, und wir sehen noch die Authorization: Basic-header überschreiben unsere Authorization: Bearer-header 🙁
- Dies funktionierte in unserem Fall. API: .Net Core 2.1; front-end: Eckig; token-basierte Authentifizierung. Hinzugefügt ClearAuthenticationCache direkt nach der Authentifizierung und vor allen anderen API-Aufrufe.
InformationsquelleAutor Dennis Ziegan
6

Komme ich gerade über dieses Problem auch.

Was seltsam war, ist, dass es funktionierte gut auf meinem Entwicklungsrechner, es war, als ich bereitgestellt der das Problem auftrat.
Wieder lief es in Chrome, Firefox etc.

Es stellt sich heraus, dass das Problem ist, dass der IE war in der Aufdeckung der Website wurde auf der localintranet-zone und wurde deshalb versucht, automatisch zu versuchen sich anmelden (es wurde durch Gruppenrichtlinien festgelegt - dies ist eine interne app).

Mein workaround war, dass (zum Glück) es war nur autodetecting zone lokales intranet, wenn Sie mit einem server-Namen, das war nicht ein FQDN (z.B. myserver) - aber mit der kompletten A

InformationsquelleAutor BrettH
5

Ich hatte das gleiche problem in einer knockoutjs-Anwendung, es hat gut funktioniert im Chrome und Firefox aber nicht im IE.

Ich auch Fiddler und bemerkte, dass die ersten ajax-call verwendet, der Träger als gedacht und wurde erfolgreich zurückgegeben. Aber dann IE gestartet, um eine Schleife, und senden Sie die nachfolgende ajax-Aufrufe immer und immer wieder mit dem Verhandeln Autorisierung statt!

In meinem Fall war es eine Art timing-Problem im IE, ich löste es, indem die ajax-Aufrufe, die geladenen Daten beim Rendern synchron.
```
    me.loadLimits = function () {
      $.ajax({
        type: 'GET',
        dataType: 'json',
        contentType: 'application/json',
        url: '/api/workrate/limits',
        headers: me.headers,
        async: false,
        success: function (result) {
    ...
```
InformationsquelleAutor Anders Askenryd
4

Ich auch auf dieses Thema, als ich war Auftakt mehrere Daten geladen in meinem angular app.

Ich gearbeitet, um dieses durch die Erkennung der browser und wenn IE, verzögert jede Anfrage von 50ms auf der Grundlage der index der Anruf:
```
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);
});
```
Interessanterweise, wenn ich $timeout musste ich erhöhen Sie die Verzögerung auf 100ms.
- Leider scheint das nur zu funktionieren, wenn Aktualisierung einer Seite NICHT auf der ersten Seite zu laden. Immer noch die Untersuchung...
- Hast du jemals eine Lösung finden? Ich habe das gleiche Problem und implementiert eine etwas zufällige Verzögerung für jede Anforderung und schrittweise verzögerte Wiederholungen. Dies hat geholfen, aber nicht vollständig lösen das Problem
InformationsquelleAutor pilkingk
3

Hatten wir vor ähnlichen Problem mit Winkel-und web-api. Problem passiert, wenn das system versucht, auf eine Ressource auf der root-Ebene, die Windows-Authentifizierung aktiviert ist. In unserem Fall wurde die Anwendung versuchen, um das favicon von IIS-Stammverzeichnis. Sobald diese Anfrage erhält unbefugte, DH wird versuchen Sie, die Ressource mit der Verhandlung header; wenn der Fehler wieder Auftritt. Aber ab diesem Zeitpunkt, DH senden verhandeln header anstelle unserer bearer-token. Dies ist aufgrund der Einstellungen im IE, die ich denke, ist in Internet-Optionen -> Erweitert -> Aktivieren Sie die Integrierte Windows-Authentifizierung im Abschnitt "Sicherheit" (nicht sicher, ich habe die genauen Sachen).

Update war entweder gewähren Sie anonymen Zugriff auf root-Ebene oder, um die Ressource location, die app zugreifen möchte (schlechte Wahl) oder Dokument.execCommand('ClearAuthenticationCache', false); in die app.js Datei.
- "Dokument".execCommand('ClearAuthenticationCache', false); in die app.js Datei. Was meinst du? Mein Verständnis ist, dass code ist nur relevant, deaktivieren Sie die Authentifizierung cache-Speicher für Basic-Authentifizierung und nicht die Windows. Und wo würden Sie diesen code in Ihre Winkel-app? Es hätte ja sein können, nachdem Sie die Anfrage aus dem IWA-geschützten Ressourcen, aber bevor Sie die Anforderung von anon Ressourcen richtig?
- Ich meine zu haben, dass der code in deiner main-Modul/controller. AFAIK, sobald ein Antrag trifft 401 (wenn Sie versucht, auf eine Ressource zuzugreifen-geschützt unter Verwendung der windows-Authentifizierung), IE versucht, zu schlagen, dass die Ressource wieder mit verhandeln token. Und danach IE speichert das token und sendet diesen token, für alle die susequent Anfragen. Dies ist bedingt durch die Einstellung im IE (wenn ich mich richtig erinnere), die ich erwähnt habe in der Antwort. Könnten Sie bitte überprüfen, das Verhalten in der Registerkarte "Netzwerk"? Ist das verhandeln token zu gehen, nachdem die Anfrage ist fehlerhaft mit 401?
- Sind Sie noch immer mit Problem-auch nach dem clearCache code?
- Ich habe' versuchen, die clearCache-code noch nicht, weil ich nicht sicher war, wohin damit. wir haben einige Ressourcen (html, js) laden wir, das sind IWA-geschützt, aber wir bekommen auch auth-Token für unsere API von einem IWA-geschützte Ressource, so dass Sie wissen, Wann klar, dass credentials cache ist heikel. Auch, fühlt sich an wie werden wir am Ende immer aufgefordert, für die Anmeldung eine Menge mehr. Ich werde es versuchen in den nächsten Tagen
- Ich würde sagen, halten Sie es einfach, Global, in der Sie die wichtigsten module, die in den Anwendungsbereich. Sie müssen nicht, um es klar, das übliche, dies ist eine Zeit der Konfiguration.
InformationsquelleAutor Developer
0

In meinem Fall, DH abwechselnd zwischen dem senden ein bad request, gefolgt von einer guten Wunsch auf einen zweiten Versuch, dann gefolgt von einem bad request wieder und so weiter.

Nach dem Versuch, mehrere Ansätze zu verursachen, D. H. zu wiederholen - es scheint, dass wieder ein 307 (Temporary redirect) mit der gleichen request-url im Location-header löst das Problem.

z.B. bei einer Anfrage nach "http://myUrl/api/service/"
```
HTTP 307 Temporary Redirect
Location: http://myUrl/api/service/
```
IE Wiederholungen der Aufruf mit den richtigen Daten.

Edit: Diese Methode könnte gefährlich sein, wie es vielleicht schaffen eine Endlosschleife. Eine mögliche Lösung, das zu umgehen, ist wieder einige Zähler als Teil der url im Location-header analysieren und es beim Empfang der Anruf wieder.

InformationsquelleAutor Jimbidf

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.