Restricting Access to Web Pages
If you have content in your webspace that you want to restrict to specifc users or groups, you can use a .htaccess file to control access.
You can (and should) also ensure people use HTTPS connections, for better security.
There are several ways of securing your page - read the examples section to see some more complete examples that put everything together.
Creating a .htaccess file
Directives for controlling access should be put in a file called .htaccess inside the directory you want to protect.
Note that .htaccess directives don't affect parent directories - place them at the highest level you want them to control.
The file needs to be readable by the w3serv user; in most cases, this means making the file world-readable (eg. mode 644).
The directory it lives in, and all its parents up to your home directory, also need to be executable-by-others, (eg. mode 0711 or better.)
If the web server can't read the .htaccess file, it will deny access to the entire directory and any subdirectories below it.
Controlling access to specific files
By default, a .htaccess file is applied to the whole directory it lives in, and all sub-directories.
To limit restrictions to a specific file, put them inside a <Files> directive.
For example, if you only want to restrict access to a "secure.html" page:
<Files "secure.html"> # ... entries restricting access ... </Files>
These days, virtually all web pages should use encrypted connections unless there's a specific reason not to.
This is especially true for password-protected pages - even for trivial pages, you should make sure that passwords are never transmitted in cleartext.
To require HTTPS for a directory, put the following snippet in your .htaccess file:
<IfModule !mod_ssl.c> RedirectPermanent / https://www.cse.unsw.edu.au/ </IfModule> <IfModule mod_ssl.c> # all other directives go in this section </IfModule>
If the page isn't being accessed over HTTPS, it will redirect the browser to the HTTPS version of the site.
If you're using a Personal Domain or CGI Scripts, you will need to change www to username.web or cgi respectively.
It's important that you put any other directives inside the second IfModule section, to ensure that all authentication happens over HTTPS.
There are two main ways of implementing password protection: with your own manually-maintained password file, or using CSE account authentication.
Using a password file
The simplest form of password-based access control is to list usernames and encrypted passwords in a file. Typically, this file is called .htpasswd.
For this example, assume that you're restricting the secure directory, so you're working inside /web/username/secure/:
$ cd /web/username/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: 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.
Add this to .htaccess (within the <IfModule mod_ssl.c> section)
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 access to specific users in the file by using require user username1 username2 ... instead of require valid-user.
Using zID and zPass
Alternatively, you can authenticate users with their zID and zPass:
AuthName "Restricted to CSE Users" AuthType Basic AuthYP On require valid-user
This will grant access to any valid CSE user.
To restrict access to specific users, use require user user1 user2 user3 ...
Note that users need to have an account at CSE as well as a working zID.
Accounts, classes and (net)groups
At CSE, the computer system organises users' accounts into a hierarchy of what we call account classes. The accounts for people in the course COMP1234 are in the account class COMP1234. They are also in sub-classes depending on the role of the account (or the person who owns the account). Students of the course are in COMP1234_Student and lecturers are in COMP1234_Lecturer. Different account classes grant access to different resources in the CSE computer system. You can use these classes to control access to your web pages.
The account classes work as Netgroups when the CSE computer system checks for access.
To restrict to users in given account class, say COMP1234, put this in the .htaccess file:
require group @COMP1234
This will allow all teachers and students of COMP1234 in the current session
Some frequently-used classes include:
- Staff and equivalent: @Employee @Visitor
- Course: @COMP1234
- Course teachers (not students): @COMP1234_Teacher
Case Sensitive class name
The class name is case-sensitive in the .htaccess file. This example does not have a valid class name and will deny all access to the webpage:
require group @Comp1234
However, in other contexts, class or netgroup lookups are not case-sensitive which may confuse people.
The correct capitalisation for the class name, will be returned by the acc command:
acc type=class Comp1234
Name : COMP1234
Only use the primary class name with correct capitalisation in your .htaccess file.
Plain UNIX groups
If you want to restrict access to people in a specfic unix group, say csg, use:
require group @group.csg
Preventing filesystem access
Files in your webspace normally need to be world-readable so that the webserver can access them.
This means that any users on CSE systems will have access to the underlying files as well.
If you want to prevent this, you will need to lock down the file permissions, while still granting access to the webserver.
You can do this with the priv webonly command.This makes a directory group-owned by the webserver, so that only you and the webserver can get inside it through the normal unix filesystem.
$ priv webonly directory_name
For more complete information on how this works, run priv help webonly.
Note that this only applies to static content - PHP and CGI scripts only need to be user-readable, so you can simply chmod 600 secretfile.php and it will work the way you need it to.
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
Alternatively, you can restrict access by IP range:
order allow,deny allow from 129.94. allow from 149.171.
Restrict a directory to course students onlyThe 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 authenticationThis 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 scriptInteresting 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
- This uses a password file instead of zID authentication
<Files "secure.cgi"> <IfModule mod_ssl.c> AuthName "Restricted page" AuthType basic AuthUserFile /web/username/.htpasswd require valid-user </IfModule> <IfModule !mod_ssl.c> # no non-ssl access Redirect / https://cgi.cse.unsw.edu.au/ </IfModule> </Files>
- World Wide Web - WWW FAQs
- .htaccess files - use and configuration of .htaccess directives
- man htpasswd or man apache (on a linux machine)
- Apache Server Documentation Project (particularly the Apache 1.3 auth section).