Currently, I am developing an angular web application that needs to be compatible with IE10. One of the requirements is to make a cross-domain call to our enterprise salesforce server. When using Chrome (not officially supported but commonly used for development), the call fails due to Chrome sending an OPTIONS preflight request to the salesforce server, which does not support CORS.
Surprisingly, IE does not send a CORS preflight request, so I expected the call to work without any issues. However, I encountered an "Access is Denied" error deep within the angular code.
Upon further investigation, I found that the specific line in Angular (v1.2.21) causing the issue is:
xhr.open(method, url, true); (line 8544 in version 1.2.21).
After browsing through discussions on GitHub, Google Groups, and Stack Overflow, it seems that the problem lies in how IE handles cross-domain requests and which XHR object is being utilized to make the call.
Previous versions of Angular had addressed this issue by adding a function before the xhr.open() call to fetch the correct XMLHttpRequest object for the IE version in use:
var xhr = createXhr(method);
xhr.open(method, url, true);
forEach(headers, function(value, key) {
if (isDefined(value)) {
xhr.setRequestHeader(key, value);
}
});
Theoretically, this approach should invoke the appropriate xhr object's .open() method. However, I still encounter an "Access is Denied" error at that line.
Suggestions from various sources recommend using XDomainRequest() instead of XMLHttpRequest for cross-domain calls in IE. Despite my skepticism, I manually edited the code in angular.js to utilize XDomainRequest() specifically for our salesforce call:
var xhr;
if (url.indexOf("salesforce.com") > -1) {
xhr = new XDomainRequest();
}
else {
xhr = createXhr(method);
}
xhr.open(method, url, true);
forEach(headers, function(value, key) {
if (isDefined(value)) {
xhr.setRequestHeader(key, value);
}
});
However, now the line where xhr.setRequestHeader(key, value) is called fails. Does anyone have insights into what could be causing this issue? It seems unlikely that Angular lacks a solution for handling cross-domain calls in IE, so I must be overlooking something.