AJAX In Action [124]
7.1.3 Problems with subdomains
Finally, note that web browsers have a fairly limited notion of what constitutes the same domain and can err frustratingly on the side of caution. The domain is identified solely by the first portion of the URL, with no attempt to determine whether the same IP address backs the two domains. Table 7.1 illustrates a few examples of how the browser security model “thinks.”
Table 7.1 Examples of cross-browser security policy
Cross-Scripting
URLs
Comments
Allowed?
http://www.mysite.com/script1.js
Yes
As expected!
http://www.mysite.com/script2.js
continued on next page
Licensed to jonathan zheng 250 CHAPTER 7 Security and Ajax Table 7.1 Examples of cross-browser security policy (continued) Cross-Scripting URLs Comments Allowed? http://www.mysite.com:8080/script1.js No The port numbers don’t match (script 1 is served from port 8080). http://www.mysite.com/script2.js http://www.mysite.com/script1.js No The protocols don’t match (script 2 uses a secure HTTP protocol). https://www.mysite.com/script2.js http://www.mysite.com/script1.js No ww.mysite.com resolves to IP address 192.168.0.1, but the browser doesn’t http://192.168.0.1/script2.js try to work this out. http://www.mysite.com/script1.js No Subdomains are treated as separate domains. http://scripts.mysite.com/script2.js http://www.myisp.com/dave/script1.js Yes Although the scripts come from sites owned by different people, the domain http://www.myisp.com/eric/script2.js is the same. http://www.myisp.com/dave/script1.js No www.mysite.com points to www.myisp.com/dave, but the browser http://www.mysite.com/script2.js won’t check this. In the case of subdomains, it is possible to truncate the part of the domain being matched by setting the document.domain property. Thus, for example, in a script served from http://www.myisp.com/dave, we can add a line to the script stating document.domain='myisp.com'; which would allow interaction with a script served from the subdomain http:// dave.myisp.com/, provided that it too sets the document.domain value. It isn’t possible to set my document.domain to an arbitrary value such as www.google.com, however. 7.1.4 Cross-browser security Our discussion wouldn’t be complete without pointing out a glaring crossbrowser inconsistency. Internet Explorer security operates on a series of “zones,” with more or less restrictive security permissions. By default (for Internet Explorer 6, at least), files executing on the local filesystem are given permission to contact websites on the Internet without the user being prompted, with the Licensed to jonathan zheng Communicating with remote services 251 Figure 7.2 A security warning dialog is shown in Internet Explorer if the code tries to contact a web service not originating from its own server. If the user agrees to this interaction, subsequent interactions won’t be interrupted. local filesystem assumed to be a safe zone. The same code will trigger a security dialog if run from a local web server (figure 7.2). It is possible to write sophisticated Ajax applications and test large parts of the functionality against dummy data served directly from the filesystem. Taking the web server out of the equation does simplify a development setup during intense coding sessions. However, we urge developers testing any code that is accessing Internet web services to test it on a local web server in addition to the filesystem. Under Mozilla, there is no concept of zones, and web applications served off the local filesystem are as restricted as any delivered from a web server. Under Internet Explorer, however, the code runs in different security zones under the two situations, making for a big difference in behavior. This summarizes the key constraints within which our Ajax scripts must operate. The JavaScript