Internet Explorer 11 replaces Authorization header

Question

What would cause Internet Explorer to replace the HTTP header

Authorization : Bearer

with

Authorizat

Answer 1

I've just come across this issue too.

What was odd is that it worked fine on my development machine, it was when I deployed it the issue arose. Again it worked fine in Chrome, Firefox etc.

It turns out that the issue is that IE was detecting the site was on the localintranet zone and was therefore trying to automatically trying log on (it was set by group policy - this is an internal app).

My workaround was that (luckily) it was only autodetecting local intranet zone when using a server name that wasn't an FQDN (e.g. myserver) - but using the full A

Answer 2

I had the same problem in a knockoutjs application, it worked fine in Chrome and Firefox but not in IE.

I also used Fiddler and noticed that the first ajax call used Bearer as intended and returned successfully. But then IE started to loop and send the subsequent ajax calls over and over again with the Negotiate authorization instead!

In my case it was some sort of timing issue in IE, I solved it by making the ajax calls that loaded data during rendering synchronous.

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

Answer 3

I also encountered this issue when I was kicking off multiple data loads in my angular app.

I worked around this by detecting the browser and if IE, delayed each request by 50ms based on the index of the call:

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

Interestingly, when I used $timeout, I had to increase the delay to 100ms.

Answer 4

We had a problem where Internet Explorer was caching credentials. We could fix the problem by using the following script:

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

see: Wikipedia

Answer 5

In my case, IE alternated between sending a bad request, followed by a good request on a second attempt, then followed by a bad request again and so on.

After trying several approaches to causing IE to retry - it appears that returning a 307 (Temporary redirect) with the same request url in the Location header solves the issue.

e.g. for a request to "http://myUrl/api/service/"

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

IE retries the call with the proper data.

Edit: This method might be dangerous as it might create an infinite loop. A possible solution to work around it, is to return some counter as part of the url in the Location header and analyze it when receiving the call again.

Answer 6

We had faced similar issue with angular and web api. Issue happens when the system tries to access some resource at root level which had Windows Authentication enabled. In our case, application was trying to get the favicon from IIS root. Once this request gets unauthorized, IE will try getting the resouce with negotiation header; though it fails again. But from this point onwards, IE keep sending negotiate header instead of our bearer token. This is due to the settings in IE, which I think is in Internet Options -> Advanced tab -> Enable Integrated Windows Authentication in the Security section (not sure, I forgot the exact stuff).

Fix was either give anonymous access to root level or to the resource location which app is trying to access (bad option) or have document.execCommand('ClearAuthenticationCache', false); in the app.js file.