How to use Apache .htaccess and mod_rewrite with the Microsoft FrontPage Extensions

People who publish their websites with Microsoft FrontPage to a Linux/Apache server often discover quickly that if they modify their site's .htaccess file, it corrupts their FrontPage Extensions and makes it impossible for them to publish their site. The fix is usually to reinstall the FrontPage Extensions, which has the undesirable side effect of erasing some of the files on the site. In a worst case, you might have to republish the entire site. After this has happened a couple of times, many people decide that they can't use .htaccess if they publish with FrontPage. But you can!

1. Minor modifications make the FrontPage Extensions compatible with .htaccess, even the dreaded mod_rewrite.
2. It is sometimes possible to uncorrupt your FrontPage extensions without reinstalling them.

I did some experiments to answer these questions:

Is there a security feature of FrontPage Extensions that checks whether .htaccess has been edited and freezes the site if it has?

That is, do the FrontPage Extensions use any tampering detection methods on .htaccess such as checksum verification, timestamp checking, or a hidden or encrypted shadow file that must always match?

The answer to all is no.

I was able to do all of the following without corrupting the FrontPage Extensions:

1. Edited .htaccess directly from within cPanel > File Manager, inserting carriage returns and whitespace.
2. Copied all the text from .htaccess, pasted it into Notepad, changed LF line ends to CRLF, inserted blank lines, pasted the text back into .htaccess on my server, and saved it.
3. Added some code (not mod_rewrite code) at the end of .htaccess.
4. After intentionally corrupting my FrontPage Extensions (by inserting mod_rewrite code), I took the text from my previously known good .htaccess file, pasted it back into .htaccess, and restored full FrontPage access to my site. That is, I was able to uncorrupt the FrontPage Extensions.

None of these actions corrupted the FrontPage Extensions, so it is only the settings in the .htaccess file's content that corrupt the FrontPage Extensions. It is not the act of tampering with the file itself.

Can you modify your server's configuration so you can use the FrontPage Extensions and still have full use of .htaccess, including mod_rewrite?

Yes. Here's how:

Using cPanel > File Manager, navigate to each of the following three files and edit each one using the Edit File link in the upper right corner of the File Manager screen. If you decide not to save the file, just close the browser window. The file is not saved unless you click the Save button.

1. /public_html/_vti_bin/.htaccess
2. /public_html/_vti_bin/_vti_adm/.htaccess
3. /public_html/_vti_bin/_vti_aut/.htaccess

At the TOP of each file there is a line

Options None

that was put there when the FrontPage Extensions were installed. Do not delete or modify that line. It gives this folder a secure starting point by turning OFF any insecure options that are enabled in folders above it. It is most likely this line that prevents you from publishing successfully with FrontPage, but if you remove it, you damage your site security. You must be more specific:

The only edit you make is, at the very BOTTOM of each file add the following on its own line:

Options +SymLinksIfOwnerMatch

Then Save the file.

Do this for each of the three files.

You do not have to make any modifications to the top-level .htaccess file in your public_html folder.

If you ever have to uninstall and reinstall your FrontPage Extensions, you must apply these mods again because reinstalling the FPE creates all new .htaccess files. You'll find your old .htaccess files archived with names that have 10 digits appended, like this:

.htaccess.0123456789

These files are only archived backups. You might find them useful for reference if at a later date you need to see the .htaccess code you used previously, but these files otherwise have no function and can be deleted.

Alternate method

There is another .htaccess line that will achieve the same purpose as the one above:

Options +FollowSymLinks

I chose not to use that because from browsing through the Apache documentation, it appears to be less secure. SymLinksIfOwnerMatch also allows following SymLinks, but it applies an additional security test. It creates a small amount of additional server overhead, but only when this folder is being accessed, which is when you are publishing, which is not often.

I can't say I understand thoroughly the implications of the differences between FollowSymLinks and SymLinksIfOwnerMatch. If you are the only person who publishes to your site, then it looks like SymLinksIfOwnerMatch should work for you. But if there are multiple people who publish to your site, using different user names, and if the use of SymLinksIfOwnerMatch freezes them out, then FollowSymLinks would be the next thing to try.

Test results

I've tested the configuration described above with the following cPanel features, and they all work without corrupting the FrontPage Extensions. By the end of testing, they were all enabled simultaneously:

• Index Manager
• Redirects (RewriteEngine, RewriteCond, RewriteRule)
• MIME Types
• Hotlink Protection
• DenyIP
• Apache-level (rather than FrontPage subdomain level) folder password protection

But cPanel can't be fully trusted to manage .htaccess

In the course of testing, it became evident that there are some flaws in how cPanel manages the .htaccess file.

cPanel is not a component of Linux or Apache. It is an independent module that provides a user friendly interface to Apache features. It takes options you select and translates them to .htaccess code. But like almost any automated code generator, its features are somewhat crude and error-prone compared to what you can accomplish if you work with the underlying system directly.

In order to work properly, cPanel has to correctly parse (interpret) the existing contents of .htaccess, which it seems unable to do in some circumstances. Then, if its method of modifying .htaccess consists of inserting a block of cookie-cutter code, without regard for other code in .htaccess that might modify or conflict with the block being inserted, then it's no wonder that .htaccess can end up in disarray.

Therefore, cPanel should not be completely trusted with management of your .htaccess files, whether you use FrontPage or not. It is much more advisable, in all cases, to determine the correct code to achieve a desired objective, and insert it into your .htaccess manually. You can still use cPanel to generate the code, but you should look at what it did and decide whether it's correct.

Examples of how cPanel inserted code. Some had errors.

Index Manager

Turning off indexes for the public_html folder inserted this code into .htaccess:

Options All -Indexes

This is more meddlesome than is required. The "All" enables FollowSymlinks and some other less secure features. This would do the job, without the side effects.

Options -Indexes

MIME Types

I set up a MIME type for Windows wma files. cPanel inserted this code:

AddType audio/x-ms-wma wma

Hotlink Protection

Enabling the default Hotlink Protection caused cPanel to insert this code. The first RewriteCond line allows direct access (such as from a browser or media player). Omit the line if you don't want to allow direct access.

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://mydomain.com/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://mydomain.com$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.mydomain.com/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.mydomain.com$ [NC]
RewriteRule .*\.(jpg|jpeg|gif|png|bmp)$ http://mydomain.com/bandwidththief.htm [R,NC]

The last line above should have an L in it [R,NC,L]. This is a cPanel error. As long as this is the only block of Rewrite code in your site (which is what cPanel expects), it won't cause problems, but if you have other Rewrite blocks, it will cause problems. This is because cPanel appears to reserve the RewriteEngine for Hotlink Protection only!

1. If you have preexisting Rewrite blocks in your .htaccess, then when you go to cPanel Hotlink Protection, it shows Hotlink Protection as enabled, even though it's really not.
2. The entries that it shows for sites from which to allow access and for allowed and disallowed file types are taken from all the Rewrite lines that it finds, whether or not they have anything to do with Hotlink Protection!
3. The values it extracts from those lines are totally wrong. They will not accomplish Hotlink Protection at all.

In other words, cPanel is unable to distinguish between RewriteEngine lines that relate to Hotlink Protection and ones that you put there for other purposes. This could make a mess of your .htaccess file.

Redirects

This code was inserted:

RedirectMatch temp ^/dummy2.htm$ http://mydomain.com/dummy1.htm

Note how the redirect avoids using the RewriteEngine. This is evidence that RewriteEngine is reserved for the use of Hotlink Protection only. But the redirect does work.

IP Deny

I set it up to deny my own IP address. (It blocked browser access, but cPanel access was of course still allowed.) IP Deny made more changes to .htaccess than any other feature, including ones to the default FrontPage deny,allow sections. It changed this (default created by the FrontPage Extensions):

<Limit GET POST>
order deny,allow
deny from all
allow from all
</Limit>

To this:

<Limit GET POST>
#The next line modified by DenyIP
order allow,deny
#The next line modified by DenyIP
#deny from all
allow from all
</Limit>

This part allows showing the Forbidden page, even to the denied party:

<Files 403.shtml>
order allow,deny
allow from all
</Files>

This line does the denial.

deny from aaa.bbb.193.45

Removing the IP Deny using cPanel did not restore the modified .htaccess sections to their previous default state, but it makes no difference. The default FrontPage "order deny,allow" lines allow anyone to GET or POST, and no one to PUT or DELETE. The changes that DenyIP made don't change that, but it has to change the order in which it's done so it can apply the deny line globally.

A concise reference on how to interpret the Order, Allow, and Deny directives is at http://httpd.apache.org/docs/1.3/mod/mod_access.html. In the case where two or more rules conflict, my understanding is that the rule farther down in the .htaccess file overrides the earlier one.

Other points:

When you copy your server's .htaccess file lines for external use or editing, you must do it using cPanel File Manager's Edit File mode, not Show File. When you use Show File, critical tags that are in the file don't show, and the lines you copy, missing those tags, will be worse than useless.

When experimenting with .htaccess, be sure to save the text from your known-good .htaccess file before you start, so you can paste it back if the experiment fails.

As an example of something you can do manually that cPanel cannot do, these two sections happily co-exist. The first block redirects www to non-www. The second prohibits hotlinking:

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^(.*)$ http://mydomain.com/$1 [R=301,L]

RewriteCond %{HTTP_REFERER} !^http://mydomain.com/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://mydomain.com$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.mydomain.com/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://www.mydomain.com$ [NC]
RewriteRule .*\.(jpg|jpeg|gif|png|bmp)$ http://mydomain.com/bandwidththief.htm [R,NC,L]

Questions are welcome in the discussion forum.