Internet Explorer 11 заменяет заголовок авторизации

Ответ 1

У нас была проблема, когда Internet Explorer кэшировал учетные данные. Мы могли бы исправить эту проблему, используя следующий script:

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

см. Wikipedia

Ответ 2

У меня была такая же проблема в приложении knockoutjs, она отлично работала в Chrome и Firefox, но не в IE.

Я также использовал Fiddler и заметил, что первый вызов ajax использовал Bearer, как предполагалось, и успешно вернулся. Но затем IE начал цикл и отправлять последующие вызовы ajax снова и снова с помощью авторизации Negotiate!

В моем случае это была какая-то проблема с синхронизацией в IE, я решил ее, сделав вызовы ajax, которые загружали данные во время рендеринга синхронно.

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

Ответ 3

Я тоже столкнулся с этой проблемой.

Что было странно, так это то, что он отлично работал на моей машине разработки, именно когда я развернул ее, возникла проблема. Снова все отлично работало в Chrome, Firefox и т.д.

Оказывается, проблема в том, что IE обнаруживал, что сайт находился в зоне локального набора и поэтому пытался автоматически пытаться войти в систему (он был задан групповой политикой - это внутреннее приложение).

Мое обходное решение заключалось в том, что (к счастью) это было только автоопределение локальной зоны интрасети при использовании имени сервера, которое не было FQDN (например, myserver), но с использованием полного A

Ответ 4

Я также столкнулся с этой проблемой, когда я начал загружать несколько загрузок данных в моем приложении angular.

Я работал над этим, обнаружив браузер, и если IE задерживает каждый запрос на 50 мс на основе индекса вызова:

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);
});

Интересно, что когда я использовал $timeout, мне пришлось увеличить задержку до 100 мс.

Ответ 5

Мы столкнулись с аналогичной проблемой с angular и web api. Проблема возникает, когда система пытается получить доступ к некоторому ресурсу на корневом уровне, на котором была включена проверка подлинности Windows. В нашем случае приложение пыталось получить значок из корня IIS. Когда этот запрос будет неавторизован, IE попытается получить резус с заголовком переговоров; хотя он терпит неудачу снова. Но с этого момента IE продолжает отправлять заголовок для переговоров вместо нашего токена-носителя. Это связано с настройками в IE, которые, как мне кажется, находятся в "Свойствах Интернета" → вкладка "Дополнительно" → "Включить встроенную проверку подлинности Windows" в разделе "Безопасность" (не уверен, я забыл точные данные).

Исправление было либо анонимным доступом к корневому уровню, либо к тому месту, в котором приложение пытается получить доступ (плохая опция), или иметь document.execCommand('ClearAuthenticationCache', false); в файле app.js.

Ответ 6

В моем случае IE чередовался между отправкой плохого запроса, за которым следовал хороший запрос при второй попытке, затем последовал плохой запрос и т.д.

После попытки нескольких попыток заставить IE повторить попытку, кажется, что возвращение проблемы 307 (временная перенаправление) с тем же URL-адресом запроса в заголовке Location решает проблему.

например. для запроса " http://myUrl/api/service/"

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

IE повторяет вызов с соответствующими данными.

Изменить: Этот метод может быть опасным, так как он может создать бесконечный цикл. Возможное решение для его работы - вернуть некоторый счетчик в качестве части URL-адреса в заголовке Location и проанализировать его при повторном вызове.