The Same Origin Policy
Two scripts are considered to have the same origin if the containing pages:
If all three of these conditions aren’t met, the two scripts are not allowed to interact. For instance, a script running on cannot access a page from p2p.wisdomjobs.com because these are considered different domain names. This same script can’t access pages from www.wisdomjobs.com:8080 because it has a different port number or from about:blank because it’s a different protocol.
The effect on BOM and DOM scripting
These rules affect the way you can interact with the BOM and the DOM. For instance, you cannot access the document object for any page from a different origin, meaning that you can’t access any of the DOM structure. The following two lines illustrate the issue:
The previous code should output two alerts, each displaying the URL of the page in the second frame (the frame at index 1). You may recall from earlier in the book that both the window and document objects have a location object as a property. If the script using these two lines of code is from a different origin than the page contained in the frame, the second line of code fails because the script cannot access the document.location object or any of its properties. The script can, however, access the window. location object (represented by frames.location) and can still access all the other properties of the window.
You may also remember that the XML HTTP Request object (in all browsers) and the Web Service functionality work only with resources from the same domain; this is yet another instance where the Same Origin Policy takes effect. It also applies to plugins.
The exception to the rule
Common logic dictates that www.wrox.com and p2p.wrox.com belong to the same domain,so they should be able to communicate with one another. As it turns out, the browser developers agree and have provided a way to allow such communication.
In the pages from each subdomain, a single line of script can be included to circumvent the Same Origin Policy. This is done by setting the document.domain property as shown here:document.domain = “wisdomjobs.com”;
Window object issues
A number of measures protect end users from malicious scripts attempting to use windows.
First and foremost, windows cannot be opened off screen or smaller than 100 x 100. If you specify coordinates that are off the screen,the window is automatically placed on the screen in a location close to where you specified, but with enough space to see the entire window. Likewise,if you try to open a window smaller than 100 x 100, the window automatically opens up to 100 x 100. These rules, although seemingly impractical, help to ensure that users are always aware of windows popped up from scripts.
You also can’t open windows that are larger than the user’s desktop. You can’t, for instance, open a window that is 1600 x 1200 on a screen that is 1024 x 768.
These same window position and dimension rules apply after the window has been created. You cannot move a pop-up window off screen using moveBy() or moveTo(), nor can you resize the window to be smaller than 100 x 100 or to be larger than the desktop using resizeBy() and resizeTo().
Also a window cannot be closed using the close() method unless the window was opened using window. open(). If you try to close a window that wasn’t opened by script, a dialog is displayed asking for the user’s permission to close to the window.
Most browsers now come with pop-up blockers built-in. Many non-technical users actually have no idea whether or not pop-up blocking is turned on. Keep this in mind when designing your Web solution.
Typically, pop-up blockers work by blocking all pop-up windows that occur without user interaction, meaning that you can’t open up a new window during events such as load and unload;pop-up windows can only be opened during events such as click and keypress.However, some pop-up blockers that block all pop-up windows without regard for user interaction. So how can you tell if one of your pop-up windows has met with an untimely block?
The window.open() method typically returns a pointer to the newly created window. If the window was blocked, window.open() usually returns null:
The preceding code displays a message to the user when the window has been blocked. In general, it’s always best to make sure the method returned doesn’t return null whenever you open a window.
As part of the Netscape Communicator code overhaul, Mozilla introduced several new security mechanisms for ensuring the authenticity and safety of scripts embedded in Web pages. The first involves activating enhanced privileges.
Various security-related capabilities are arranged into privileges. In order to use these privileged functions, you must request permission from the user using netscape.security.Privilege Manager.enablePrivilege().
In order to enable a privilege,you must pass in one of these values to the enablePrivilege() method:
You may remember this line of code from Chapter 17, “Web Services.” This privilege was necessary in order to complete the Web Service calls. The UniversalBrowserRead privilege also allows you to access the URLs in the browser’s history, such as the following:
This script outputs the URL of each page in the browser’s history, as stored in the history object.
As soon as you have completed the use of privileged actions, it’s best to disable the privilege to ensure that no malicious scripts can use the privilege:
The UniversalBrowserWrite privilege is perhaps the most interesting because it enables you to avoid the window restrictions mentioned earlier. When this privilege is enabled, you can:
When a signed script is loaded, the browser displays a message asking if the signed script should be allowed to access the extended privileges it may use. The Mozilla Foundation provides SignTool to aid in the signing of scripts. This small utility packages a script into a JAR file along with its digital certificate. In order to use signed scripts, the containing HTML page must be accessed using a URL with the following format:jar:http://www.yourdomain.com/signedscripts.jar!/page.htm
Another way to access the extended privileges is to enable Codebase Principals. This policy determines the safety of a given script based on where it’s loaded from (its codebase). Presumably, a script is safe if it is being loaded from the same server as the HTML page. This is not exactly a safe assumption, which is why all Mozilla browsers come with Codebase Principals disabled. It is purposely difficult to enable so that the average user won’t turn on Codebase Principals by mistake. Codebase Principals should only be used for testing and debugging of a script that will eventually be signed.
The one million lines aren’t cumulative, so you don’t need to worry if you have scripts that run when the user clicks on different parts of the page. This restriction exists only within a single function call to prevent problems such as infinite loops and infinite recursion.
Java Script Related Tutorials
|Adv Java Tutorial||Core Java Tutorial|
|Java-Springs Tutorial||Java Servlets Tutorial|
|EJB(Enterprise JavaBeans) Tutorial||JavaServer Faces (JSF) Tutorial|
|Java Swing Tutorial||Java Tutorial|
|JavaMail API Tutorial||Java 8 Tutorial|
|Java XML Tutorial||Java Bean Utils Tutorial|
|The Java Debugger (JDB) Tutorial||Java.math Package Tutorial|
Java Script Related Interview Questions
|Java Script Interview Questions||Adv Java Interview Questions|
|Core Java Interview Questions||Java-Springs Interview Questions|
|Java Servlets Interview Questions||EJB(Enterprise JavaBeans) Interview Questions|
|JavaServer Faces (JSF) Interview Questions||Java Swing Interview Questions|
|Java 8 Interview Questions||Java XML Interview Questions|
|JavaFX Interview Questions||The Java Debugger (JDB) Interview Questions|
Java Script Related Practice Tests
|Java Script Practice Tests||Adv Java Practice Tests|
|Core Java Practice Tests||Java-Springs Practice Tests|
|Java Servlets Practice Tests||EJB(Enterprise JavaBeans) Practice Tests|
|JavaServer Faces (JSF) Practice Tests||Java 8 Practice Tests|
Java Script Tutorial
Browser And Operating System Detection
All About Events
Advanced Dom Techniques
Forms And Data Integrity
Drag And Drop
Interacting With Plugins
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.