FAQ Policies
FAQ : Restricting web access


Restricting Access to Web Pages

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

General Notes

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 a 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.

The following snippet can be put in your .htaccess file to force access to go through an encrypted connection:


<IfModule !mod_ssl.c>
RedirectMatch /(.*)$ https://www.cse.unsw.edu.au/$1
</IfModule>





Observe the https in the redirect.

(Note: if you are using a Personal Domain or CGI Scripts with a password, you will need to change www to username.web or cgi respectively).

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>





These say "if the ssl module isn't enabled, redirect the browser to the https site". The other part makes sure it won't ask for a password to get 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 ...

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
  • Subject: @COMP1234
  • Subject teachers (not students): @COMP1234_Teacher


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)).

Unipass

You shouldn't need unipass authentication. Don't do this unless you know what you're doing (and are a member of staff).

Unipass authentication uses a radius server and a customised radius module:


AuthName "UniPass Restricted area"
AuthType basic

# stuff to turn on UniPass authentication
AuthUseUnipass On







Then you can use require user z1234567 s9876543 to list specific users.

The examples below include a combined CSE/UniPass example, which requires a little bit more special handling.

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 specific UniPass users

This sample needs to turn off "authoritative" sources, since we use more than one authentication method.




<IfModule mod_ssl.c>
AuthName "CSE and Unipass Authentication Example"
AuthType basic

# stuff to turn on UniPass authentication
AuthRadiusAuthoritative Off
AuthUseUnipass On

# stuff to turn on YP authentication
AuthYP on
AuthYPAuthoritative Off
SSLRequireSSL
require group @User # ie, anyone with a valid CSE account
require user s1234567 s2345678 # list of valid UniPass usernames
</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
  • We use a userfile instead of YP 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>














See Also

Tags for this article: authorised htaccess https restricting security web