Access denied in IE 10 and 11 when ajax target is localhost

Question

I'm trying to do a ajax call between a server (http) that is on internet. And target that to my own localhost. FF/Chrome/ ETC... works. It's ONLY an IE issue. IM USING IE 11 AND 10.

The request is don't even done. The "denied access" is thrown instantly.

This is the code. Just for you to see.

Is not the classical HTTP/HTTPS error in IE8 AND IE9. This is something else, but the documentation is not helpful.

$jq.ajax({
            contentType: 'application/json',
            url: url,
            dataType: 'json',
            crossDomain: true,
            beforeSend: function (xhr) {
                xhr.withCredentials = true; 
                xhr.setRequestHeader("Authorization", "Basic " + $jq.base64.encode(username and password));
            },
            success: function (data, status, headers) {},
            error: function (xhr, status, error) {}

The status is 0 in xhr object and error is "Denied access"

Solution 1

Internet Explorer raises this error as part of its security zones feature. Using default security settings, an "Access is Denied" error is raised when attempting to access a resource in the "Local intranet" zone from an origin in the "Internet" zone.

If you were writing your Ajax code manually, Internet Explorer would raise an error when you try to open the resource. For example:

var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://localhost/', true); // This line will trigger an error
xhr.send();

You can work around this error by adding the origin site to the "Trusted sites" security zone. You can test this by adding "http://client.cors-api.appspot.com" to your "Trusted sites" zone and using this test page at test-cors.org with your localhost site as the Remote URL.

Solution 2

In addition to the trusted site requirement I found that the problem was not fixed until I used the same protocol for the request as my origin, e.g. my test site was hosted on a https but failed with any destination using http (without the s).

This only applies to IE, Chrome just politely logs a warning in the debug console and doesn't fail.

Solution 3

If you are attempting to make cross-origin ajax requests in IE9, you'll need to use XDomainRequest instead of XMLHttpRequest. There is a jQuery plug-in that wraps XDR. You should be aware that there are some notable limitations of XDR.

Another option would be to use a library like this: https://github.com/jpillora/xdomain.

Solution 4

jQuery implements ajax calls using the XMLHttpRequest object which is not supported in IE9. You have to force it to use XDomainRequest instead.

I get around this problem using this jQuery plugin:

https://github.com/MoonScript/jQuery-ajaxTransport-XDomainRequest

View more solutions

Comments

[Dragos Bobolea]

OP specifically said it's IE10/11. XDomainRequest is only for IE9 and below.

[Jamie Holdstock]

User has updated his question - previously he did not indicate IE version so I assumed it was 9.

[theUtherSide]

But what if your JS is being run by someone else and you can't change their IE security settings? This solves the problem for one computer....but not for the deployed code.

[oobug]

@theUtherSide If your code is being deployed to localhost, then you're already going to be deploying/installing something on your user's workstation. If you have access to their workstation, you can change their IE security settings. If your user is deploying/installing manually, you can include the IE security settings change in your installation instructions.

[theUtherSide]

@oobug That's exactly my point --this answer only applies if you have access to change the IE security settings. That's fine if you have some internal app, but it does not apply to JS code on the wild wild web.

[oobug]

@theUtherSide The question asked is specifically about Ajax calls targeting localhost. I would advise against developing a web application that makes Ajax calls to localhost unless you've also developed something deployed to localhost.

[ᴠɪɴᴄᴇɴᴛ]

The first link is dead.

[sean]

This fixed my issue. 4 years later, IE doesn't like http vs https but other browsers don't seem to care.