I’m trying to access my server from another server, using AJAX, which I know is automatically denied to prevent other people from getting information, but how do I unblock this, or in other words, get around this so I can access this information on my other server? Thanks, all
Below is my code that i’m currently using to get the data:
var xmlHttp; var xmlStr;
function GetXmlHttpObject(){
var xmlHttp=null;
try{// Firefox, Opera 8.0+, Safari
xmlHttp=new XMLHttpRequest();
} catch (e){//Internet Explorer
try{
xmlHttp=new ActiveXObject("Msxml2.XMLHTTP");
} catch (e){
xmlHttp=new ActiveXObject("Microsoft.XMLHTTP");
}
}
return xmlHttp;
}
function stateChanged() {
if (xmlHttp.readyState==4 || xmlHttp.readyState=="complete"){
xmlStr=xmlHttp.responseText;
}
}
function loadXMLFile(){
var xmlFile="http://www.tnpfk.com/includes/ai/ai_weather.php?city="+document.getElementById('city').value+
"&country="+document.getElementById('country').value;
xmlHttp=GetXmlHttpObject();
if(xmlHttp==null){alert("Browser does not support HTTP Request");return;}
xmlHttp.onreadystatechange=stateChanged;
xmlHttp.open("GET",xmlFile,true);
xmlHttp.send(null);
}
One solution might be to write some kind of script (PHP,ASP,etc) to read the external source and make the AJAX-call to your local script.
The script will “tunnel” the other site to your site.
No can do. http://www.google.co.uk/search?q=cross-site+xmlhttprequest
It’ll probably be possible at some point in the future, but not today. Your only solution to this problem is to use a hidden iframe, which is unpleasant and not recommendable. Here is an example. It would also be liable to break as you would have to load the iframe, access its contents and either parse the innerHTML with regular expressions or walk the document in the iframe using the DOM. Both methods are fragile because the owner of the page you’re requesting can change it without your knowledge.
As scallioXTX says, you can also point to a script on your server to do this, but then you have two independent processes which can fail, which means your request for the page is twice as likely to fail. It also makes your server do twice as much work, which can in the end be expensive.
Well that sucks, I was hoping to create an AJAX Weather RSS Feed–I geuss i’ll just stick with reloading with PHP for now until something like that is supported.
Correct me if I’m wrong, but IIRC, that “other” domain will still need to give you the data your server script is asking for (and is prepared to parse). However, if you’re doing it guerilla-style, and not telling that other server and that you’re effectively “data scraping”, once they change their page, your entire setup is… well… kaput.
This problem would still exists if cross-domain XMLHTTPRequests were allowed. For most uses, there is no need for the server to parse any code, but just return the code back to the client.
We ourselves are working on a site that “calls” product feeds from a feed provider - they give us an XML feed, and our PHP handles the “parsing” into the database. There is a faster way, which is by using their API, but we wanted a bit more control, so we built our own.
This is why I do believe my knowledge is correct: I can’t see any stable way to constantly access data unless the data structure is “fixed”. I mean, even Google needs a bit of <title>,<h1>,<meta> for their spiders. I would assume that AJAX / Remote Server calls are just as particular.
That way you don’t have to worry about http tunnelling, I imagine integrating an api into your application is going to be far more streamlined than trying to re-invent the wheel.
This is possible, and I’ve done it before for a web stats script. The trick is that we won’t be using the XmlHttpRequest method at all, and we have to control the server (or hosting account) at the destination (the site you want to perform the XmlHttpRequest on).
The other server will have a PHP file (or some other server-side code) that will actually be loaded for that request using mod_rewrite.
That script will do what it needs to do, and then return ONLY javascript. That javascript will then be executed by the <script> tag in step #1 by the website that included it from another domain.
Remove the javascript after execution with DOM scripting, and include it (or another one) again to simulate additional AJAX calls.
So it’s more like - This end goal is possible, just without true “AJAX”, and through a roundabout way by including remote javascript files (you can do this dynamically with some DOM scripting) that are put together by a server-side language.
Bit of an ugly solution though…could also run into caching problems. I think tunnelling is the most sustainable option in this scenario, or using an API like Google’s to handle the grunt work for you.
While driving home from college last night I thought of the same thing felgal came up withl. I setup a PHP script that went to another PHP script on my server. Then I used XMLHttpRequest to return the server-script, which got the information, but it does take a little longer to retrieve the data. I made sure it worked in Opera, FF, Safari, and IE7, which all worked, but in any case it now works.