Project Guide Security

The Project Guide security provisions in Microsoft® Office Project 2003 include support of trusted sites and management of cross-frame scripting.

Trusted Sites Restriction

Project Guide pages can access the Project object model through the Window.External object. Window.External provides access to the object model of the application that hosts Microsoft® Internet Explorer browser components. In this case, it applies to Project. For more information, see the topic external Object in the HTML and Dynamic HTML section in the MSDN® library.

Access to Window.External enables a page to read, write, or manipulate data on the user's hard disk.

The trusted sites restriction applies to scenarios where the Project Guide is ON as well as OFF. Pages located on the local hard disk are always considered trusted. For pages located on an intranet file share, such as \\servername\sharename, the user has to include this file share in the list of trusted sites in Internet Explorer. To find the trusted sites list, on the Internet Explorer Tools menu, click Internet Options, and then click the Security tab. Click the Trusted sites zone, and then click Sites.

Important  You should be very restrictive about which site locations you designate as safe. The Project Guide displays pages only from sites that the user has explicitly identified as trusted in Internet Explorer. For maximum security, you should add the most granular web or UNC address possible to the trusted sites list. For example, if a custom Project Guide is on a network share such as \\CentralServer\CustomPG\Bavaria\custom_mainpage.htm, you should add file://CentralServer/CustomPG/Bavaria, rather than file://CentralServer. to the trusted sites list. Trusting the root folder could lead to malicious attacks by other code that is put in the root folder without your knowledge.

Cross-Frame Scripting

A typical Project Guide customization scenario is to have a custom XML document for ProjectGuideContent, and custom .htm and .js files for GoalAreas and GoalAreaTasks that live on a central network share or intranet server. In most cases, organizations choose to use the default ProjectGuideFunctionalLayoutPage that is provided with Project: mainpage.htm in the pjintl.dll file.

Most GoalArea and GoalAreaTask pages have many references to functions that reside in the mainpage.htm and mainpage.js files. For efficient development, custom pages for GoalAreas and GoalAreaTasks similarly use existing functions. However, mainpage.htm and mainpage.js reside in the pjintl.dll file on the user's local computer; the custom pages usually reside on a network share or intranet server, so they will be in a different security zone.

Internet Explorer does not allow a page that is located in one security zone to call script in a different zone because of cross-frame scripting security checks. For more information on cross-frame scripting, see the Microsoft Knowledge Base article PRB: Permission Denied Error Message When Scripting Across Frames (Q167796).

Project displays only pages from trusted sites. A page from one trusted site can access script on a page from another trusted site, or on a page that is on the user's local computer. These access rules enable custom Project Guides to combine custom content with the default functional and layout pages.

Internet Explorer does not allow access to script in a different security zone directly through the parent object. The WebBrowserControlWindow method of the Window object resolves the problem. This property returns the DOM object of the Internet Explorer window loaded in the WebBrowser control that is hosted in the specified Project window. If you use the default functionality and layout page for a Project Guide, WebBrowserControlWindow returns a pointer to mainpage.htm.

For example, execute the following command in the Immediate window of the Microsoft Visual Basic® for Applications (VBA) editor in the English-language version of Project, for a project that uses the default Project Guide:

Print ActiveWindow.WebBrowserControlWindow.url

The reply string is (on one line):

res://C:\Program%20Files\Common%20Files\Microsoft%20Shared\Microsoft%20Office%20Project%2011\1033\pjintl.dll/mainpage.htm

Note  For a discussion of the res protocol, see Custom Protocols and Localization.

Instead of using the Internet Explorer parent object to access scripts on mainpage.htm, content pages can use the window.external.WebBrowserControlWindow object. For example, the default GoalArea pages call displayGoalAreaHeader from mainpage.js. You would not use the parent object directly, as in the following statement:

parent.displayGoalAreaHeader();

Instead, use the following statement:

pDisplayGoalAreaHeader();

All of the default GoalArea and GoalAreaTask pages include the util.js script file, which defines the methods pDisplayGoalAreaHeader and pScript as follows:

function pDisplayGoalAreaHeader()
{
   pscript().displayGoalAreaHeader();
}

function pscript()
{
   var parentHTMLDoc = window.external.WebBrowserControlWindow();
   return parentHTMLDoc.Script;
}

The pscript function uses WebBrowserControlWindow to return a pointer to the parent Internet Explorer window. You should use the same syntax when you write custom Project Guide pages that need to access functions on the default functionality and layout page.