HTAccess

Any Virtual server user may setup a .htaccess file in their 'web/' directory and/or in any directory created within that 'server root' directory. The main reasons a user would want to set the .htaccess file up are:

1. Block access to certain files, except to certain domains (or completely).
2. Add an experimental or special mime-type
3. Password protect a private directory.

The .htaccess file is basically a on-the-fly addition to the main server configuration. It allows you to change some aspects of how the server operates on your files and directories. Note that some things have been blocked in order to keep security as high as possible. The .htaccess file is placed in the directory that it operates on. It changes the permissions/settings for the directory it is in and all sub-directories contained therein. You may put an .htaccess file in a subdirectory of a directory controlled by another .htaccess file and it will happily work. The .htaccess file in the parent directory's settings remain in effect unless overridden in the sub-directory's .htaccess file. This is confusing just to describe so it probably shouldn't be done until you are an expert.

DIRECTIVES YOU CAN ADD TO THE .htaccess FILE

• Allow
• Deny
• Order
• Require
• AddType
• AuthUserFile
• AuthGroupFile
• AuthType
• AuthName
• DefaultType
• ErrorDocument
• ForceType
• Options
• Satisfy
• <Files> </Files>

That seems like a lot but they are really very simple. Further discussion of each follows the examples:

EXAMPLES
Example 1. Deny a Domain Access to a Directory.

.htaccess contains:

Order Deny,Allow Deny from .thisbaddomain.com

Note that the Order directive makes sure that 'Deny's override Allows and not the other way. Also, 'Allow from all' is the assumed default from our master configuration.

Example 2. Deny a Set of Files to a Domain.

.htaccess contains:

<Files *.gif> Order Deny, Allow Deny from .thoseevilpeople.net </Files>

In this case only .gif files would be 'Deny'ed to anyone from .thoseevilpeople.net and only people from them. Since many people have more than one account (office/home) this is rarely used like this. It is more often used in 'Allow'ing ONLY one domain, like in the next example.
Also, the style of the Container Directives (<File> or <Limit>) is like HTML! Handy isn't it?

Example 3. Allow Only One Domain and One Country Access to a Set of Files.

.htaccess contains:

<Files barney*> Order Allow, Deny Deny from all Allow from .yahoo.com

Allow from .it </Files>

Note this example allows only people from 'yahoo.com's corporate office and people in Italy (.it) to view the files that begin with the letters 'barney'. This includes all sub-directories that contain files beginning with those letters and ALL the files in any directories that happen to begin with 'barney'. Also, notice that we made 'Allow's come before 'Deny's in the 'Order' so that the all DOESN'T mean ALL.

Example 4. Add a Special Mime-Type to a Directory.

.htaccess contains:

AddType image/x-photoshop PSD

This causes the server to announce *.psd files as Content-Type: image/x-photoshop when sending it to the browser. Hopefully the browser knows that image/x-photoshop means run PhotoShop and give it this file. Normally this is used with a new or being tested Plug-In that doesn't have an entry in our master file yet. If you need this on a permanent basis or think it might be useful to others please send us mail about it so we can add it in for everyone. Also, this will override current setting which makes 'AddType audio/x-dumbexample JPG' valid! You can change what jpg means in your directories.

Example 5.; Force All Files in a Directory to a Specific Mime-Type.

.htaccess contains:

ForceType image/jpg

The causes ALL files in the directory to be treated as JPEG files. No matter their extension. Note, can NOT be use in a <Files> </Files> tag!

Example 6. Password Protect a Directory - Simple Form.

.htaccess contains:

AuthName "Secret Directory Access" AuthType Basic   AuthPAM_Enabled off Require valid-user AuthUserFile /mnt/home/people/UNI/WEBHSV/userid/.nameoffile

.nameoffile contains:

user1:asdfasdfasdf2 user2:ergvdsdfef34f ...

'AuthName' causes the browser to display something like, "Enter username for Secret Directory Access at www.thedomain.com:"

'AuthType Basic' tells it to use the 'AuthUserFile' for authentication. (no other types are currently available.)

'AuthPAM_Enabled off' disables PAM authentication on the cobalt, if you do not use this it will auth out of the PAM system.

'Require valid-user' says to only allow a valid-user, you can also use 'Allow' and 'Deny' to stop certain domains. The .nameoffile contains simple text usernames followed by a ':' and then 13 characters that are the encrypted password for that user. These can be generated with a simple command on the shell line if /usr/bin/htpasswd.

Note that the file '.nameoffile' has a period in front of it and is NOT in the web directory. Putting your password file where it could be downloaded would be a VERY bad idea. It is possible to crack simple passwords (one word or name in all upper or lower case is crackable in seconds!) so it is recommended that you use good sense and pick tough passwords that contain a number, symbol and letter combination. The dot in front of the file simply hides the file from view during normal file listing on unix systems.

It isn't real security but it does mark the file as special when YOU list it. The permissions on the file should be 644. This means that it can be read/write for you and world readable (webserver). Those people who have a full webserver running under their own userid (ask about this since it only occurs when requested and only on some account types), may set the permissions to 600 and disallow anyone else on the system from reading the files as well.

ENTRIES ALLOWED IN .htaccess FILE

More complete documentation is available at http://www.apache.org/docs/ should you be interested, but keep in mind that we have limited the scope of the directives you can use considerably and that abuse of this privilege could result in the total curtailment of these features or even the cancellation of your account in extreme cases.)

Allow (all, [domain list])

ex. 'Allow from .xodiax.com or 'Allow from .xodiax.com .yahoo.com .aol.com' for a list of domains A list of domains to allow access to a directory (and its subdirs)

Deny (all, [domain list])

ex. 'Deny from All' A list of domains to deny access to a directory (and its subdirs)

Order (Allow,Deny or Deny,Allow)

Specifies which rule is considered first. Look at the examples for 'Allow' and 'Deny' and consider this... If Deny is considered before Allow then no one, not even people on the .xodiax.com (our office) network, may enter the site; but if Allow is the first rule then .xodiax.com domain IPs (Xodiax office in this case) would be admitted and no one else. ex Order Allow,Deny (always specify this [if you specify 'Allow' or 'Deny' anyway] since the default could be either way and change without notice.)

Require (user [user list], group [group list] valid-user)

ex. 'Require User john bob sam' The user must login with the specified names, be in the specified groups or in the case of Valid-User simply be authorized by the Auth* commands.

AddType (mime/type [extension list])

ex. 'AddType image/gif GIF GFF FIG' teaches the server the mime/type to send for a particular extension. In the case of the examples any file ending in .gif, .gff or .fig would be treated as a GIF file. Useful for adding a type we don't already have in our master mime-types file. [As mentioned above, if the mime-type is in any way becoming a standard, please let us know so we can save other patrons the trouble by adding it to our master list. noc@xodiax.com would be the best place to send such requests. Also, See DefaultType and ForceType]

AuthUserFile (filename)

ex 'AuthUserFile /home/sites/siteXX/.secret' The file to use as a password list created with any text editor or the htpasswd program. The FULL path to the file MUST be specified. The format of the file is simple, a userid followed by a colon (:) and then the crypt() generated password entry. You may use the htpasswd program to add them directly to the file.

AuthType (basic)

ex 'AuthType Basic' The type of authentication that uses the above 'AuthUserFile' and 'AuthGroupFile' commands is 'Basic'. We do not currently support other types of authentication in the master server. Contact your web representative if you wish to use alternate methods (for power/speed/compatibility with databases etc...)

AuthName ([text])

ex 'Secret Directory' The realm prompt string sent to users when they are given the login dialogue box. In Netscape you get a prompt like 'Enter username for Secret Directory Access at www.xodiax.com:' for the example above.

DefaultType (mime/type)

ex 'DefaultType text/html' for files that do not have an extension or have an unknown extension the server must make a guess as to what mime type to tell the browser it is sending. We default the Xodiax servers to text/plain so that we can spot extension typos easily. If you are prone to leaving the extensions off a certain type of file or don't want bad extensions to show as text you may set this to ANY mime/type you like. [See ForceType and AddType]

ErrorDocument (3-digit-code [filename or text or url])

ex 'ErrorDocument 401 /~userid/error401.html' You set up custom error responses! If they tried to get into a protected directory then one response can be sent, but if they tried to get to a page that doesn't exist then they get another page rather than the boring and very generalized error documents we provide. This can provide your site with a nice feel even in the event that an error occurs and also be set up to send people who tried and failed to get into a protected directory straight to the instructions on how to signup or get help if they forgot their password. [See the ErrorDocument Section Below since this is a complicated issue.]

ForceType (mime/type)

ex 'ForceType image/gif' Forces the mime type to tell the browser it is sending a particular type of file no matter what the extension actually is. This one is rarely used. [See DefaultType and AddType]

Options

These are disabled but by default these are on: Indexes Includes FollowSymLinks

Satisfy (any, all)

ex 'Satisfy All' If you have BOTH 'Allow' and 'Require' directives in a single directory the server needs to know if it is supposed to check all or if one out of two isn't bad. Useful if you need to password protect an area from the general public but people from a specific address group are allowed open access.

<Files> </Files>

Used to apply directives to only a select group of files. You could use this in conjunction with the 'Require' and 'Auth*' directives to password protect access to *.gif files only! Like in html files the directives enclose commands within the start and stop portions but in the .htaccess file should appear on their own lines. An example opening directive would be: '<Files *.gif>' that would be followed by a directive like 'Deny from .aol.com' and then by '</Files>' each on their own line. This would disallow sending any GIF files to anyone coming from AOL.

ERROR DOCUMENT HANDLING

• ErrorDocument 403 "This is a simple text message
• ErrorDocument 404 /~userid/oopsie.html
• ErrorDocument 401 /cgi-bin/figureitout4them.cgi
• ErrorDocument 402 http://www.somewhere.com/somepage.html

All these forms are allowed, but the trick is in knowing what error number is what! In the first example the double quote at the beginning ONLY is intentional. It signals the webserver that the following data is text and not a web site address.

If you want more info about these error codes you might try: http://www.w3.org/Protocols/Specs.html

We recommend that 403 warn them that the file/directory is unavailable to them for a reason.

We recommend that 401 should be a nice page telling your legitimate users how to get help from you with their password and tell snoopers how to get a legitimate password, or that the site is private and that all attempts are logged. If you don't have any protected directories, don't bother with this one. If you have multiple protected directories consider using multiple pages so that you can be more specific about the error.

We recommend that 404 should note that the file/directory doesn't exist and that if they reached the page in error from a link on your site to contact you at whatever email address you prefer, that if they reached the error from an outside link that they should contact the link maintainer about fixing the old link and that you ALWAYS place a nice link to your root homepage like http://www.whatever.com so that they can still enjoy the fruits of your labor.

If you send them to a cgi then the cgi variable HTTP_REFERER should contain the page they came from and REQUEST_URI the bad request they typed in. In a web page you can cause these variables to be printed by using:

<!--#echo var="REQUEST_URI" --> <!--#echo var="HTTP_REFERER" -->

Note that this works with any Environment variable that is set by a webserver. A few often used are:

• REMOTE_ADDR (the IP they are coming from)
• REMOTE_HOST (the DNS name of the IP they are coming from)
• REQUEST_URI (the web page they requested with the servername cut off)
• HTTP_REFERER (some browsers report the page you clicked on to get to this page. Of course, if you didn't click on a page to get here then it won't show anything.)
• HTTP_USER_AGENT (the web browser they use)

For these to work the execute bits must be set on the file or the file must be named with a .shtml extension.

It is important to remind you at this point that the settings carry down from directory to directory. If you set up authentication on a directory then ALL of it's subdirectories are authenticated unless you override it by specifically turning off authentication in another .htaccess file. If you use .htaccess files in multiple directories do keep in mind that they are cumulative in effect, so in a sub directory the server looks in all the parent directories and adds the files up. The most specific file overrides the more general so what you turn on in a parent directory can always be turned off in a subordinate.

Your .htaccess files can easily get kind of complicated if you start using lots of features so we recommend that you start small and work your way up, testing as you go. Hopefully, this page will be followed up someday by an experts page with real-life examples being used by our customers. There are also some other features, not discussed here, that we may describe and demonstrate for you in that future project. We encourage you to e-mail the noc here if you are particularly proud of some special use you've put this to.

If you need assistance our qualified staff are available to assist. Please contact our Network Operations center at (502) 315-6015 or email support@Peak10.com.