3

I have a piece of javascript executing on a jetty server which is sending a XMLHTTPRequest to a scoket on another server(wamp server). The request gets sent to the socket, however the XHR response seems to be getting blocked.

I have heard that I can use JSONP to overcome this problem. However as I am new to both javascript and I have never used JSONP technique before I would greatly appreciate any help in how to use this technique?

function sendPost(url, postdata, callback) {

xmlHttp=GetXmlHttpObject()

if (xmlHttp==null) {
    alert ("Browser does not support HTTP Request")
    return
} 

xmlHttp.onreadystatechange=callback
xmlHttp.open("POST",url,true)
xmlHttp.send(postdata);

}

function sendInitRQ(width, height) {

var post = "<?xml version=\"1.0\" encoding=\"UTF-8\"?><command     type=\"init\"><width>" + width + "</width><height>" + height + "</height></command>";

sendPost("http://localhost:80/socket.php", post, initReturned);

}

I know that the php socket is recieving the post as when i check the server log i get a 200 on the get request.

I just want to know how can I use the JSONP approach? I have seen exampples of the approach but Iam stilll unsure of how to do it.

danben
  • 80,905
  • 18
  • 123
  • 145
shane87
  • 3,090
  • 12
  • 51
  • 65
  • This doesn't have anything to do with cross-site scripting (XSS); to put it another way, this sort of inter-site operations issue is not what the term XSS refers to. – Pointy May 27 '10 at 13:08
  • Ah - I think I see. Between versions 1.5.2 and 1.6.4 jQuery itself started stripping out "empty" parameters like that. I don't know why, so I may end up logging a bug. – Pointy Nov 24 '11 at 21:13

1 Answers1

7

The JSONP technique uses a completely different mechanism for issuing HTTP requests to a server and acting on the response. It requires cooperating code in the client page and on the server. The server must have a URL that responds to HTTP "GET" requests with a block of JSON wrapped in a function call. Thus, you can't just do JSONP transactions to any old server; it must be a server that explicitly provides the functionality.

The idea is that your client-side code creates a <script> block dynamically, with the "src" attribute set to the URL of the JSONP server. The URL should contain a parameter telling the server the name of the Javascript function you expect it to call with the JSON data. (Exactly what parameter name to use depends on the server; usually it's "callback", but I've seen some that use "jsonp".) The client must of course have that function in the global scope. In other words, if you have a function like

function handleJSON(json) {
  var something = json.something;
  // ... whatever ...
}

then your URL tells the server to call "handleJSON", and the server response should look like this:

handleJSON({"id": 102, "something": { "more": "data", "random": true }});

Thus when the <script> block is loaded from the "src" URL you gave, the browser will interpret the contents (the response from the server) and your function will be called.

It should be clear that you should only make JSONP requests to servers you trust, since they're sending back code to execute in your client, with access to any active session(s) your client has with other secured sites.

edit — Here's a nice article: http://www.ibm.com/developerworks/library/wa-aj-jsonp1/

Pointy
  • 405,095
  • 59
  • 585
  • 614
  • 1
    Regarding "with access to any active session(s) your client has with other secured sites"... is this correct? I thought that it would be limited to the context of the page that issued the request, not other possible open sites in different tabs/windows/iframes. – jjmontes Nov 24 '11 at 19:08
  • 1
    Well, it's JavaScript that's imported into your page, and it can do anything that any other JavaScript can do. Note, for example, that your pages can load something like jQuery from Google, and that copy of jQuery has just as many capabilities as jQuery loaded from your own site. But you're right that it's all on a per-window/tab basis, so code on one tab has no visibility or access to your Home Banking window (though, if it posts to the Home Banking site, the browser **will** send along any open session cookies etc; that's what CSRF attacks rely on). – Pointy Nov 24 '11 at 21:10