Adapting FrontPage Server Extensions for Large Web Presence Providers

If you are an administrator at a very large Web Presence Provider (WPP) where the environment is highly customized, you can adapt Microsoft® FrontPage Server Extensions to fit your custom solutions.

This adaptable implementation of the FrontPage Server Extensions is known as lightweight server support. Lightweight server support is designed for WPPs who have many thousands of Web sites and who have the resources to create custom solutions. Typically, such WPPs create custom code for automating the process of setting up and maintaining customer accounts.

If you are running the FrontPage Server Extensions in lightweight server support mode, it is assumed that custom solutions at your site take into account any and all necessary security measures. Because the FrontPage Server Extensions do not contribute any security functionality when running in a lightweight server configuration, the security of your web environment depends completely upon your custom solutions.

Note   In lightweight server support mode, you cannot disable anonymous upload to your site when you use the File Upload component that comes with FrontPage® 2002. For this reason, the File Upload component is not supported in a lightweight server environment.

By configuring the FrontPage Server Extensions to use lightweight server support, large WPPs can scale the FrontPage Server Extensions to meet the demands of a high-volume, highly customized environment. Implementing the FrontPage Server Extensions' lightweight server support affects the way you:

• Set up FrontPage Server Extensions

• Set up users

• Modify CGI variables

• Handle requests to the server

A sample implementation of lightweight server support is available for download from the Web Presence Providers for Microsoft FrontPage Web site. The download includes sample code, along with a text file containing information about setting up and using the sample implementation.

Setting up FrontPage Server Extensions

The procedure for setting up the FrontPage Server Extensions for lightweight server support depends on the platform of your Web server.

Enabling lightweight server support for UNIX

If you are running a Web server based on UNIX, follow these steps to enable lightweight server support for UNIX:

Install the FrontPage Server Extensions, creating the /usr/local/frontpage/version5.0 directory and a single _vti_bin directory for all of the Web sites to share. For UNIX, use the /usr/local/frongpage/version5.0/_vti_bin directory which is installed with the FrontPage extensions.

Create the file /usr/local/frontpage/version5.0/enablelws.txt, owned by root. The presence of this file indicates to the FrontPage Server Extensions that lightweight server support is enabled on this computer.

If you have one FrontPage-extended Web site per user, all on the same virtual server (such as https://www.largewpp.com/community1/user2), update the _vti_inf.html file in the root directory by adding FPNoRootWeb=" n ", where n is the level of each user's content directory. For example, for User2, at https://www.largewpp.com/community1/user2, you would set FPNoRootWeb="2".

If each of your customers has his or her own virtual server, do not set FPNoRootWeb.

Enabling lightweight server support for Windows

If you are running a Web server based on Microsoft Windows®, follow these steps to enable lightweight server support:

Install the FrontPage Server Extensions, creating the \Program Files\Common Files\Microsoft Shared\Web Server Extensions\50 folder and a single _vti_bin subfolder.

In the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\5.0, create a value with the name LWSFilterDll and a string value set to the path of your custom DLL. This DLL should have an entry point with the following signature:

BOOL __cdecl FPIsLWSEnabled( LPEXTENSION_CONTROL_BLOCK pecb);

FrontPage calls this routine for each server request to determine whether lightweight server support is active for that request. So, for example, if all of your FrontPage-extended Web sites use lightweight server support, this routine always returns TRUE, and FrontPage Server Extensions run in lightweight server mode for all of your FrontPage users.

Caution   Be sure that the FPIsLWSEnabled function only returns TRUE for servers that are lightweight server-enabled (in other words, where the ISAPI filter is setting the appropriate HTTP_FRONTPAGE_LWS_* variables). If the function returns TRUE for a particular server, and these variables are not set, there is a potential security hole.

If you have one FrontPage-extended Web site per user, all on the same virtual server (such as https://www.largewpp.com/community1/user2), update the _vti_inf.html file in the root directory by adding FPNoRootWeb=" n ", where n is the level of each user's content directory. For example, for User2, at https://www.largewpp.com/community1/user2, you would set FPNoRootWeb="2".

If each of your customers has his or her own virtual server, do not set FPNoRootWeb.

The FrontPage Server Extensions cannot use Microsoft Index Server when they are running in lightweight server mode. Therefore, if your IIS Web server is running Index Server, set the configuration variable NoIndexServer=1 in the registry. For more information about this configuration variable, see Command-line Properties.

Using lightweight server mode with Office XP Web Folders

The Office XP features that allow using Network Places and Web Folders with FrontPage-extended Web sites rely on IIS to register FrontPage 2002 Server Extensions on the server computer. When you are in lightweight server mode, IIS does not recognize your Web sites as FrontPage-extended Web sites automatically. In order to use Network Places and Web Folders with lightweight server support, you must run a script to tell IIS that you are running in lightweight server mode.

To register your lightweight server with IIS, run the following script from the command line:

c:\inetpub\adminscripts\adsutil.vbs set w3svc/1/root/FrontPageWeb 1

After you have run the script, you must stop and restart IIS before it can take effect. You can stop and restart IIS from the command line by using the following syntax:

net stop iisadmin /y, net start w3svc

About FPNoRootWeb

You use FPNoRootWeb when you do not want FrontPage to manage a root web on your server. The reasons for not having a root web are:

• The list of subwebs for that root web can become so large that it significantly slows down all FrontPage operations against the root web.

• You may want to manage the root web (often your organization's home page) separately from any subwebs for security reasons.

When a client does not know which web contains a particular URL (in other words, FrontPage does not have a current web), it sends a "url to web url" Remote Procedure Call (RPC) command to the server. The "url to web url" RPC is often sent before any other calls are sent, and then the URL that is returned is used for subsequent RPCs.

The "url to web url" RPC is usually sent to the /_vti_bin/shtml.dll in the root web of the server. By setting FPNoRootWeb, however, you can change this behavior. For example, setting FPNoRootWeb="1" tells the client to send this request only to the webs one level down from the root. So, for the URL https://server/subweb rather than sending the request to https://server/_vti_bin/shtml.dll, the request is sent to https://server/subweb/_vti_bin/shtml.dll. After the client knows which web or subweb a file or folder is in, it sends subsequent RPCs for that file or folder to the scripts in that web or subweb.

Note that you must be sure that the _vti_pvt directory for each web or subweb can be read by the world in order for the "url to web url" RPC to work correctly. The files within the directory do not need to be world-readable, only the directory itself. Nor do the pages and user-created subfolders in the web need to be world-readable, although in many cases they will be.

For example, https://server/subweb/_vti_pvt must be readable by the Everyone group in Windows NT®, or world readable (------r--) on UNIX. This is because the RPC determines whether a folder is a web or subweb by checking for the _vti_pvt/services.cnf file. If the _vti_pvt directory for the web or subweb is not readable, the RPC cannot see the services.cnf file, and the RPC may return the wrong web or subweb.

Setting up users

If you have custom code that automates the process of setting up new users, you should add code that sets up users to use the FrontPage Server Extensions. For each FrontPage user, create the following under the root directory of the user's web:

• Services.cnf file, with a forward slash (/) as its contents, in the directory _vti_pvt

• _vti_cnf directory

• _vti_txt directory (for full-text search index)

• _private directory (for storing private author data, such as form results data from the runtime components in FrontPage 2002. This directory should not allow browsing).

For example, on a UNIX server, an account for User1 contains the following:

/users/u/user1_root/_vti_pvt/services.cnf

/users/u/user1_root/_vti_cnf

/users/u/user1_root/_vti_txt

You must also create a /users/u/_vti_pvt directory when FPNoRootWeb is set.

Note   If you are using the FrontPage Apache patch support (apache_fp), the root directory for the FrontPage web and _vti_pvt must be owned by the same user and group. Also, the User ID and the Group ID must be within the range specified by mod_frontpage.c (which means that they must not be system IDs).

Your server code must use custom environment variables to allow the FrontPage Server Extensions to map server requests to the proper user directories.

Modifying CGI variables

The FrontPage Server Extensions will check for environment variables to work with your custom server. You can customize your server to handle the environment variables that FrontPage Server Extensions are checking for. To customize your server, you must modify and recompile server code, create a custom Apache module, or create an ISAPI filter. See your Web server's documentation for information about modifying variables.

FrontPage Server Extensions use some standard CGI variables, as well as a few custom variables, which you must add.

Standard CGI Variables

FrontPage Server Extensions use the following standard CGI variables:

• SERVER_NAME

  Determines the URL of the site being managed with FrontPage. Used during link management and when setting the base URL in pages that are generated by browse-time FrontPage components.

• SERVER_PORT

  Determines the URL of the site being managed with FrontPage. Used during link management and when setting the base URL in pages that are generated by browse-time FrontPage components.

• SCRIPT_NAME

  Determines the subweb associated with the current request, such as /user1/_vti_bin/shtml.exe, or for a FrontPage 2000 nested subweb, /user1/service/_vti_bin/shtml.exe.

• PATH_INFO

  Identifies the extra information in a URL after the CGI script. Used by FrontPage browse-time FrontPage components.

• PATH_TRANSLATED

  Indicates a mapped version of PATH_INFO, taking the custom directory mapping algorithm into account. For example, if https://www.largewpp.com/user1/\_vti\_bin/shtmlexe/user1/test.htm is stored in c:\users\u\s\user1, then PATH_INFO is /user1/test.htm, and PATH_TRANSLATED should be set to c:\users\u\s\user1\test.htm.

Customizing environment variables for UNIX

In addition to the standard CGI variables, you must add the following FrontPage-specific variables on a UNIX platform:

• FRONTPAGE_LWS_PATH (required)

  Indicates to the FrontPage Server Extensions that they are being invoked in a lightweight server environment. The FrontPage Server Extensions will not check for FrontPage-specific server configuration information; nor will they check for server-specific configuration information, such as httpd.conf or the IIS metabase.

  The FrontPage Server Extensions require that the full, translated file system path must end with the same path as the URI. For example, https://www.largewpp.com/user1/*filename*.htm should be mapped to a file system path ending with user1/filename.htm, such as c:\u\s\user1\filename.htm. The FRONTPAGE_LWS_PATH variable should then be set to the file system path minus the URI. So in the example above, it would be set to c:\users\u\s.

• FRONTPAGE_LWS_SSL_PORT (optional)

  Identifies the other port on a SSL server. For example, if an authoring request comes in on port 443, FRONTPAGE_LWS_SSL_PORT might be set to 80.

• FRONTPAGE_LWS_LANGUAGE (optional)

  Identifies the default language to use for error messages and generated pages. Corresponds to the FrontPage default language server setting.

Customizing environment variables for Windows

If your Web server is a Microsoft Internet Information Server, you must create an ISAPI filter that processes requests to the server. This ISAPI filter should set the following variables as described for UNIX, but you must add them to the HTTP headers. See the example implementation for details.

FRONTPAGE_LWS_PATH

FakePre-8693dbd02c314802b109080d63fb0a71-96ffefd8da984da89ed436ea1de8b6ac FakePre-d4ff749e7fd449cc843ade62e3da5ca4-cf50ae3081474503a151b522a75434df FakePre-4147df471a514787b12783b0b3342daf-2754b00cd4334bf8b2b0cbcf417b612f

In addition, you must create the following variables:

• FRONTPAGE_LWS_SCRIPT_NAME

  Overrides SCRIPT_NAME CGI variable for FrontPage Server Extension support.

• FRONTPAGE_LWS_PATH_TRANSLATE

  Overrides PATH_TRANSLATE CGI variable for FrontPage Server Extension support.

Handling requests to the server

Using the custom environment variables, you can implement support for FrontPage in your custom Web server code.

Your custom code must modify the Web server so that it intercepts all requests to */_vti_bin/* directory and does the following:

• Uses either the virtual server name (www.user1.com) or to the script name (/user1/_vti_bin/shtml.exe) to identify the target web.

• Validates requests:

  • Only web administrators can make requests to /_vti_bin/_vti_adm.

  • Only web authors and web administrators can make requests to /_vti_bin/_vti_aut.

  • Only web browsers, web authors, and web administrators can make requests to /_vti_bin.

• Invokes a single copy of the _vti_bin executables with the appropriate environment variable settings. These could be either the actual executables or, on UNIX, the setuid shims developed for the FrontPage Apache patch support (apache_fp).

  

  Note   For Apache, if you use the FrontPage executable (fpexe) to invoke _vti_bin executables, the current version must be patched so that it passes along the FRONTPAGE_LWS_* environment variables to the subprocess. The sample implementation of lightweight server support available for download from the Web Presence Providers for Microsoft FrontPage Web site includes a patched version of fpexe (fpexe.c) that you can use instead of the released version.

  

In addition, your custom code must intercept and disallow all requests (GETs and POSTs) to */_vti_* and */_pvt/* directories, except those to */_vti_bin/*. These directories contain files that are used only by the server extensions and should not be accessible to any browsers.

Note   Under the lightweight server configuration, FrontPage Server Extensions do not contribute any security functionality. In both configurations, the FrontPage Server Extensions rely on the Web server's authentication process. Therefore, your custom Web server code is responsible for setting the necessary restrictions to Web resources.

Upgrading from a previous lightweight implementation (Microsoft Windows platform)

By default on a Windows platform with one virtual server, when you upgrade from FrontPage 2000 Server Extensions to FrontPage 2002 Server Extensions, the default virtual server is extended with the full version of FrontPage 2002 Server Extensions. Even if you were running a lightweight server extensions implementation of FrontPage 2000 Server Extensions, the virtual server will still be upgraded to the full FrontPage 2002 Server Extensions. To get back to a lightweight implementation, you can remove FrontPage Server Extensions 2002 from the default virtual server (but not from the entire server), and then finish the process of enabling lightweight support.

To remove FrontPage 2002 Server Extensions from the default virtual server, run the following operation on the command line:

owsadm -o fulluninstall -p <port number>

After you unextend the default virtual server, you can continue with the process of enabling the lightweight server extensions as usual.

In addition, when you upgrade on the Windows platform, you must manually move the LWSFilterDLL folder from HKEY_LOCAL_MACHINE/Software/Microsoft/Shared Tools/Web Server Extensions/40 to HKEY_LOCAL_MACHINE /Software/Microsoft/Shared Tools/Web Server Extensions/50. This registry folder contains settings used by the lightweight server support and is not moved automatically during upgrade.

Analyzing Web site usage in lightweight server mode

When you are running FrontPage Server Extensions 2002 in lightweight server mode, you cannot analyze Web site usage.