[RESOLVED] Getting around cross-domain AJAX in Firefox?

[semi-sentient]

This is a Firefox only issue. I've done some searching and I haven't been able to come up with a solution for this. None of the examples I've tried seem to work, for whatever reason.

Essentially I'm getting that wonderful "Permission denied to call method XMLHttpRequest.open". I tried setting the appropriate privileges, but that results in an exception with the message "A script from "http://servername" was denied UniversalBrowserRead privileges".

Any idea what I'm doing wrong??? If not then I have to basically make this an IE only application, which kinda blows. So that you know what I'm attempting to do here...

1) The page is accessed by internal users on an internal web server.
2) Once "submitted", the script makes an AJAX call to our public web server, which will return a "success" or "failure" result.

Here is my code:objReq = (window.XMLHttpRequest ? new XMLHttpRequest() : new ActiveXObject("Microsoft.XMLHTTP"));

if (objReq) {
objReq.onreadystatechange = function() {
if (objReq.readyState == 4) {
if (objReq.status == 200) {
try {
if (!document.all && netscape.security.PrivilegeManager.enablePrivilege) {
netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");
}
} catch(e) {
alert("(Mozilla) - " + e);
}
alert(objReq.responseText);
} else {
alert("There was a problem processing the job.\n\nPlease contact the IT Help Desk.\n\nError: " + objReq.statusText);
}
}
}
try {
if (!document.all && netscape.security.PrivilegeManager.enablePrivilege) {
netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");
}
} catch (e) {
alert("(Mozilla) - " + e);
}
objReq.open("POST", url, true);
objReq.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
objReq.send(url);
} else {
alert("There was a problem processing the job.\n\nPlease contact the IT Help Desk.");
}

I understand the security concerns associated with xss attacks, but this is a pretty significant limitation in Mozilla. At a minimum, there should be a prompt that asks if the request is allowable instead of just blocking it completely. I hope there's a client-side workaround for this...

[etylocus]

What you could do is instead of requesting a page to the external server, make the request to a special page in your internal server, that's going to act as a gateway between the client and the external server. This page then queries the external server (using XMLHTTP ;) ), and returns the data to the client.

[Orc Scorcher]

enablePrivilege will always fail unless you set the configuration option signed.applets.codebase_principal_support to true first.

[semi-sentient]

enablePrivilege will always fail unless you set the configuration option signed.applets.codebase_principal_support to true first.

That did the trick. I'll just have to inform the users who want to use Firefox with this application that they will need to set this (and advise them on the risks).

[semi-sentient]

What you could do is instead of requesting a page to the external server, make the request to a special page in your internal server, that's going to act as a gateway between the client and the external server. This page then queries the external server (using XMLHTTP ;) ), and returns the data to the client.

I could do that, but it would further complicate an already complicated application. I'm having to do several AJAX requests already in JS (locally), then parse out XML (by applying XSL). Then I have to handle an AJAX request in Visual Fox Pro and return valid XML, in addition to doing yet another AJAX request after that (in VFP that is). The last thing I want to do is write a middle-man AJAX handler in ASP (which is what the web server supports) because then I'm dealing with 3 different AJAX implementations / DOM parsers and that's a complete pain in the butt. Having to work with Visual Fox Pro is frustrating enough...

[felgall]

I could do that, but it would further complicate an already complicated application.

Well the right way to use Ajax is to use it to call your server and then let the server side code call the remote host. Any other way is certainly not going to work at least for the vast majority of browsers. I don't think most browsers even have an option to allow Javascript to access remote domains since that is a major security risik and anyone would have to be a complete idion to turn that feature on in the browsers that do have it.

Also how do you know it is a Firefox only issue? How many thousands of different browsers have you tested it in?

Sounds like you have a choice between further complications to make it work or keep it simple and useless.

[semi-sentient]

Well the right way to use Ajax is to use it to call your server and then let the server side code call the remote host. Any other way is certainly not going to work at least for the vast majority of browsers. I don't think most browsers even have an option to allow Javascript to access remote domains since that is a major security risik and anyone would have to be a complete idion to turn that feature on in the browsers that do have it.

Also how do you know it is a Firefox only issue? How many thousands of different browsers have you tested it in?

Sounds like you have a choice between further complications to make it work or keep it simple and useless.

First of all, this is an internal only application, so when I say Firefox only issue it's because we only have two browsers in-house: IE and FF. If this were a publically available application then I would take the time to write server-side code that gets around the issue. Anyway, thousands of different browsers? Get real. There are only 3 or 4 browsers that are worth bothering with. Thousands my ass.

Second, using 3 different implementations of AJAX/XML becomes very difficult when you have to manipulate the data in all 3 languages. I guess you think that all languages implement everything the same? You know how difficult it is to translate code from JavaScript to VBScript to VFP? When you have to do heavy string manipulation at all 3 "locations", you quickly realize that keeping it simple is the best thing to do.

Third, this isn't a real cross-domain issue, at least not in the classical sense. All the servers that I'm accessing are on the local network (the public server has an internal interface). Why shouldn't I be allowed to make AJAX calls on a local network?

So anyway, my users will have to click a simple button to authorize the request. Big deal. That makes it useless, right?

Get out of here with that elitist garbage.

[semi-sentient]

P.S. Resource theft and XSS attacks are rarely (if ever) considered "major security risks".

[felgall]

Well you never said it was an internal site. With an internal site you have a lot more control over the setup of the system and can restrict users to just two browsers as you have done.

On the internet you usually need it to work on at least IE7, IE6, IE5.5, Firefox 2.0, Firefox 1.5, Firefox 1.0, Netscape 8, Netscape 7, Opera 9, Opera 8, Safari, and any other browsers that a significant number of your visitors are using (out of the many hundreds of different browsers out there). Also internet visitors are less likely to click a link authorizing something that their existing security has blocked.

[semi-sentient]

It goes without saying that this implementation wouldn't work well on the internet, and if VFP wasn't involved, I'd probably take the time to write a server-side handler. That was actually my first approach, but as I realized how complex things were getting (not to mention time consuming), I backed away. A large part of the reason is that we run mostly a PHP shop and developing the server-side solution in ASP would limit who could maintain it. Unfortunately the web server I'm working on is running 3rd party software that requires ASP, and our admins frown upon putting PHP on a Windows box--so that's all there really was to work with.

Whatever the case, Firefox now functions how IE functions in that it will prompt the user before allowing submission and retrieval.

And I apologize for sounding a little harsh earlier. It was a pretty long and frustrating day at work, not that it excuses my tone. I appreciate whatever tips I can get.