Microsoft KB Archive/214851

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

Article ID: 214851

Article Last Modified on 2/22/2007

-

APPLIES TO


 * Microsoft FrontPage 2000 Server Extensions
 * Microsoft FrontPage 98 Standard Edition

-



This article was previously published under Q214851



SYMPTOMS
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.



CAUSE
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.



WORKAROUND
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:

 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. Note there is no directive, Require Valid User. If you see Require Valid User, you have opened the .htaccess for the wrong Web. In the  section of the .htaccess file, add the directive Satisfy Any. Make your  section look like the following:



Order deny,allow

Deny from all

Allow from all

Satisfy Any



 After adding the Satisfy Any directive, save the .htaccess file.</li> 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.</li> 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.</li></ol>

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.

<div class="status_section">

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

Additional query words: front page

Keywords: kbbug kbpending KB214851

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.