views:

1405

answers:

6

As you know doing Cross Domain XMLHTTP requests is not allowed for security reasons under Internet Explorer.

I have a WebBrowser Control and I'm using DocumentText instead of Navigate to a URL. Since the current domain is about:blank when the page tries to do a request to itself or other domain I'm getting Access is denied Javascript error.

Even when I use Navigate if the Javascript do a request to another domain it doesn't work.

How can I get around this?

This HTML code should work with WebBrowser Control:

<body>

<a href="javascript:getit('http://www.google.com')"&gt;this should work</a>
<div id="x"></div>

</body>

<script>
function XHConn()
{
  var xmlhttp, bComplete = false;
  try { xmlhttp = new ActiveXObject("Msxml2.XMLHTTP"); }
  catch (e) { try { xmlhttp = new ActiveXObject("Microsoft.XMLHTTP"); }
  catch (e) { try { xmlhttp = new XMLHttpRequest(); }
  catch (e) { xmlhttp = false; }}}
  if (!xmlhttp) return null;
  this.connect = function(sURL, sMethod, sVars, fnDone)
  {
    if (!xmlhttp) return false;
    bComplete = false;
    sMethod = sMethod.toUpperCase();

    try {
      if (sMethod == "GET")
      {
        xmlhttp.open(sMethod, sURL+"?"+sVars, true);
        sVars = "";
      }
      else
      {
        xmlhttp.open(sMethod, sURL, true);
        xmlhttp.setRequestHeader("Method", "POST "+sURL+" HTTP/1.1");
        xmlhttp.setRequestHeader("Content-Type",
          "application/x-www-form-urlencoded");
      }
      xmlhttp.onreadystatechange = function(){
        if (xmlhttp.readyState == 4 && !bComplete)
        {
          bComplete = true;
          fnDone(xmlhttp);
        }};
      xmlhttp.send(sVars);
    }
    catch(z) { return false; }
    return true;
  };
  return this;
}

function getit(url){
    var xmlhttp = new XHConn();
    var fnWhenDone = function (oXML) { document.getElementById('x').innerHTML = oXML.responseText; alert(oXML.responseText); };
    xmlhttp.connect(url, "GET", "", fnWhenDone);
}

</script>
A: 

I don't understand on which domain you don't have access to the Javascript... Have you tried using the script tag to get the data that you want from a different domain? You can use the JSONP idiom to namespace the data...

var head = document.getElementsByTagName("head")[0];
var script = document.createElement("script");
script.src = "anotherdomain.com/data?callback=myFunction";
head.appendChild(script);

And then on "/data":

myFunction({
    // data here
});
Luca Matteis
I don't have the control over Javascript code. So I can't change it. But I want to allow Webbrowser Control to do Cross-domain requests without a specific library such as JSONP. Also it's fine if I can just change the current document.domain. But that doesn't look possible either without navigate.
dr. evil
You're going to need JSONP, I think.
Alan
How can this NOT be Javascript relevant if you're talking about Internet Explorer Security issues using XMLHTTP? Sorry, I'm not familiar with the Webbrowser Control stuff.
Luca Matteis
+3  A: 

I found a dirty workaround, load a local HTML (c:\temp\temp.html) and then modify the content of it via javascript.

After this point there is no more CrossDomain restrictions however using document.write causing other nasty problems such as JQuery .ready functions won't work.

dr. evil
A: 

A nice bounty added to the question, please ask anything you want me to clarify. It's been a while and I still couldn't solve this problem.

Also please see references in http://stackoverflow.com/questions/427532/what-do-you-do-when-youre-stuck for other stuff that I've tried find a work around.

dr. evil
This is not an answer.
Daniel Daranas
A: 

URLACTION-CROSS-DOMAIN-DATA seems to be the right direction: Read this to find out why

Kalmi
any idea how to implement in .NET ? :)
dr. evil
Kalmi
A: 

The only way to do this is to make sure your code runs in the trusted zone (or higer like HTA). By default, anything running inside the WebBrowser control runs in the zone that the files which are being served come from. (i.e. the standard IE security policies are being used.)

To change this behaviour, you'll need to change the application which is hosting the WebBrowser control and implement a few interfaces on that WebBrowser control. (IInternetHostSecurityManager, IInternetZoneManager and IInternetSecurityMgrSite are the ones that you should take a look at.) This is not a trivial task and the documentation about this is scarce at best.

Once this is done, your code can run with any privileges you need, and cross-domain requests are just as easy as resetting Mime-Sweeper high scores.

Hope this helps.

Jeroen Landheer
Thanks for the answer, definitely this is way to go. The problem though is the implementation. I've tried so many things and actually tried to implements zones as well as URL_POLICY_ALLOW stuff. Even though they work for some other stuff they didn't work for CROSS DOMAIN communication.
dr. evil
Have you tried to do cross domain requests using a HTA? An HTA is a HTML application that has full privileges. If it works in an HTA, it will work with this technique. Implementing it though is a different story...
Jeroen Landheer
A: 

Check this, it worked for me like a charm. http://support.microsoft.com/default.aspx?scid=kb;en-us;246227

TheBestOnWeb