Cannot Browse Sub Web if UNIX Root Web on Apache is Restricted
ID: Q214851
|
The information in this article applies to:
-
Microsoft FrontPage 2000 Server Extensions
-
Microsoft FrontPage 98 for Windows
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 <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>
- After adding the Satisfy Any directive, save the .htaccess
file.
- 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.
- 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.
STATUS
Microsoft has confirmed this to be a problem in the FrontPage 2000 Server Extensions.
Additional query words:
front page
Keywords : fpse2000
Version : WINDOWS:; winnt:
Platform : WINDOWS winnt
Issue type : kbbug