So you have one or more web pages that you want to publish via the web but you don't want to make them available to everyone? A solution is to use the htaccess password mechanism that is part of the Apache Web Server. This Apache feature allows you to publish static web pages to validated users via a web browser prompt for a username and password.
For added security, you can force users to access your pages using an SSL (Secure Socket Layer) connection. This means transmitted data is encrypted, so passwords and webpages cannot be read in cleartext over the internet.
There are several ways of securing your page. You will put together all the different ones that you want to use. Read the examples section to see some more complete examples that put everything together.
Checklist
Check this when securing a directory
Have I got the required SSL for password-protected areas?
Scope of .htaccess file (how to limit specific files)
By default, a .htaccess file is applied to the directory it lives in, and all sub-directories. So you'll often just create the .htaccess in your public_html directory, or in a subdirectory.
To limit your restrictions to a specific file, put all of the directives inside a <Files> directive.
For example, you only want to restrict access to a "secure.html" page:
<Files "secure.html">
... entries restricting access ...
</Files>
To only restrict a subdirectory, put the .htaccess file inside it instead.
File Permissions
The web server needs to be able to read your .htaccess file. If one exists and the web server can't read it, then it will deny access to be on the safe side.
So, you should make all of your .htaccess files world readable:
$ chmod 644 .htaccess
The parent directory itself also needs to be accessible (executable):
$ chmod 711 parent_directory
HTTP access only (no filesystem access)
If you don't want people to access a directory through the normal UNIX filesystem, then you will need to use priv webonly.
This program makes a directory group-owned by the webserver, so that only you and the webserver can get inside it through the normal unix filesystem.
Usage:$ priv webonly directory_name
For more complete information on how this works, run priv help webonly.
An alternative to using priv webonly is to have a AlternativeCGI that does the authentication for you.
Password protection
You may wish for people to enter a password to view a page. Note that if you are using password protection, it is strongly encouraged that you force an encrypted connection.
Requiring an Encrypted Connection
To stop others from easily extracting your password from network traffic, you should always use encrypted connections for password-protected pages.
If those pages are served by CSE's main web server (Albeniz) or CSE's CGI servers then you can redirect unencrypted requests for pages to make encrypted requests instead.
The following snippet can be put in your .htaccess file:
<IfModule !mod_ssl.c>
RedirectPermanent / https://www.cse.unsw.edu.au/
</IfModule>
In plainer English this means if the ssl module isn't enabled, redirect the browser to the https site.
Observe the https in the redirect.
Then, you should put any other restrictions (the parts that require a password) inside the following:
<IfModule mod_ssl.c>
... parts requiring password go here ...
</IfModule>
The prior part makes sure it won't ask for a password before issuing the redirect (you don't want the user to be asked for a password twice).
Password-file based access (invent your own username and password)
The simplest form of password-based access control is to list usernames and encrypted passwords in a file. Typically, this file is called .htpasswd.
Lets assume that you're restricting the secure directory, so you're working inside /home/username/public_html/secure/:
$ cd /home/username/public_html/secure/
First, you need to create the password file, this doesn't have to be in the same directory, but often is…
We can do this using the htpasswd command (-c means create).
First we create a user called "bob".
$ htpasswd -c .htpasswd bob
New Password: (type password)
Re-type new password:
Adding password for user bob
Now the bob user is there. You can add other users the same way but without -c.
Next, you need to tell the web server to restrict access based on that file.
For portability, instead of using /home/username/public_html/ to refer to your web area, we use /web/username/, which is equivalent and will also work on the CGI servers.
Add this to the .htaccess file (remember that we were in the "secure" directory of your web area):
AuthUserFile /web/username/secure/.htpasswd
AuthName "Access to Private Web Pages"
AuthType Basic
require valid-user
This lets any user in the .htpasswd file get access.
You can limit to specific users by using require user username1 username2 ... instead of require valid-user.
CSE users
You can authenticate CSE users using YP.
Put this in your .htaccess to turn that on.
This way you won't need a password file.
AuthName "Restricted to CSE Users"
AuthType Basic
AuthYP On
I've also included the usual AuthName and AuthType for completeness.
If you want any CSE user, you can just use:
require valid-user.
Or for specific users:
require user user1 user2 user3 ...
Note that a zID and zPass should work, but only for users where they associate to a CSE account so "require valid-user" will be only CSE students and staff.
Specific groups (e.g. members of a certain course)
To restrict to users in a subject, say COMP1234, you refer to the netgroup (which means putting a @ in front):
require group @COMP1234
If you want to restrict access to people in a unix group, say csg, use:
require group csg
OR
require group @group.csg
Some frequently-used groups include:
Staff and equivalent: @Employee @Visitor @Conjoint
If your group does not work, it may be necessary for SS to add a netgroup priority to it.
You can check a netgroup priority by running acc .COMP1234 'format=${netgroup}' (note that the @ is replaced with a . (period)).
Note that group names are case sensitive so if the CSE group is "CSE_Group" then require group @cse_group will not work, it must be
require group @CSE_Group.
Host-based access
You can restrict based on the IP address or domain name that the user is coming from:
This will only allow people to access the page if their computer's domain name ends in .unsw.edu.au.
order allow,deny
allow from .unsw.edu.au
This is a similar example, but restricts it to the university by IP address:
order allow,deny
allow from 129.94.
allow from 149.171.
An Alternative Solution
There is an alternative to use a .htaccess file.
This is to use a special CGI script that effectively proxies access to your directory.
Then the secure directory can be owned by you and not accessible to anyone else (not even the webserver).
You can implement the authentication using a cookie, or form-based password, etc.
More information on writing CGI scripts can be found here.
Commonly Used Examples
This section has a few common examples. Feel free to suggest new examples to SS if you believe a particular one will be useful.
Restrict a directory to course students only
The complete .htaccess file for COMP1234 will look like:
# No non-SSL access
<IfModule !mod_ssl.c>
RedirectMatch /(.*)$ https://www.cse.unsw.edu.au/$1
</IfModule>
<IfModule mod_ssl.c>
AuthName "COMP1234 Students only"
AuthType basic
AuthYP on
require group @COMP1234
</IfModule>
Restrict access to any valid CSE user and associated zPass authentication
This sample needs to turn off "authoritative" sources, since we use more than one authentication method.
<IfModule mod_ssl.c>
AuthName "CSE and zPass Authentication Example"
AuthType basic
# stuff to turn on YP authentication
AuthYP on
AuthYPAuthoritative Off
SSLRequireSSL
require group @User # ie, anyone with a valid CSE account
</IfModule>
<IfModule !mod_ssl.c>
Redirect / https://www.cse.unsw.edu.au/
</IfModule>
Require a password on a CGI script
Interesting points here are:
A single file only is restricted (secure.cgi)
The SSL redirection is to cgi instead of www because it is a CGI script
