332 Part II: Developing an Ajax Library^
If you want to fetch information from another site or even mash-up content from a
number of resources, you are going to find Ajax, as it currently stands, not very friendly.
This makes perfect sense if you consider that same-origin restrictions are in effect. If your
page is hosted on ajaxref.com, any script using an XHR simply cannot natively call
weather.com and google.com and combine the information.
One method to address the same-origin policy with Ajax is to use a server proxy.
Consider that if the example is hosted at http://ajaxref.com/ch7/
notarealservicedemo.html, calls can be issued to pages like http://ajaxref.com/
ch7/weatherproxy.php and http://ajaxref.com/ch7/googleproxy.php that would
go out and make requests to the services in question and pass the data back to the browser
and meet the same-origin restrictions. This approach will work, but it does open up
concerns with a proxy that an attacker may be able to abuse and launch attacks against
those sites. You certainly do not want to build your proxy like http://ajaxref.com/ch7/
proxy.php?site=X&payload=Y, where X is the site and Y is payload. Such open proxies
are the dream of hackers worldwide for launching attacks, and they quickly share
information about such exposed services. While the limited proxy will work, it too can be
used as a launch pad to attack the sites it can proxy to unless you take pains to request it
with Referer checks, double cookie systems, and other methods to try to ensure the
requests are coming from valid users.
Alternatively, to get around the same-origin issue, we can turn back to the traditional
mechanisms like <script> tags to fetch data including script code and JSON data.
However, as you have seen, can you trust such data not to contain something evil? Consider
that each Web service that you contact if it is compromised would be executed in our
security context and could cause all sorts of mischief. There needs to be some sort of shield
to keep possible bad code at bay.
To demonstrate one possible technique, a request is made to Yahoo that provides JSON
and JSONP responses that can be used via <script> tag calls, thus breaking the same-
origin restriction. For example, if you issued a URL like:http://search.yahooapis.com/WebSearchService/V1/webSearch?appid=XXXXXX&query=" +
searchterm + "&output=jsonyou would receive a JSON packet as a response that you might consume:{"ResultSet":{"type":"web","totalResultsAvailable":1140000,"totalResultsReturned
":10,"firstResultPosition":1,"moreSearch":"\/WebSearchService\/V1\/webSearch?
query=%22+++searchterm+++%22&appid=XXX®ion=us","Result":[{"Title":
"SearchTerm (JavaMail API documentation)","Summary":"public abstract class
SearchTerm. extends java.lang.Object. implements java.io.Serializable ...
SearchTerm() Method Summary. abstract boolean. match(Message msg)
...","Url":"http:\/\/java.sun.com\/products\/javamail\/javadocs\/javax\/
mail\/search\/SearchTerm.html","ClickUrl":"http:\/\/uk.wrs.yahoo.com\/_
ylt=A0Je5VymUJxGdMYA_iPdmMwF;_ylu=X3oDMTB2cXVjNTM5BGNvbG8DdwRsA1dTMQRwb3MDMQRzZW
MDc3IEdnRpZAM...snip...SearchTerm.html%26w=searchterm%26d=Y-re7urnPC6Q%26icp=
1%26.intl=us","Size":"6149"}}]}}NNOT EOTE We strip the appid out of the code listing and replace it with XXX, but you have to provide a
correct ID value to make these types of queries. Apply for one directly at Yahoo or other sites you
would like to query.