Microsoft KB Archive/144483

= FP98: Main Issues Fixed by FrontPage Server Extensions v. 3.0.2.1330 =

Article ID: 144483

Article Last Modified on 7/4/2007

-

APPLIES TO


 * Microsoft FrontPage 98 Standard Edition

-



This article was previously published under Q144483



SUMMARY
This article documents the five main issues that are fixed by the FrontPage Server Extensions, version 3.0.2.1330 for FrontPage 98.



Active Server Page (ASP) Code Is Displayed Rather than Processed Page
If you activate a component (for example, click Start Search in a Search Component) on a Web page that contains a browse-time FrontPage component and either Active Server Pages (ASP) or server-side scripting code, you see the ASP code rather than the result of the ASP. This behavior potentially can cause problems if a knowledgeable user exploits this behavior to gain access to sensitive data (such as a user name or password) embedded in the ASP source code.

When some FrontPage components are activated on a Web page, the Shtml.dll file, a FrontPage Server Extensions browse-time file, is called. The calling page name is then passed as a value to the DLL. The DLL parses the Web page, performs whatever actions it should based on the components on that page, and then returns the appropriate results. If the page that contains the activated run-time component also contains ASP code, Shtml.dll parses the page and returns a Web page that contains the actual ASP code rather than the processed results of the ASP script. Normally when a Web page that contains ASP code is invoked from the browser, the Asp.dll file processes the ASP code and dynamically generates a Web page with the expected results. However, since a FrontPage component invokes Shtml.dll, passing the Web page name as a value for it to parse the page, Shtml.dll, not Asp.dll, is responsible for processing the page. As a result, the page returned to the browser still contains the unprocessed ASP source code.

This update does not remove any functionality that a Web developer might be using today. If a Web developer actually tries to combine these two technologies on a page, the developer will not achieve the intended result, because the ASP will never be processed. However, although it is unlikely anyone would design a page that combines these two technologies, there is a remote chance this combination of technologies could be exploited to gain read-only access to ASP source code and potentially sensitive information (such as user names and passwords). This issue was discovered internally, and to date we have had no reports from customers regarding this issue. However, with this update we have taken steps to ensure that no customer will encounter this.

The update addresses the issue by doing the following: If a page has either ASP code or server-side scripting, the update does not allow Shtml.dll to process that page. If a Web page or someone attempts to pass the ASP code through Shtml.dll, a standard error appears, prompting the customer to contact the Web site administrator. The Web site administrator can check the event log. This log contains an entry indicating that the attempt to fetch a non-HTML page was not completed. This update effectively eliminates the possibility of exploiting Shtml.dll to view unprocessed ASP code or viewing ASP code in a run-time component and ASP combination situation. Please note that this in no way limits or restricts the proper use of ASP code or server-side scripting on your Web site.

In this update, a setting has been added for the Frontpage.ini file called "RunTimeFileExtensions." In addition to the above cases, if Shtml.dll is invoked, it returns an error if the requested page has a file extension that does not match a file extension specified as the value of "RunTimeFileExtensions." By default, this value is .htm and .html. This new setting gives Web administrators who use custom file extensions for their Web pages to further enable or control which pages can be parsed by Shtml.dll. For more information about this setting and the update, please refer to the FrontPage Server Extensions Resource Kit.

Discussion Web Sorting
In the shipping version of FrontPage 98, you can create a discussion Web using the Discussion Web Wizard. In the wizard, you can sort your discussion Web messages in chronological or reverse chronological order. Specifying reverse chronological order in the wizard has no effect on the actual, run-time sorting of the discussion Web messages, and the messages are actually sorted in "forward" chronological order.

Discussion Web Table of Contents
Under some conditions, it is possible that a discussion Web table of contents may not list all messages that actually exist in the Web. When you recalculate a FrontPage extended Web, the pages are enumerated and their hyperlinks are recalculated in the order dictated by file system date. The Writeto.cnf file (located in the _vti_pvt folder of the Web) contains a list of the Web pages that contain "backlinks" to files where a browsing user is authorized to post new data. The discussion Web table of contents file ( toc.htm in the discussion Web) is one such file. At the beginning of the recalculation, Writeto.cnf is cleared. As the recalculation processes each file, it adds the names of the proper files to the Writeto.cnf file. If the discussion Web table of contents file is processed before all of the message files, the table of contents will not display entries for those message pages that have not yet been recalculated.

The update corrects this problem by recalculating the table of contents page last, ensuring that all message pages are listed.

Discussion Webs and Microsoft Index Server 2.0
If a FrontPage discussion Web is indexed and queried using Microsoft Index Server 2.0, the search fails. This update corrects this issue by ensuring that Index Server 2.0 indexes those files that exist in the special discussion Web folders on your FrontPage extended Web.

Nortbots.htm with Disk-Based Webs
When you create a disk-based Web with FrontPage, the run-time components, such as the Search Form and the Save Results Form Handler, do not function properly until the Web is published to a Web server on which the FrontPage Server Extensions are installed. If you activate a browse-time component on a page from a disk-based Web, an end user receives a page that displays this message:

No Run-Time Bots Available.

This page is called Nortbots.htm. This is meant to inform users that they need to install the FrontPage Server Extensions in order for the run-time components to function and that they are browsing against a Web on which the FrontPage Server Extensions have not been installed.

When you publish a disk-based Web to a Web server that has the FrontPage Server Extensions installed, this message is no longer necessary, because the "Run-Time Bots" functionality is now available. However, the links to the Nortbots.htm page still exist in the Web pages that contain the run-time components. This can result in the following error message when you activate a run-time component:

HTTP/1.0 404 Object not found.

This update corrects the problem by removing the links to the Nortbots.htm page when you publish your content to a FrontPage extended Web site.

