In order to specify your own customized error documents, you simply
need to add the following command,
on one line, within your
htaccess file:
ErrorDocument code /directory/filename.ext
or
ErrorDocument 404 /errors/notfound.html
This would cause any error code resulting in 404 to be forward to
yoursite.com/errors/notfound.html
Likewise with:
ErrorDocument 500 /errors/internalerror.html
You can name the pages anything you want (I'd recommend something that
would prevent you from forgetting what the page is being used for), and
you can place the error pages anywhere you want within your site, so long
as they are web-accessible (through a URL). The initial slash in the
directory location represents the root directory of your site, that being
where your default page for your first-level domain is located. I
typically prefer to keep them in a separate directory for maintenance
purposes and in order to better control spiders indexing them through a
ROBOTS.TXT file, but it is entirely up to you.
If you were to use an error document handler for each of the error
codes I mentioned, the htaccess file would look like the following (note
each command is on its own line):
ErrorDocument 400 /errors/badrequest.html
ErrorDocument 401 /errors/authreqd.html
ErrorDocument 403 /errors/forbid.html
ErrorDocument 404 /errors/notfound.html
ErrorDocument 500 /errors/serverr.html
You can specify a full URL rather than a virtual URL in the
ErrorDocument string (http://yoursite.com/errors/notfound.html vs.
/errors/notfound.html). But this is not the preferred method by the
server's happiness standards.
You can also specify HTML, believe it or not!
ErrorDocument 401 "<body bgcolor=#ffffff><h1>You have
to actually <b>BE</b> a <a href="#">member</A> to view
this page, Colonel!
The only time I use that HTML option is if I am feeling particularly
saucy, since you can have so much more control over the error pages when
used in conjunction with xSSI or CGI or both. Also note that the
ErrorDocument starts with a " just before the HTML starts, but does not
end with one...it shouldn't end with one and if you do use that option,
keep it that way. And again, that should all be on one line, no naughty
word wrapping!
For to password protect a directory and all the directories below.
Put a file named
.htaccess in the directory you want to password protect with the follow text.
AuthUserFile /opt/guide/www.widexl.com/.htpasswd
AuthType Basic
AuthName "Member Page"
require valid-user
For to password protect the admin.pl script.
You can use wildcards for this, like: "*.html" "*.zip"
<files "admin.pl">
AuthUserFile /opt/guide/www.widexl.com/.htpasswd
AuthType Basic
AuthName "Administrator script"
require valid-user
</files>
AuthUserFile: This is the full path to your
password file
AuthType: This need to be
Basic.
AuthName: This is the name (Realm) you want to give to your password protected site.
top
Auth Digest
MD5 Digest authentication provides a more secure password system than
Basic authentication, but only works with supporting browsers.
The only major browsers which support digest authentication are Internet
Explorer 5.0, Amaya and Konqueror from KDE2.
I don't think its save for Big Brother, but it's always more save than
Auth Basic.
And most users are using Internet Explorer 5.0 or higher.
Module:
mod_digest (old version)
Module:
mod_auth_digest (new version)
OS:
Unix, Linux, WinNT.
Don't use both modules on the same time.
Setting up MD5 Digest authentication is easy.
Put a file named
.htaccess in the directory you want to password protect with the follow text.
Example:
mod_digest
AuthDigestFile /opt/guide/www.widexl.com/.htpasswd
AuthType Digest
AuthName "Member Page"
require valid-user
Example:
mod_auth_digest
AuthDigestFile /opt/guide/www.widexl.com/.htpasswd
AuthType Digest
AuthName "Member Page"
AuthDigestDomain /member/ http://www.widexl.com/members/
AuthDigestNonceLifetime 300
require valid-user
Enabling SSI Via htaccess
Many people want to use SSI, but don't seem to have the ability to do so
with their current web host. You can change that with htaccess. A note of
caution first...definitely ask permission from your host before you do
this, it can be considered 'hacking' or violation of your host's TOS, so
be safe rather than sorry:
AddType text/html .shtml
AddHandler server-parsed .shtml
Options Indexes FollowSymLinks Includes
The first line tells the server that pages with a .shtml extension (for
Server parsed HTML) are valid. The second line adds a handler, the actual
SSI bit, in all files named .shtml. This tells the server that any file
named .shtml should be parsed for server side commands. The last line is
just techno-junk that you should throw in there.
And that's it, you should have SSI enabled. But wait...don't feel like
renaming all of your pages to .shtml in order to take advantage of this
neat little toy? Me either! Just add this line to the fragment above,
between the first and second lines:
AddHandler server-parsed .html
A note of caution on that one too, however. This will force the server
to parse every page named .html for SSI commands, even if they have no SSI
commands within them. If you are using SSI sparingly on your site, this is
going to give you more server drain than you can justify. SSI does slow
down a server because it does extra stuff before serving up a page,
although in human terms of speed, it is virtually transparent. Some people
also prefer to allow SSI in html pages so as to avoid letting anyone who
looks at the page extension to know that they are using SSI in order to
prevent the server being compromised through SSI hacks, which is possible.
Either way, you now have the knowledge to use it either way.
If, however, you are going to keep SSI pages with the extension of
.shtml, and you want to use SSI on your Index pages, you need to add the
following line to your htaccess:
DirectoryIndex index.shtml index.html
