JSONP stands for JavaScript Object Notation with Padding. The response to a JSONP request is not parsed as JSON, but as JSON-formatted data. We Played with ‘plain’ JSON, right? Look here – Get your Twitter™s Tweet as RSS and JSON with New Twitter API.
The JavaScript Object Notation, JSON in short, is a compact data format for man and machine easily readable text form for the purpose of data exchange between applications. Any valid JSON document is a valid JavaScript, can be interpreted by eval () function. Due to small variations in the amount of allowable Unicode characters, however it is possible to generate JSON objects that are not accepted by a standards-compliant JavaScript interpreter. Apart from this JSON works regardless of the programming language. Parsers exist in virtually all widely used languages. JSON was originally developed by Douglas Crockford. Currently it is specified by two competing standards, the RFC 7159 by Douglas Crockford and ECMA-404.
But, we are not talking about JSON, but JSONP. JSONP (JSON with Padding ) allows transmission of (JSON) data on domain boundaries. Usually Ajax data queries are sent to the server via the XMLHttpRequest object of a web browser. The problem of same-origin policy can be circumvented by JSONP.
The Basic Idea about JSONP Script Tags
The src attribute of a script element can possibly specify arbitrary URLs. For this attribute, the same-origin policy does not apply. So, it is possible to specify a URL in a different domain, the example returns JSON data. This script would have no effect. The server packaged this JSON data to the client to process, as a parameter to a JavaScript function that is already defined in the web browser. The name of this function is the server via a querystring communicated to the URL; for example:
This was the example of Padding. This JSON data could be dynamically generated, according to the query parameters passed in the URL. For each JSONP call their own is ---
Vulnerabilities of JSONP
The script elements allow a server to transmit any content (not just JSON objects) to the web browser. This may lead to a malicious web service via the returned data spying on private information in the web browser or changed in meaning. Since the same-origin policy is not observed in the script element , a malicious website can request JSONP and analyze data, which are not intended for them ( Cross-Site Request Forgery ). The problem occurs when sensitive data should be protected from third parties.
To Summarize JSONP
For example, say the server expects a parameter called "callback" to enable its JSONP capabilities. Then your request would look like:
1 | https://thecustomizewindows.com/responsive/?callback=mycallback |
Without JSONP, this might return some basic JavaScript object, like so:
1 | { foo: 'bar' } |
However, with JSONP, when the server receives the callback parameter, it wraps up the result a little differently, returning something like this:
1 | mycallback({ foo: 'bar' }); |
As you can see, it will now invoke the method you specified. So, in your page, you can define the callback function:
1 2 3 | my callback = function(data){ alert(data.foo); }; |
And now, when the script is loaded, it will be evaluated, and your function will be executed. This is hoe cross-domain requests work.
It is also worth noting the one major issue with JSONP : you lose a lot of control of the request. For example, there is no "nice" way to get proper failure codes back. As a result, you end up using timers to monitor the request, which is always a bit suspect. The proposition for JSONRequest is a great solution to allowing cross domain scripting, maintaining security and allowing proper control of the request.
