1242 Part V . Putting JavaScript to (Web host server) Work
Monday, November 26th, 20071242 Part V . Putting JavaScript to Work plug-in, a Java applet, or a JavaScript script. Because of the signed script facilities, NN4+ was designed to allow scripts to have wider range of control over the browser s interior working parts, provided the user granted permission for such activity (more about this later in the chapter). NN3 included a partially implemented prototype of another policy known as data tainting. Signed scripts supersede data tainting, so if you encounter any writings about data tainting, you can ignore them because the technology is not being further developed. By and large, the same origin policy is in force inside IE3 and after. Precise details may not match up with NN one-for-one, but the most common features are identical. The signed script policy is implemented only in NN4+. While Microsoft offers digital signatures for some items that may be embedded within an HTML page (such as ActiveX controls and other components), scripts that are in an HTML page s source code or linked in as a .jslibrary cannot be signed for IE. While everything you read in this chapter about signed scripts applies only to NN4+, you should find the next couple of sections informative even if you develop solely for IE. The Same Origin Policy The origin of the same origin policy means the protocol and domain of a source document. If all of the source files currently loaded in the browser come from the same server and domain, scripts in any one part of the environment can poke around the other documents. Restrictions come into play when the script doing the poking and the document being poked come from different origins. The potential security and privacy breaches this kind of access can cause put this access out of bounds within the same origin policy. An origin is not the complete URL of a document. Consider the two popular URLs for Netscape s Web sites: http://home.netscape.com http://developer.netscape.com The protocol for both sites is http:. Both sites also share the same domain name: netscape.com. But the sites run on two different servers: home and developer (at least this is how the sites appear to browsers accessing them; the physical server arrangement may be quite different). If a frameset contains documents from the same server at netscape.com, and all frames are using the same protocol, then they have the same origin. Completely open and free access to information, such as locationobject properties, is avail able to scripts in any frame s document. But if one of those frames contains a docu ment from the other server, their origins don t match. A script in a document from one server would display an access disallowed or permission denied error mes sage if it tried to get the location property of that other document. A similar problem occurs if you were creating a Web-based shopping service that displays the product catalog in one window and displays the order form from a secure server in another window. The order form, whose protocol might be https:, would not be granted access to the location object properties in a catalog page whose protocol is http:, even though both share the same server and domain name.
Note: In case you are looking for affordable and reliable webhost to host and run your j2ee application check Vision J2ee Web Hosting services.