This section of tutorial tutorial explains Cross domain Ajax calls and Same Origin policy in web browser. All modern browsers today are following the same policy.
One of the current trends in web applications is communicating with the content and functionality from two different sources. Over the last few years, Google, Yahoo, Flickr, YouTube and Amazon has allowed developers to implement in their own applications, by opening up of formerly proprietary APIs with simple one line calls to their APIs. That enables developers to the features such as adding photos, maps, videos and playlists, comments, likes etc.
Also, in business application sometimes we are forced to create the similar meshups, by making the web service calls to different IPs. In the case of web services, they are always called either with SOAP or HTTP-GET/POST requests and return information in the same way may be using XML, JSON or any other format. They are designed to be called from other domains, and in sometimes it is a contradiction to prevent them being called this way. The client applications developed has to make cross-domain web services calls, and mostly they use Ajax calls.
Browsers security restriction imposes the cross domain web Service calls using Ajax. Bowsers have the same-origin policy exists to prevent malicious use of resources. Browsers by default don’t support to make cross domain Ajax calls. If we make so, it returns the following error:
Visit the below link for more details on browser security policy: Same-origin policy.
How to get around this limitation?
There isn’t a single answer to this question; here we will see the different work around and current most popular techniques, what several techies are proposing.
1. Cross domain proxy
This is one of the most common approaches. Your script calls your server; your server makes the call to the remote server and then returns the result back to the client.
There are some definite advantages to this approach. You have more control over the entire life-cycle. You can parse the data from the remote server; do with it what you will before sending it back to the client. If anything fails along the way, you can handle it in your own way. And lastly, you can log all remote calls, with that you can track success and call failures.
2. Cross domain JSON/ JSONP
For this approach, the remote server needs to be set up to handle this. It needs to handle an additional parameter i.e. a callback function. The response back will load a JSON object as a parameter of the callback function you specified in the request.
Example:
A conventional JavaScript program might request this URL via XMLHttpRequest, to the URL
This JSON data could be dynamically generated, according to the query parameters. And it might receive the response in JSON format like this
{"Name": "User1","Id": "USRGRP111","GROUP": "GR10"}
In JSONP the src attribute in theThe received payload would be:
parseResponse({"Name": "User1","Id": "USRGRP111","GROUP": "GR10"})
3. Cross domain using Flash
Flash is much like Ajax, and by default you cannot again make cross-domain web service calls. Work around to this us we can enable the capability by placing a special XML file on the remote server to accept requests from other domains.
Limitation: The great limitation to this technique is that the browser must need to have Flash installed and enabled.
4. Disable web security policy
This approach works as a temporary fix for the application only for development purpose. Here we can disable that security policy by opening the browser with “–disable-web-security” command. This disables it for the entire browser, until you restart it. Steps to disable the browsers security policy:
- Right click on the Chrome.exe
- Add –disable-web-security command to the target path. It should look like
5. Disable web security policy using frameworks available
Use ACD framework
