As described above, certain .htaccess files can be modified to allow the insertion of RewriteEngine code for www to non-www redirection. I've now tested the configuration with the following cpanel features, and they all work without corrupting the FPE's. By the end of testing, they were all enabled simultaneously:
Index Manager
Redirects
MIME Types
Hotlink Protection
IP Deny
However, in the course of testing, it became evident that there are flaws in how
cpanel manages the .htaccess file. These are not FrontPage's fault.
Cpanel is apparently not a component of Linux or Apache. It is an independent module that attempts to provide a user friendly interface to the features of your server. It tries to take options you select and translate them to the corresponding code of the underlying system. But like almost any user friendly automated code generator, its features are 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 certain circumstances. Then, if its method of modifying htaccess consists of inserting at a random location a block of cookie-cutter code, without regard for other code in htaccess that might modify or conflict with the block being inserted, which also appears to occur, 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.
Experiments done and the results:
Index ManagerTurning 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.
Options -Indexes
would do the job, without the side effects.
MIME TypesI set up a MIME type for Windows wma files. Cpanel inserted this code. No FPE problems:
AddType audio/x-ms-wma wma
Hotlink ProtectionEnabling 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. If you have other Rewrite blocks, it will cause problems.
If you have any 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, and the default entries that it shows for sites from which to allow access and for allowed/disallowed file types are taken from all the Rewrite lines that it finds, whether or not they have anything to do with hotlink protection! And the values it extracts from those lines are totally wrong. They will not accomplish Hotlink Protection at all. In other words, this is not a bug of the FrontPage Extensions, but of cpanel. It is unable to distinguish between RewriteEngine lines that relate to hotlink protection and ones that are there for other purposes. This can make a mess of your htaccess file.
RedirectsThis code was inserted:
RedirectMatch temp ^/dummy2.htm$ http://mydomain.com/dummy1.htm
Note how the redirect avoids using the RewriteEngine. This may be evidence that RewriteEngine is reserved for the use of Hotlink Protection, and no other cpanel feature is allowed to use it. But the redirect works and is correctly only applied when people access your site from the web. That is, if you request the redirected page from within FrontPage, you get the file you asked for, not the other one!
IP DenyI set it up to deny my own IP address. (It blocked browser access, but cpanel access was still allowed.) IPDeny made more changes to htaccess than any other feature, including ones to the default FrontPage deny,allow sections. It changed this (default FrontPage):
<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>
Presumably this part allows showing the Forbidden page, even to the denied party:
<Files 403.shtml>
order allow,deny
allow from all
</Files>
This does the denial.
deny from xxx.255.193.45
Unsure how significant the changes are. It might be that the default settings do basically nothing, allowing access to everyone. But before using this, I'd study it more carefully to make sure site security isn't compromised. Removing the IP Deny did not restore the modified htaccess sections to their previous default state.
----------------
As an example of something you can do manually that cpanel cannot do, these two sections happily co-exist. The first block correctly redirects www to non-www, then the second prohibits the hotlink:
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]
--------------------
To all, please point out any errors in the above so they can be corrected.
