combining directives

directory viewing prevention, SSI and password protection

[wilt2brian]

I have 3 goals:
1) prevent users from viewing directory contents;
2) enable server side includes;
3) implement password protection for the root directory and all sub-directories EXCEPT FOR one sub-directory named "hold" which contains one file named "temp.html".

To accomplish goals #1 and #2, I can use the following code in an htaccess file at the root:
IndexIgnore *

AddType text/html .shtml
AddHandler server-parsed .html
AddHandler server-parsed .shtml
Options Indexes FollowSymLinks Includes

To accomplish goal #3, I can use the following code in an htaccess file at the root (along with a htpasswd file):
RedirectMatch ^/$ [mydomainname.com...]

AuthType Basic
AuthName "By Invitation Only"
AuthUserFile /hostcompany/users/myusername/htdocs/.htpasswd

<Files *>
Require valid-user
</Files>

PLUS the following code in an htaccess file in the folder named "hold" which contains one file named "temp.html":
Allow from all
Satisfy any

My problem is that I can't figure out how to accomplish ALL 3 GOALS at the same time. No matter how I combine the code, adding the anti-directory-indexing code and the server-side-include code to the password protection code always results a password prompt for any request of [mydomainname.com....]

Any suggestions?

Any assistance anyone might be willing to offer will be greatly appreciated. Before posting this, I searched the forums here, as well as apache.org's forums and numerous other sites. If something related to my problem has already been posted and I missed it, I do apologize. In any event, thanks for any insight anyone may offer.

[jdMorgan]

This isn't correct:

Options Indexes FollowSymLinks Includes

Specifying "Indexes" will allow directory imdexes to be viewed. Also, it is generally safer to use the "add" and "remove" syntax like this:

Options -Indexes +FollowSymLinks +Includes

AddHandler directives can be combined:

AddHandler server-parsed .html .shtml

It might be more appropriate to rewrite requests from example.com/ to example.com/hold/temp.html instead of redirecting. This would prevent the /hold/temp.html path from being exposed to the visitor.

RewriteEngine on
RewriteRule ^$ /hold/temp.html [L]

As to the password-protection itself, it is far easier if you structure your site so that the Web root directory is not password-protected, and then put resources which need protection into a protected-subdirectory filepath. This prevents unwanted side-effects and Web protocol violations such as presenting search engine spiders with an "Authentication required" response when they try to fetch your robots.txt file or your sitemap.xml file(s)... or requiring browsers to log in when they request a favicon.ico file, labels.rdf, or /w3c/p3p.xml file. All of these files are "usually and customarily" fetched with the initial page request, and should not require a login for access. You also don't want a login required for any user-agent to see a basic server error response from your custom error pages (if you use custom ErrorDocuments).

Jim

[wilt2brian]

Jim-

Thanks very much for your help. My root directory htaccess is now written:

AddType text/html .shtml
AddHandler server-parsed .html .shtml
Options -Indexes +FollowSymLinks +Includes
RewriteEngine on
RewriteRule ^$ /hold/temp.html [L]

I understand and agree with what you're saying about the password protection and site structure. In my first post I neglected to mention my reason for setting up the site with the root directory password protected and a sub-directory UNprotected rather than the other way around. The password protection was to be temporary (during development only). I was hoping to develop the site in the same (root) directory where it will ultimately reside, avoiding the need of moving the site once development was complete. During development I wanted users requesting example.com to be sent (using a redirect or rewrite) to a page NOT password protected. Then once development was complete, I would remove both the redirection/rewrite and the password protection. There is quite possibly a simpler way of accomplishing this, I'm just not sure what it is.

Once again, thanks for all your direction on the AddHandler, Options and Rewrite.

Brian

[jdMorgan]

It's often fairly easy to develop and test new stuff in a subdomain separate from your main site. I often use "dev.example.com" and "test.example.com" as development spaces, rewriting my own requests for those subdomains to directories and subdirectories on the server as needed, while allowing common objects like images to be 'shared' from the main domain.

My comment on the 'proper' way to do directory protection is based on how Apache was designed to support things, and not intended to chide you for 'doing it wrong'. It's just that many things in Apache are easy if you do it the way the Apache developers expected things to be done, but can be difficult or even impossible if you try to take a different approach.

Remember always that MIME-types, authentication and authorization, and many other functions are implemented based on directories and files, while other functions are based on URLs. Tis was intentional. These two location-spaces can be used independently, with mod_rewrite acting as a translator. So you can, for example, make a protected subdirectory appear to reside in the top-level directory when viewed as a URL by rewriting specific top-level URL requests to a protected subdirectory in the server filespace.

Many things become clear (and easier to do) if you always bear in mind that URLs are not filepaths, and filepaths are not URLs, and that they are only related by the default URL-to-filename translation function of the server. mod_alias and mod_rewrite allow you to make that translation arbitrary -- mapping URLs to directories and filenames (and even to other servers) in whatever way suits your needs.

Just some ideas...

Jim