AJAX In Action [125]
There are, however, legitimate reasons for invoking scripts from domains other than your own, such as when dealing with a publisher of web services. We’ll see in the next section how to relax the security considerations for situations such as these.
7.2 Communicating with remote services
Building security into the web browser is a sensible move, but it can also be frustrating. Security systems have to distrust everyone in order to be effective, but there are situations where you will want to access a resource on a third-party server for legitimate reasons, having thought through the security implications for yourself. Now that we understand how the browsers apply their security policy, let’s discuss ways of relaxing it. The first method that we’ll look at requires additional server-side code, and the second one works on the client only. Licensed to jonathan zheng 252 CHAPTER 7 Security and Ajax 7.2.1 Proxying remote services Because of the “server of origin” policy, an Ajax application is limited to retrieving all its data from its own web domain. If we want our Ajax application to access information from a third-party site, one solution is to make a call to the remote server from our own server rather than from the client, and then forward it on to the client (figure 7.3). Under this setup, the data appears to the browser to be coming from the local server, and so the server of origin policy is not violated. In addition, all data is subject to the scrutiny of the server, giving an opportunity to check for malicious data or code before forwarding it to the client. Web browser Server of origin Proxy servlet The Internet Other server Remote web service Figure 7.3 If an Ajax application needs to access resources from other domains, the server of origin can proxy the resources on the Ajax client’s behalf. Licensed to jonathan zheng Communicating with remote services 253 On the downside, this approach does increase the load on the server. The second solution that we’ll examine goes directly from the browser to the thirdparty server. 7.2.2 Working with web services Many organizations these days provide web services that are intended to be used by external entities, including JavaScript clients. An Ajax client will want to contact a web service directly. The server of origin security policy is a problem here, but it can be overcome by programmatically requesting privileges to perform network activities. This request may be passed on to the user, or remembered by the browser and applied automatically, if the user has so instructed. In this section, you’ll learn how to call a third-party web service directly from an Ajax client application. Internet Explorer and Mozilla Firefox each handle these requests in their own ways, and we’ll see how to keep them both happy. Our example program will contact one of Google’s web services using the Simple Object Access Protocol (SOAP). SOAP is an XML-based protocol built on top of HTTP. The basic principle of SOAP is that the request sends an XML document to the server, describing parameters to the service, and the server responds with an XML document describing the results. The XML sent by SOAP is rather bulky, itself consisting of headers and content wrapped up in an “envelope.” Because of its use of XML, it is ideal for use with the XMLHttpRequest object. Google offers a SOAP interface to its search engine, in which the user can transmit a search phrase in the request and get back an XML document that lists a page of results. The XML response is very similar to the data presented visually in a Google search results page, with each entry listing a title, snippet, summary, and URL. The document also lists the total estimated number of results for the phrase. Our application