Cross-site access

Because of the nature of my site and the limited access to PHP reources, my PHP server and main webserver are seperated.

Speed is a priority for my site, so images and main content is served from a main non-CGI or PHP server.

Using low bandwidth services like a AJAX script are perfect for providing dynamic elements to my page, whilst maintaining the speed of the main site, and keeping focus on content, even when AJAX requests are slow.

My aim is to impliment a FAQ search script.

Example of my setup.
PHP server is cgi.username.domain.com
Web-server is www.my-domain.co.uk

I had tried last night, but I am guessing that cross-site scripting prevents me from accessing cgi.username.domain.com from my main domain.

On my www.my-domain.com site, I imported a javascript file with my AJAX function in, that is located on the cgi.username.domain.com site.

When performing an execute, it wouldn't do anything. No errors.

I can only guess that it was attempting to pull from the www.my-domain.com site, a 404 is returned, and thus the javascript stops.

Next I tried changing the URI of the AJAX call to cgi.username.domain.com, which throws an obvious cross site scripting error.

Can anybody suggest methods of providing methods to access another server in this way, using AJAX.

Does Google not do something similar?
I can't spot anything there, that can help me solve it

Many thanks

Since version 1.5, there's a default protection called domain.

This behaviour disables the ability to make ajax calls from different servers. Altho, this protection can be disabled, but I highly to suggestion then to enable the export protection, otherwise a cracker can easily call any PHP function from his local machine.

To do what you wish, there's the following code:


$AJAX = new pAjax;
$AJAX->disableDomainProtection();
$AJAX->enableExportProtection();

// Now set the functions/methos you want to be accessible from script
$AJAX->export("someFunction", array("obj.method1", "obj.method2"), ...);


And in your JS code, set the URI in the pAjaxRequest Object:


var oRequest = this.prepare("obj.method1", pAjaxRequest.POST);
oRequest.setURI("some_different_domain.com/script.php");
// ...
oRequest.async();


I hope this solves your problem.


Cheers,

Thanks for the reply.

Unfortunatly, I noticed right after making the last post, that PHP4 support was lacking, so didn't do anthing.

The great news is it is back.

However, I am still having problems working out how to do cross-site calls.

My main site is hosted on www.mydomain.com, but my server with PHP access is cgi.asite.diffdomain.com

Whever I attempt to make a call to the cgi.asite.diffdomain.com site, from my JS code downloaded from www.mydomain.com, I get errors regarding whcih if I understand correct, are cross-site-scripting problems.

Is it possible to provide some form of sample code, showing a client downloaded from one server, making calls to another server?

Hello Phil,

I researched for your trouble and I found an answer closer than I expected. I'm corrently reviewing an AJAX Book, of Nicholas C. Zackas (http://www.nczonline.net), and in chapter 2, he discuss about "The Same Origin Policy".

I'll optimize what he has written, and I think this will answer your question. Currently, only XMLHttp calls are used in pAjax, but until verson 2.0, IFRAME tecnique will be added too (and now I found a good reason for this).

The Same Origin Policy are restrictions of client browser have to access another domains scripts. An "origin" is considered a domain, for example, www.domain.com. The Same Origin Policy states that any page loaded from this origin may access, download and interact (using JavaScript) any other resource from the same origin. This follows the same rules of FRAMEs; if you load in a frame another page from a different domain, you cannot access its JavaScript from the other frame. The intent is to prevent malicious programmers from getting information out of a legitimate Web page.
The Same Origin Policy also affects how XMLHttp works. So, you cannot access resources from outside the same origin. This means that you cannot open a XMLHttp with "http://" in the open method; ony relative paths can be used. If you need to access a URL located in a different origin, you must create a server side proxy to handle the comunication.


The interesting thing is that if IFRAME technique is used (like GMail does), you can access it and retrieve its data. That's why I'll add this support until version 2.0.

I hope this answers your question.


Best regards,

Guilherme, did you ever get IFRAMES to circumvent the same origin policy? As far as I know GMail does everything from the same domain and adheres to the policy. I'd be very interested to know what you have learn since originally posting this!

Thanks

Hello Craig!

Thanks for messaging me.
I've researched a lot about differences between XmlHttpRequest and IFrame technique.

XmlHttpRequest has the Same Origin Policy applyed severely, so you can't even fire a request to another domain.

Using IFrames, you can load other domain page, but you can't access JavaScript data from both sides... from parent you can't access JS inside the iframe and inside the iframe JS code you can't access parent's JS code.
I still didn't test one last possible solution (the parent grabbing the content of the iframe), but I doubt it's possible too.

I have also researched for time needed for both requests, and IFrame is better for large requests (read this for files > 10kb). I've discussed a lot with many people, and none can find more againsts for IFrame. If you measure pros and againsts of both techniques, you'll see that IFrame is better.


I started the development of "version 2.0"... it'll change completely its behavior to IFrame. I also have a name problem with Auberger (http://www.auberger.com/pajax), that we already discussed and I accepted the idea to change the name of my class (I created the class first, but generously agreed to deliver the name copyright to him).
Also, I bought a domain to place the class. I have so deep changes that it'll probably be not recognizable; it's a new class for all purposes.
The changes made will simplify even more programmer job, turning still more OO based. Soon I'll announce the website... the dev blog is ready, but it's not only about the class. =)

If you (everybody) want to discuss possibilities (and also make suggestions), you can add me on MSN: guilhermeblanco [at] hotmail [dot] com.
It'll be a pleasure to listen other developers and try to cover their wishes.

That's very helpful info Guilherme, thanks for the reply! I'll be very interested to see your new class. Though truthfully I'm more interested in the javascript components that the PHP side of things ;-)

I think there might be a way to have iframes get around "same origin" but the question would be if that is opening the door to XSS security holes.

Keep up the good work!
-Craig