Cannot Browse Sub Web if UNIX Root Web on Apache is Restricted

The FrontPage Server Extensions are configured on a UNIX server. You have configured the root Web or a sub Web to be restricted to Browse access. You then want sub Webs of the root or lower level nested sub Webs (in FrontPage 2000) to be configured with Browse access. You open the sub Web or lower level nested sub Web in FrontPage, and set Use Unique Permissions, and assign Browse access to Everyone. You find that the sub Web or lower level nested sub Web is also restricted to Browse access even though you set Browse access for Everyone.

If you look at the .htaccess in the content area of the parent Web that is restricted, you find that FrontPage adds the Require Valid User directive. Apache reads all of the directories in the path to the Web before presenting a requested file. In this case, it reads Require Valid User in the restricted Web and applies it to the unrestricted Web as well.

If the restricted root Web is at /usr/local/apache/htdocs, and the unrestricted Web is located at /usr/local/apache/htdocs/mysubweb, then Apache will read all of the .htaccess files in /usr/local/apache/htdocs first. When it does this, it finds the Require Valid User directive and, subsequently, applies this directive to /usr/local/apache/htdocs/mysubweb even though the .htaccess file for this Web does not have the Require Valid User directive.

There are two workarounds.

If the problem is occurring on a nested sub Web, the best option is to move the sub Web that you want to be restricted to a location in the root Web where there will be no nested sub Webs below it. For instance, if your restricted nested sub Web is sub Web1 at /usr/local/apache/htdocs/subweb1/subweb2, and is causing subweb2 to also be restricted, you could move subweb2 to a different location so that there are no lower level Webs to the restricted sub Web, subweb1.

If the problem is occurring on a sub Web that resides below a restricted root Web or a nested sub Web that resides below a restricted sub Web, you can use the following workaround. Modify the .htaccess files of the Web that has Browse access set to Everyone but which is currently restricted because a higher level Web is set to Only Registered Users have Browse access.

In the Web that is restricted, even though Browse access is set to Everyone, do the following:

1.	At a UNIX command prompt, open the .htaccess file that resides in the content area of the Web that is being affected by the restricted Web.
2.	Note there is no directive, Require Valid User. If you see Require Valid User, you have opened the .htaccess for the wrong Web.
3.	In the <Limit GET POST> section of the .htaccess file, add the directive Satisfy Any. Make your <Limit GET POST> section look like the following: <Limit GET POST> Order deny,allow Deny from all Allow from all Satisfy Any </Limit>
4.	After adding the Satisfy Any directive, save the .htaccess file.
5.	You should now be able to browse the Web, but there are still some additional steps if you have restricted Webs that reside under the Web that you just added the Satisfy Any directive to. For any Web that you have that resides below the Web with the Satisfy Any directive that you will need to set restricted access to, you will need to add the directive Satisfy All.
6.	Add the Satisfy All to the, <Limit GET POST> section as shown below: <Limit GET POST> Order deny,allow Deny from all Allow from all require valid-user Satisfy All </Limit> Adding this Satisfy All overrides the inherited Satisfy Any from the parent Web that was described above.

It is highly recommended that you test thoroughly to ensure that your Webs are all configured to require access in FrontPage after making the changes to the .htaccess files above.

Microsoft has confirmed that this is a problem in the FrontPage 2000 Server Extensions.