Unfortunately, XHR has a limitation. Due to the same origin policy, the server that receives the XHR requests and the client that sends out the requests need to be in the same domain. For example, the JavaScript in the page at www.example.com/demo.html can send out XHR request to www.example.com/service.php, however, it cannot send XHR requests to www.anotherexample.com/service.php, because example.com and anotherexample.com are two different domains.
Although it is meant to enforce web security, this policy created a common problem for web applications that need to consume external data (the data from external domain).
One of the solutions is to inject JavaScript coming from the external domain to the client page of the targeted domain. Because the injected JavaScript is evaluated in the client page, the script is treated as being from the same domain.
The following script inserts a "<script>" element to the head. The source of the inserted script points to the feed service at www.externaldomain.com, and passes along the "tag" parameter.
<script type="text/javascript"> var elHead = document.getElementsByTagName("head")[0]; var script = document.createElement('script'); script.type = 'text/javascript'; script.src = 'http://www.externaldomain.com/services/feed?tag=gaming'; elHead.appendChild(script); </script>
The feed service at www.externaldomain.com takes the "tag=gaming" parameter as an input argument, retrieves a list of feeds related to gaming, and convert the gaming feeds into a JSON string. For example:
'{"feeds" : [ { "title" : "game1", "date" : "03-21-2011", "author" : "David Smith" }, { "title" : "game2", "date" : "03-22-2011", "author" : "Steve Yavorski" }, { "title" : "game3", "date" : "04-05-2011", "author" : "Kelly Lee" } ]}'
However, the service at externaldomain.com can not simply return this JSON string as response data. The "src" attribute of the script element that we're injecting should point to a JavaScript instead of a JSON string. The JSON string itself cannot be evaluated to lines of runnable JavaScript code. So what we need to do is to wrap the JSON string in JavaScript.
<script type="text/javascript"> var responseText = '{"feeds" : [ { "title" : "game1", "date" : "03-21-2011", "author" : "David Smith" }, { "title" : "game2", "date" : "03-22-2011", "author" : "Steve Yavorski" }, { "title" : "game3", "date" : "04-05-2011", "author" : "Kelly Lee" } ]}'; </script>
The above JavaScript code will be executed in the client page. JavaScript in the page is now able to parse variable responseText to get the gaming feeds.
<script type="text/javascript"> var feeds = parseJsonStr(responseText); // parseJsonStr is a pseudo function </script>
What we did above can be summarized as below:
- Inject a "<script>" element to the HTML head
- Point the "src" attribute to an external service that takes parameters and gets response data
- Wrap the response data in JavaScript
- Reference and parse the response data in JavaScript
The 3rd step "Wrap the response data in JavaScript" is also called JSON Padding, and this is where JSONP comes from.
The above approach has two problems. First, we don't quite know when the injected script finishes loading and when the responseText variable is ready to be consumed. Second, we don't want to hardcode the variable name to "responseText". The server shouldn't dictate what name the variable should be. To fix these problems, we can implement a callback function that will be invoked when the response is ready.
<script type="text/javascript"> function callback(responseText /* or whatever name you want to give */) { var feeds = parseJsonStr(responseText); // Do something about feeds ... } </script>
On the server side, the generated JavaScript will call the callback and pass in the JSON string as an input argument to the function:
<script type="text/javascript"> callback('{"feeds" : [ { "title" : "game1", "date" : "03-21-2011", "author" : "David Smith" }, { "title" : "game2", "date" : "03-22-2011", "author" : "Steve Yavorski" }, { "title" : "game3", "date" : "04-05-2011", "author" : "Kelly Lee" } ]}'); </script>
This way, we captured the moment when the response is available, and removed the naming of the JSON string from the server side.
To make things better, the name of the callback function should not be hardcoded either. We can tell the server which callback function to call by passing the name of the callback function in the URL. Here we adjust the JavaScript injecting code a bit.
<script type="text/javascript"> function onDataReceived(responseText) { var feeds = parseJsonStr(responseText); // Do something about feeds ... } var elHead = document.getElementsByTagName("head")[0]; var script = document.createElement('script'); script.type = 'text/javascript'; // callback=onDataReceived script.src = 'http://www.externaldomain.com/services/feed?tag=gaming?callback=onDataReceived'; elHead.appendChild(script); </script>
The server-side code takes the "callback=onDataReceived" parameter and passes the JSON string to the onDataReceived callback function:
<script type="text/javascript"> onDataReceived('{"feeds" : [ { "title" : "game1", "date" : "03-21-2011", "author" : "David Smith" }, { "title" : "game2", "date" : "03-22-2011", "author" : "Steve Yavorski" }, { "title" : "game3", "date" : "04-05-2011", "author" : "Kelly Lee" } ]}'); </script>
Implementation summary
What client side needs to do?
- Inject a "<script>" element to the HTML head
- Encode input arguments as query parameters into the URL of the script element's src attribute
- Include the name of the callback function to the URL
- Point the src attribute to an external service
- Define the callback function that takes JSON string as input argument
- Parse the JSON String in the callback function
What server side needs to do?
- Implement service code to answer the client requests, and expose the service through HTTP(s)
- Get all input arguments from the query parameters
- Get the callback function name
- Convert response data into JSON string
- Pass the JSON string to the callback function
Security concern
The technique of the JavaScript injection is also employed in some Cross-site Scripting (XSS) attacks. Since the consumer of the external service has no control of the returned script, the consumer can be vulnerable to XSS attacks that are introduced by the returned script from the external service. It is recommended only applying this technique for trusted external services.
s/CSS/XSS
ReplyDeleteCSS = cascading stylesheets
XSS = cross-site scripting
Might confuse people :P
Good point. I will change to XSS. Thanks.
ReplyDelete