Ajax loophole

[Andy]

Hey guys, if you're familiar with Ajax, then you would know the XMLHttpRequest object can only communicate with services on the same domain as the host of the webpage. Is thre a way to find a loophole to this? I want to be able make requests/receive xml to an external server.

Or, if you know how to find the CURRENT url of an iframe displaying a page on a different domain, that would work too.

Thanks!

[Tony]

I'm not sure if this is quite it... you might want to look into the "facebook beacon" setup, for some cross-domain privacy-out-the-window goodness.

[Andy]

Ahhh! very interesting, I had completely forgotten about that. Thanks for bringing it to my attention Tony.

[Zeroth]

There are very very good reasons for the limitations, Andy. I think Tony was being facetious. When you make a request of a different site, that opens up your site for whats called xss or cross site scripting. The other domain, if its not under your strict control, could hijack your webpage for their own nefarious ends (Malware, popups). What you could do, is have an XMLHttpRequest call to YOUR domain, and have the server contact the other domain. Its significantly easier to do it that way, plus, if its a common action, you could save bandwidth by only contacting the other server once, and using the results multiple times.

[apomb]

Tony @ Tue Jul 29, 2008 3:28 am wrote:

I'm not sure if this is quite it... you might want to look into the "facebook bacon" setup, for some cross-domain privacy-out-the-window goodness.

Fix'd

[Andy]

Zeroth @ Tue Jul 29, 2008 6:12 am wrote:

There are very very good reasons for the limitations, Andy. I think Tony was being facetious. When you make a request of a different site, that opens up your site for whats called xss or cross site scripting. The other domain, if its not under your strict control, could hijack your webpage for their own nefarious ends (Malware, popups). What you could do, is have an XMLHttpRequest call to YOUR domain, and have the server contact the other domain. Its significantly easier to do it that way, plus, if its a common action, you could save bandwidth by only contacting the other server once, and using the results multiple times.

Yes obviously there are problems with allowing XMLHttpRequest to connect to any server without any limitations, but that could've easily been solved by implementing a standard for allowing pages to sign the scripts they want to use.

I know you're just trying to help, but please don't assume I'm an idiot. I may be new to frontend programming, but I've done my research, and considered every obvious solution but none of them will help me achieve what I desire. Due to the nature of the data I'm trying to load from the offsite server, its quite unpractical for the host of the webpage to act as a proxy such a request.

Here's an example of what I'm trying to do.

Computer A visits a page hosted on server B. The page's javascript (on A) will then make a client side request to server C and receive a string, and use that string to load the rest of the page.

I've come up with a hackish solution that works quite well (no unfortunately javascript does not have whatdotcolor, though the hack does have to do with graphics), but I'd rather not use it given the choice.

[DemonWasp]

This is just the point: you should NOT have that choice. It's actually a security feature.

Why is it impractical for the request to go as follows?
A --XHR--> B --something--> C --something--> B --XHR--> A

That's the standard design, and it generally works quite well (plus, as noted, you can cache responses for better bandwidth usage).

[Zeroth]

Andy @ Tue Jul 29, 2008 10:34 am wrote:

Here's an example of what I'm trying to do.

Computer A visits a page hosted on server B. The page's javascript (on A) will then make a client side request to server C and receive a string, and use that string to load the rest of the page.

I've come up with a hackish solution that works quite well (no unfortunately javascript does not have whatdotcolor, though the hack does have to do with graphics), but I'd rather not use it given the choice.

The question, then, is why must you send a request to server C? I honestly can't see a single reason at all, to use XMLHttpRequest to access another server. If, however, you are trying to access a piece of server info, like, say number of diggs for an article, then there should be a signed api to use that ends up not using XHR.

[Andy]

DemonWasp @ Tue Jul 29, 2008 11:43 am wrote:

This is just the point: you should NOT have that choice. It's actually a security feature.

Why is it impractical for the request to go as follows?
A --XHR--> B --something--> C --something--> B --XHR--> A

That's the standard design, and it generally works quite well (plus, as noted, you can cache responses for better bandwidth usage).

because that would mean B is taking on unnecessary load

[Andy]

Zeroth @ Tue Jul 29, 2008 11:51 am wrote:

If, however, you are trying to access a piece of server info, like, say number of diggs for an article, then there should be a signed api to use that ends up not using XHR.

care to elaborate? on the front of digg, you can digg an article, and the counter will update automatically. how would i implement such a feature on a third party website?

[Tony]

The way Digg does that (last time I checked) is that the 3rd party website loads and IFRAME, the contents of which (the button) is actually hosted on Digg itself.

[Andy]

yes that is what i thought. which is why in my original question i stated "Or, if you know how to find the CURRENT url of an iframe displaying a page on a different domain, that would work too."
with an iframe, you can't access objects inside it, which means i can talk to the server, but i cant get a response

[Andy]

okay i figured it out.

thanks guys!

[Tony]

Andy @ Tue Jul 29, 2008 4:32 pm wrote:

with an iframe, you can't access objects inside it

Really? I haven't actually tried it myself... though considering that Firebug can explore IFRAME's DOM and that there are hidden IFRAME implementations of Comet, I would suspect that there should be a way to bridge the host page with the IFRAME's contents.

[Andy]

As long as the content displayed in the iframe is on a different host, you cannot access its objects.