I am using jQuery's .ajax to pull in content from other pages into a modal window. The majority of these pages are on the same domain and work correctly across all browsers.
There is one link that goes to another domain. That link works correctly in Chrome, Firefox, and Safari but gives an Access Denied error in Internet Explorer 8 and 9.
I searched quite a bit for a solution and tried several things that have not helped so far including:
I confirmed Access-Control-Allow-Origin was set to allow my domain. I tried setting it to "*" as well just to confirm that wasn't the issue.
I tried using different jQuery methods to make the AJAX call. I used jQuery's load, get, and ajax methods. jQuery's ajax method gave me the Access Denied error.
I tried using Internet Explorer's XDomainRequests. XDomainRequests told me there was an error but gave me no more information. I tried several changes to this code I found suggestions for like setting a timeout on the send function but no change.
I set jQuery.support.cors = true; and added crossDomain: true to my .ajax call.
I found someone who suggested that jQuery version 1.8.0 caused the issue which happens to be the version that is used on the website I am working on. The suggestion they had was to step back to version 1.7.2 which did not fix the issue. I also tried changing to version 1.11.0 but that also did not make a difference.
I saw a suggestion that adding &callback=? to the end of the url would solve it but that didn't make a difference.
I am probably forgetting something that I tried today but that should be most of it.
Here is the code I have at the moment:
jQuery.support.cors = true;
var request = $.ajax(
{
crossDomain: true,
type: "GET",
url: url,
success: function () {
console.log('success');
},
error: function (a, status, error) {
console.log('error: ' + error);
},
complete: function () {
console.log('complete');
}
});
Chrome, Firefox, and Safari log 'success' and 'complete' in the console. IE8/9 log 'error: Error: Access is denied.' and 'complete' in the console.
I ran into similar problem the other day. This is what I tried and it worked like a charm
I had the attribute dataType set to jsonp (i.e. dataType: 'jsonp') this will work for GET but not for POST
If the above still doesn't work then you can reference below script from MoonScript and it hooks the support up automatically
https://github.com/MoonScript/jQuery-ajaxTransport-XDomainRequest
I used this to make internet explorer work for me on cross domain ajax calls. I'd be happy to list my solution here as well, but I think that the link below probably explains in detail enough from a more intelligent user than me.
Jquery $.ajax fails in IE on cross domain calls
Related
I have a very simple ajax request (see below). The server is using CORS and works fine in IE 10+, Chrome, Firefox and Opera. On Microsoft Edge however, it fails with
XMLHttpRequest: Network Error 0x80070005, Access is denied.
I have researched the posts here, here, here and here, but cannot find an answer that works. Those people have had issues with IE, but adding the contentType (not required for this get) and crossDomain has it working fine.
CanIUse seems to state that CORS is usable in Edge. The request also fails on IE9 down, but CanIUse states only partial support for CORS, so that's understandable.
Any ideas how I can fix this please?
Code:
$.ajax({
crossDomain: true,
url: "http://localhost:2023/api/DoAction/test",
success: function (a) {
var res = JSON.parse(a);
alert(res.content);
},
error: function (a, e, r) {
alert(a.responseText);
}
});
Update
To add further information in case it provides any clues - the ajax request is coming from Azure and posting to a localhost website created using OWIN self hosting. This is unusual, but required for the software (which can only be used locally) to get data from a cloud service. As stated, it works fine for all other browsers, Edge is the only problem.
This problem should no longer exist for developers using Microsoft Edge. If you experience issues with localhost testing, navigate to about:flags, and make sure Allow localhost loopback is checked.
Microsoft Edge does not currently support (out of the box) localhost testing. You can however enable it by following the guidance provided here: http://dev.modern.ie/platform/faq/how-can-i-debug-localhost/.
We're working on resolving this in a future release.
For Build 10158 the command has changed slightly, with the rebranding of Spartan fully into Microsoft Edge, so to enable it in Microsoft Edge run the following command from an administrator command prompt:
CheckNetIsolation.exe LoopbackExempt -a -n=Microsoft.MicrosoftEdge_8wekyb3d8bbwe
Just before your ajax call use this : $.support.cors = true;
My Ajax cross domain request is failing in IE 9 with "Access denied". I have read through several posts regarding this topic, and AFAIK it should work.
IE9 and jQuery 1.8.1
Call is async, jsonp and crossdomain, cache is false. These are the prerequisites I have found.
Works in latest Firefox and Chrome.
jQuery.support.cors is true
Even the response header is set: Access-Control-Allow-Origin:* (SO)
The returned JSON code would also be correct, have used a checker (also see 3.)
So why is this failing with Access denied? Any idea? Could it be because my code is called from within a "JavaScript" library, and not a <script></script> tag on the page?
What am I missing?
// The code is part of an object's method (prototype)
// code resides in a library "Mylib.js"
$.ajax({
type: 'GET',
url: url,
cache: false,
async: true,
crossdomain: true, // typo, crossDomain, see my answer below
datatype: "jsonp", // dataType
success: function (data, status) {
if (status == "success" && !Object.isNullOrUndefined(data)) { ... }
},
error: function (xhr, textStatus, errorThrown) {
// access denied
}
});
-- Edit -- based on Robotsushi's comments, some further research ---
Indeed, cannot find XDomainRequest in the jQuery source code (1.8.1)
If I do not set cors (jQuery.support.cors = true) I'll end up with a "No Transport" exception.
Still wondering why others obviously succeed with IE9 cross domain requests, e.g. here: jQuery Cross-Domain Ajax JSONP Calls Failing Randomly For Unknown Reasons In Some IE Versions
The way jQuery handles this, seems to be around the code below, but this is not called in my particular case, no idea why?
// Bind script tag hack transport
jQuery.ajaxTransport( "script", function(s) {
// This transport only deals with cross domain requests
if ( s.crossDomain ) {
A similar situation here in year 2010: Jquery $.ajax fails in IE on cross domain calls However, this should have been solved by the later jQuery versions.
Ok, working now. Couple of mistakes on my side:
It is crossDomain: true, dataType: "jsonp" , typo - missed capital letters.
JSONP requests are not transparent. The data are not simply JSON notation, but have to be wrapped in a Js function call (on the server side): see http://en.wikipedia.org/wiki/JSONP Basically this means, if you cannot modify the sent data, JSONP is not the right option for you.
All things considered, it works. So my personal checklist would be:
Use json if possible (e.g. with Chrome, FF, or most likely IE10). Make sure response header is set: Access-Control-Allow-Origin:*
If using jsonp, check: async: true, jsonp and crossdomain: true, cache is false, jQuery.support.cors is true These are the prerequisites I have found.
Also make sure the jsonp response is a function call (JSON wrapped in function), not "just ordinary" JSON data.
I've had a similar issue trying to access some json that I'm storing on Google Cloud Storage and accessing using jQuery's ajaxing. This worked fine in Chrome and Firefox, but I was getting 'access denied' messages when testing in IE (9 and below).
The way I got around it was to use jsonP, explicitly:
re-write my json file to be a javascript file with a javascript variable to hold the json data, e.g.
(function (o) {
variableName = [json];
}(window.[nameSpace] = window.[nameSpace]|| {}));
include the url to the javascript file within the tag of the html file, e.g.
<script type="application/javascript" src="[url to javascript file]"></script>
Consume the data via it's variableName
Hope this helps :)
IE requires you to use XDomainRequest instead of XHR for cross site.
You can check out the easyXDM which is a js library that abstracts this process for you.
Alternatively see this :
Access denied to jQuery script on IE
I am pulling my hair out on this one.
I have a jquery ajax call to my server that works on my browser, it works on my device when I have it connected to my local proxy for http sniffing, but just hangs when it's off my proxy on the wifi or on the cell network.
I've set up the phonegap config.xml to allow my domain. The request is a get on the server as well as the ajax call. You'll notice it's jsonP.
The call is straight forward jquery, I'll post the code anyway. The api object is a custom object I made to hold the application's functionality.
var dfd = $.ajax({
url: myurl, // I've confirmed the url, but prefer to keep it private
data: {
ApplicationID: api.applicationID,
DeviceID: api.device.uuid(),
OSVersion: api.device.version(),
DeviceVersion: api.device.platform(),
Lat: lat,
Lng: lng,
Bearing: bearing
},
dataType: "jsonp",
timeout: 30000
})
.fail(function (event, jqXHR, ajaxSettings, thrownError) {
console.error(jqXHR);
});
I've tried this answer, the closest I could find to my problem, but it doesn't seem to work.
Phonegap jQuery ajax request does not work
Is there something I'm missing? What am I doing wrong?
EDIT:
I forgot to mention, the timeout I have set on the ajax call does nothing, it just seems to ignore it.
Since you pull a json string, why not use
$.getJSON("http://www.example.com?jsoncallback=?",
function(data){ ... }
Note the jsoncallback. What happens here is that jquery parses an extra parameter to the code to verify the result is from the actual request. This happens on cross-domain requests.
To make your 'json-builder' compatible, simple place the jsoncallback in front of the request:
$return = $_GET["jsoncallback"].'({"title" : "test", "author" : "someone"});
Your problem may not be, as you mentioned, cross domain. Does your server logs any requests? I have similar problem with second (the same) request after linking it from index.html, first request works fine. I found an information that it may be a phonegap bug.
It turns out my problem was entirely different. My dependencies were not loading because of how the mobile browsers add AMD scripts. I've fixed this by consolidating all scripts into a single file and it's worked ever since.
This question already has answers here:
$.ajax call working fine in IE8 and Doesn't work in firefox and chrome browsers
(3 answers)
Closed 4 years ago.
I have a script that makes an ajax request to a remote server, that returns a plain text response. It works fine in all browsers except IE8 (shocker).
Here's the code:
$.ajax({
url: 'abc.com/?somerequest=somevalue',
cache: false,
type: 'POST',
data:{
sub: 'uploadprogress',
uploadid: this.uploadId
},
dataType: 'html',
success: this.uploadProgressResp,
error: this.errorResp
});
In IE8, it returns a "No Transport" error. I suppose it's because IE8 doesn't allow cross domain requests?
NOTE: I didn't write the API for the remote server. If I did, I would return JSON response rather than a plain text response. So yes, the dataType is supposed to be HTML rather than JSON.
Try adding this somewhere before the ajax call - Best place for it is before any other JavaScript executes!
jQuery.support.cors = true;
Without this, the "No transport" error will be thrown by Internet Explorer. The error message itself is rather confusing, but by default cross-domain ajax requests are blocked by IE, but do not appear to be so by other browsers - or at least, Chrome and Firefox will function to that effect.
I shared your pain on this one, historically. Quite confident that it will sort your issue.
I know this is very old question, but sadly people still using IE8/9 and sometimes we have to support them :/
This is best solution I was able to find for this issue:
https://github.com/MoonScript/jQuery-ajaxTransport-XDomainRequest
Just include following script in your html and that's it, you don't have to modify anything in your jQuery request
<script type="text/javascript" src="//cdnjs.cloudflare.com/ajax/libs/jquery-ajaxtransport-xdomainrequest/1.0.3/jquery.xdomainrequest.min.js"></script>
Limitations:
IE6/7 isn't supported, only IE8 and IE9
Minimum jQuery version is 1.5
When using POST method in IE8/9, Content-Type header always will be
set to text/plain
Current website and requested URL both must be using same protocol (HTTP->HTTPS or HTTPS->HTTP requests will not work)
We had an interesting issue this morning - the details of the issue itself aren't relevant here, and I already fixed it, but I did run into something strange, to me, about jQuery.
The site I am building internally runs on https, only, so Apache is set to redirect any inbound http request to its https equivalent. This redirect is working fine. But, I had a bug in my software where I was trying to send the following ajax request:
jQuery.ajax({ type: "PUT",
url: "http://somewhere.com/cmdt/todo_lists/8457/toggle",
data: { deployment_id: 827},
dataType: "script"});
I understand that this would fail - I'm alright with jQuery not wanting to follow a redirect. But the actual behaviour is even weirder: I never see an xhr request go out at all! And there's no javascript error! It just fails, silently. If I change the url to https, or to a relative path, it works fine, no problem. My question is, why wasn't it TRYING to send out the request before? And why didn't it raise an error?
The reason you're not getting a failure is because it's a cross-site request, and so instead of using XMLHttpRequest, it's actually generating an HTML <script> tag and dropping it into the DOM, and using that mechanism to load the file.
This works reasonably well (considering it's a complete hack around wrong-headed browser "security" notions) but there's no way for jQuery to trap errors at that point, sadly. You will likely get a browser error if you have developer mode turned on, but that's it.
If you run that from an url that's https and try to open the equivalent http page you run into cross domain problems due to the different protocols they use. Have a look at same origin policy.