using XMLHttpRequest it is not possible to open a connection to a document on a different domain than where the page itself is hosted.
but what about different ports?
for example I have a webserver running on my machine listening on port 80 so the webaddress would look like this:
http://localhost:80/mypage.html
and I have another webserver running on localhost which is meant to process the ajax requests but listens on a different port. so the javascript in mypage.html would look like this:
var xmlhttprequest = new XMLHttpRequest();
xmlhttp.open("GET", "http://localhost:1234/?parameters", true);
xmlhttp.send();
would this work? or will it give a security exception as well?
Using a different port does indeed count as cross-site scripting.
There are several well-known ways to make a call (you can always send the data) and use the response (which is what you cannot normally do under anti-xss constraints), including JSONP and using an iframe in the page to load the data.
This wouldn't go as it is still practically on another server (at least another server instance, which may not be under your control).
You could add a Access-Control-Allow-Origin: http://yourdomain:1234/ in headers, google for Cross-Origin Resource Sharing. It's relativelly new though, not all browsers know about this.
Or you can use jQuery (read more on http://softwareas.com/cross-domain-communication-with-iframes).
Related
I am trying to post to a server listening on a different port, but FireFox insists on sending an OPTIONS request because apparently I am not using the proper URL. How can I POST to localhost:8161 without FireFox thinking the request might be cross domain and sending OPTIONS?
Here you have an answer:
How do I send a cross-domain POST request via JavaScript?
It is not easy to detail it in a better way.
You can add iframe whose src contains url with different port
Browsers don't allow cross-site AJAX calls (it's a security restriction).
Is there any possible solution ?
EDIT
I control only the caller website
If you control both parties then there a lot of options. Such as JSONP, or modifying header responses of the remote website. Unfortunately, JSONP only works if the remote website supports it. You can't force a JSONP call to a website that doesn't already support it.
However, as you have said, you only control the source website. You cannot hack the browser around this restriction for obvious reasons. You do have a third option which is creating a back-end proxy. You can use Apache and mod_rewrite to create a proxy. Here is on how to do this or this link which is more detailed.
For example
ProxyPass /api/gtalkbots http://gtalkbots.com/reverse-proxy-data.php
ProxyPassReverse /api/gtalkbots http://gtalkbots.com/reverse-proxy-data.php
Creates a proxy at /api/gtalkbots which will returns the repose from gtalkbots.com
Your best solution is to use JSONP calls.
function jsonp(url, params, callback){
var script = document.createElement("script");
script.setAttribute("src", url+'?'+params+'&callback='+callback);
script.setAttribute("type","text/javascript");
document.body.appendChild(script);
}
function doit(data){
alert(data);
}
jsonp('http://domain.com', 'foo=bar', 'doit');
In the opposite side, the website you're contacting must be able to return a JSONP formatted response in order for this to work.
There are 2 ways to do this, depending on whether the callee will ship out JSONP or not:
1. If you can, use JSONP
JSONP is a way to bypass the cross domain policy by returning a function call, rather than a naked JSON object. The P stands for padding, essentially just the part that calls the function.
For this to work, the callee needs to return JSONP.
Regular JSON looks like this:
{a: 12, b: 15}
JSONP looks like this:
callback({a: 12, b: 15});
When the AJAX request completes, the callback function (which you define in your own code) will be executed and the JSON data passed to it as an object, thus bypassing the cross domain policy.
2. If JSONP is not supported, mirror the request through your own server
The second option is to pipe data through your own server. Your JavaScript makes a request from your server, and the server then mirrors that request to the remote server and pings back the result.
Since the AJAX request is now made to your own server you won't run afoul of the cross domain policy.
There are two downsides to this approach:
Two requests are now required which will slow the response time a little, though probably not much as server to server communication will probably be via a fat pipe.
Since all requests now originate from your server you may have problems with IP based rate limits. This is the case with Twitter API calls. You may be able to mitigate against this by caching results.
The parts
I am developing against two Pylons servers and testing locally. One server is on port 5000 and is the called server. The other is on port 7000. The latter creates a cookie that specifies the same domain as used by the former server. Essentially, the first server uses credentials provided by the second server to impersonate the user.
The first server expects to find an auth token (a cookie, really) in its response.environ at run time. When I authenticate on the server on port 7000 and browser to a service on port 5000, the latter server uses the cookie created by the former and the app works.
The fly in the ointment is that the first server creates an HTML5 app that uses an ajax call to the second server, and I cannot get the cookie to be included in the ajax call. I believe that Chrome (the browser we are using/requiring for HTML5 support reasons) refuses to send the cookie for cross domain reasons: going from foo.net:7000 to foo.net:5000 is considered cross domain.
Oh, and the ajax call is through jQuery.
The question
Is there any way to make an ajax call from an HTML5 app created on a port in the same domain to a server in the same domain but a different port?
What I've tried or discard out of hand
I do not believe I can use dynamic script tag insertion because I am making the call from javascript and the HTML is generated on the client at runtime from other javascript. At least, I don't think that is a desirable solution.
I don't believe Access-Control-Allow-* is applicable because I am going from client to server, not the other way.
I've seen this on jQuery and ports in ajax calls. I've seen this, too.
I know about the same-origin policy.
And this does not work.
Agree with Michael that the simplest solution is JSONP. But even in JSONP you need to configure your server such that it supports JSONP. Many Servers deny this to keep their data secure and sound. JSONP expect your server to send data in the format that can be evaluated as the valid JSON. But its not the case in every JSONP Request and response. So, just watch out for that.
The absolutely simplest solution to this is to use JSON/P. I wish there were an easier, softer way to accomplish this, but I certainly haven't found one.
HTML5 will be next super star.
So~~~How to using new idea to implement AJAX on the WebSocket in HTML5 spec?
thx....
I think you misunderstand ajax and websockets.
All internet programs operate by using a special kind of connection known as a socket (sockets can also be used for other things, but thats not important right now). For example, when you access a webpage in Chrome, Chrome creates a socket and uses that to connect to the webserver (there are other steps, but thats the simple explanation).
Ajax is a method for updating content on a page without reloading that page (or going to a new page), this is useful for dynamic content. Ajax works through the XMLHttpRequest object in the DOM Api. When you make an Ajax request, you're asking the web browser to initiate a new connection on your behalf (the web browser may then create a new socket as it sees fit).
Websockets is an alternative api which allows you more control over the socket the web browser creates. In essence its an alternative technology which accomplishes a similar purpose. Ajax sends only a single HTTP request (usually post or get), and receives the appropriate response, thus the advantage of websockets are 2 fold:
Websockets allows for non HTTP transfers (for example, streaming VoIP).
Websockets allow for bi-direction transfers, (ie. servers making follow up requests to client).
This is not to say Ajax isn't still useful, but that Websockets allow you to do things you can't with Ajax.
Assuming a single page application accessed initially via HTTP that uses AJAX for all server interaction, is it possible to use HTTP for regular data transfers and then switch to AJAXian HTTPS requests for secure data transfers?
If so, how would the browser handle the certificate and locking notification when a HTTPS AJAX request was made?
If this is not possible, then are there any workarounds to mixing AJAX HTTP and AJAX HTTPS within the same page such as loading an iFrame for HTTPS?
Thanks!
Attempting to switch protocols will violate the same origin policy.
I am not sure how a workaround using iFrames would behave, but I think the browser may block access to the frame that was loaded as HTTPS, again due to the same origin policy.
I know this is old post but since i arrived here by search engine it would be a worth to spill what I've learn.
It is possible to use something called CORS but as usual old MSIE has problem implementing it.
It should be simple as sending additional HTTP headers:
Access-Control-Allow-Origin: http://example.com:8080 http://foo.example.com