Module 5 Lecture Notes Part 2

635.482: Website Development

Overview of Web Servers

A web server is simply a program that runs as a daemon or a server on a host. A "daemon" process is a process
that tends to start when the system is booted, and continues to run until the system is shut down. A server is a
type of daemon that is passive in nature, and does nothing until it is requested to do something – it is an "event
driven" program. A web server handles a client request for service within the HTTP protocol. Usually, this means
the client will request a web page via HTTP, and the server will either serve up the page to the client, or return
some type of error.

There are many different web servers available. In fact, there may be dozens or even hundreds of web server
programs that can be used. However, the dominant web server in the internet today is Microsoft’s IIS web server.

One survey shows that IIS is running on about 36.8% of all active Internet web servers today.

1
Another survey shows that the open source Apache is used by 48% of all known web servers.

These surveys also singles out other web servers, including nginx, LiteSpeed, and Google. These five servers
make up between 86% and 88% of the market share or servers in use. Thus, there are many other servers that
are available on the Internet today.

This module will discuss the functionality of web servers. We will do this by looking at the Apache web server, and
look at what can be configured. I am not looking for you to be an expert on configuring web servers by the end of
this module – but I do want you to be able to describe what kind of things you can configure on a web server, and
what the functionality of that configuration is. You may want to try to download and run a web server on your
computer – that indeed might be useful in a future module that deals with server side processing.

You could try the Apache server, or you might find some other smaller, less functional web server that you could
easily install on your system. If you decide to try the Apache server, there is a stack that you can download which
will make your installation easier. This stack includes PHP, which we will be using in this class, as well as MySQL
and Perl. XAMPP is a nice option whether you are using Windows, Mac or Linux.

Apache Web Server Configuration Files

The main configuration file for Apache is a single file, usually called 'httpd.conf'. Where this file exists in a system
depends on how Apache is installed, and what type of operating system is being used. (Apache can run on many
different operating systems, including UNIX and various flavors of Windows.)

Configuration File description from the Apache web site.

Here is a partial example of the httpd.conf file:

2
 Modul

Directiv

Modul

Directiv

Modul

Server-wide Configurations
There are certain configurations which will apply system-wide. The link below describes these.

Server-wide configurations from the Apache web site

Some additional descriptions of some of the more important configuration parameters follow:

DocumentRoot – The directory from where all document requests start. This will be the directory looked at when
you only specify the host in the URL. A note about htdocs, you might also see www or public_html. Any of
these directory names are legitimate names for a public access folder. You can change your configuration file
(httpd.conf for Apache) to make this whatever you want.

UserDir – The name of the directory which is appended onto a user's home directory if a ~user request is
received. In our case the UserDir is set to htdocs. This configuration parameter is part of the "mod_userdir"
configuration module, which allows the server to use individual user directories. You can look at the
documentation for this here: http://httpd.apache.org/docs/current/mod/mod_userdir.html.

DirectoryIndex – This is the specification of the default file name that will be used if the last token in a URL refers
to a directory rather than to a specific HTML file. In our server, that configuration entry looks like:

DirectoryIndex index.html welcome.html index.htm index.shtml

AccessFileName: The name of the file to look for in each directory for access control information. This is set to
.htaccess, which is a typical default. See the module notes on "Restricting Access" for more information on this
file.

ScriptAlias: This controls which directories contain server scripts, particularly CGI scripts. These directories
follow the same alias rules as the Alias parameter. The web2.jhuep.com site restricts CGI (due to security
concerns), so individual student directories are not allowed to run CGI. However, instructors can place their CGI
scripts in a particular directory where CGI is allowed. We will use this when we discuss CGI later in the course.

3
Directives Applied to Only Specific Directories
Directives placed in the main configuration file outside of any other section apply to the entire server. You can
change the configuration for only a part of the server by placing the directives in <Directory>, <DirectoryMatch>,
<Files>, <FilesMatch>, <Location>, and <LocationMatch> sections. These sections limit the application of the
directives which they enclose to particular file system locations or URLs.

The <Directory> directive specifies which web users are able to access a particular directory, and the various
options that can be set for that directory. The specified directory must be a valid directory within the server.

The options (http://httpd.apache.org/docs/current/mod/core.html#options) directive will set up the various options

for pages within that directory and all sub-directories. The options that can be set are:

• Indexes: if this option is set and no index.htm file exists in a directory, a directory listing will be displayed
if not file is given in the URL
• Includes: this allows server-side includes to be activated (server side includes are pages or scripts that
include other scripts)
• IncludesNOEXEC: this allows server side includes but not execution of scripts in this directory (scripts in
other directories can be included, though)
• FollowSymLinks: this allows symbolic links to be followed (a symbolic link in Unix is like a shortcut or
alias in Windows, this option is not available in Apache for Windows)
• SymLinksIfOwnerMatch: this works just like the above option, except Apache will follow symbolic links
only when the target of the directory is owned by the user of the link (again, this option is not available in
Apache for Windows)
• MultiViews: this option allow will enable the server to substitute files like this: if a user requests a file
catalog.htm, and no file exists by that name, but a catalog.pl exists, the server will return catalog.pl
• ExecCGI: this allows cgi-bin applications to be executed

We can also use None or All as a shortcut. Note that the All option will not enable Multiviews, which must be
explicitly named.

Check out the Apache Documentation for details on these options.

The above settings are the most critical component of these configuration files. It is important that you know what
these settings mean in order to interpret existing configuration files. However, many other directives and options
are present, and you should spend some time at the Apache web site seeing what other capabilities exist.

Additional Resources

• Server Watch
• Apache HTTP server documentation

Restricting Access to Web Pages

In some cases, you may want to keep certain parts of your web site protected so only a certain group of users can
get access. For example, if you are teaching a class, and you post your grades, you likely will only want to allow
the student and the instructor (and perhaps your grader) to have access to those grades. The instructor may want
to only allow students who are currently taking her course to have access to her class notes. Some commercial
sites might provide "premium" content that will only be accessible to users who have paid a fee. And of course,
government sites containing sensitive data may require some form of authentication to allow users access to their
data. In this module, we will examine some forms of restricting access to pages within your web site.

4
Restricting Access on the NSCA Apache Web Servers

First of all, for the most part, the methods of restricting access to pages depend on the web server package that is
used. We will examine the method used by the most popular web server on the Internet today, the NSCA Apache
web server. Other servers will handle this issue in a similar manner.

In the NCSA Apache server, setting up restricted access requires two steps.

Step 1. The first step is to update the server configuration files. This must be done by the server administrator,
and the web server process must be restarted to have any such changes take effect. This update will tell the web
server to check for access control files in certain directory trees.

Step 2. The second step is to add access control files to directories to specify the details of how you want to
restrict access to files in these directories, and the web server will automatically check these files whenever
access is requested for any files within the specified directory trees.

Setting Up Access Controls in UNIX

Most of the web servers today run on some variant of the UNIX operating system. The following discussion will
focus on how to set up the access control mechanisms in the UNIX environment, but again, this discussion should
apply to non-UNIX environments as well. In fact, however, only a few commands in UNIX need to be used to set
this up.

On UNIX, the "ls" command lists files in a directory. To list all files, including "hidden" files (in UNIX, "hidden" files
are files that start with a "."), use the "-a" option of "ls". You might want to use the "-l" option as well, to get a long
format listing. So, to look at all the files in a directory, use "ls –la". You will need this to verify that you have
created the access restriction files.

Suppose you place your web files in a directory called "htdocs". Now, suppose the web server has enabled the
use of restricted access in your directory, or in some parent directory of your current directory. This will allow you
to restrict access to files within your working area. First, if you wanted to create a place for restricted files, you
would do the following after logging into the UNIX system:

% cd htdocs
% mkdir restricted

This creates the directory "restricted" within your htdocs. Next, you need to create the access control files for this
directory.

Setting Up a Password File

NCSA Apache has provided the htpasswd utility to set up password file in a directory. The suggested name of the
password file is .htpasswd. The htpasswd utility has a '-c' option to create the password file if it doesn't exist; you
should only this option the first time you create this file. This option is not needed subsequently.

Presuming you issued the two UNIX commands above, and you are in your "restricted" directory, you can do the
following:

% htpasswd –c /xampp/apache/.htpasswd userName

Password: <enter the password for the user ‘userName’>
%

This will create the file ".htpasswd" in your "restricted" directory, and that .htpasswd file will contain a single entry
– a user name and the password you typed in. That password, by the way, will not look anything like what you
typed in. This is because the password is encrypted in a one-way hash, so in theory you cannot derive the original
password from the encrypted version. To add another user to the .htpasswd file, you can do the following:

5
 % htpasswd /xampp/apache/.htpasswd userName2
Password: <enter the password for the user 'userName2'>
%

Note that the second time around, you don't supply the '-c' option. If you do, nothing bad will happen; you just
don't need to supply it since the .htpasswd file already exists. Also note that you do not want the .htpasswd file in
a directory below your public access folder (htdocs, public_html or www) for security reasons.

Setting Up an Access Description File

You have now set up the user name and password file for your "restricted" directory. However, this is still not
enough. You must create an access description file within the "restricted" directory as well. The name of this file is
part of the server configuration, but a normal default file name is ".htaccess". You need to create this file using
some kind of text editor (like vi, emacs, or the like) on the UNIX system, or you can create the file on your
Windows or Mac system using an appropriate text editor and then upload the file to the proper directory on the
UNIX system. However you do it, the .htaccess file must have the following general syntax:

AuthUserFile *absolute path to password file*

<Limit *HTTP commands*>
require user userid1 userid2
<Limit>

A specific example:

AuthUserFile /xampp/apache/.htpasswd
<Limit GET POST>
require user tyson frazier ali
</Limit>

The token "AuthUserFile" must be set to the full UNIX pathname of the .htpasswd that you created above. The
above example assumes that your home directory is in "/xampp/apache".

The next lines in the .htaccess file describe the access controls themselves. In the above example, the HTTP
GET and POST commands will be limited only to the users "tyson", "frazier" and "ali". If a browser requests any
page (via either the GET or POST HTTP commands) in the "restricted" directory or any of its sub directories, the
server will require that the browser solicit a user name and password from the user. The user name must be one
of the three listed, and, if so, the password supplied will be passed to the server (in clear text). That password will
then be encrypted using the same algorithm and key used to place the original encrypted password in the
.htpasswd file, and that result will be compared to the encrypted password stored in the .htpasswd file
(specifically, the file identified by the AuthUserFile token). If the encrypted passwords match, the user is granted
access to the desired web page. If not, an HTTP error 401 (Unauthorized) or 403 (Forbidden) will be returned to
the browser.

Restricting Access by Groups Using NSCA Apache

You can also set up groups of user names to simplify maintenance of restricted access. To do this, you can
create a third file to define groups of user names. By default, this file is called .htgroup, but you will reference this
directly in your .htaccess file, so the name can be whatever you choose. Like the .htpasswd file, you do not want
to store the .htgroup file under your public access tree (htdocs, public_html, www, etc.).

In this file, simply create a group name, and follow that group name by a colon and a list of users. This will
associate that list of users with that group name. For example:

basic: joe tom bob

silver: sam sally
gold: alex stan
platinum: bigbucks rich

6
This creates four groups. Then, if you like you can set up four directories in your UNIX htdocs file, and place an
.htaccess file in each of them:

In the directory "basic" you can have the following .htaccess file:

AuthUserFile /xampp/apache/.htpasswd
AuthGroupFile /xampp/apache/.htgroup
<Limit GET POST>
require group basic
</Limit>

In the directory "silver" the .htaccess file would look as follows:

AuthUserFile /xampp/apache/.htpasswd
AuthGroupFile /xampp/apache/.htgroup
<Limit GET POST>
require group basic silver
</Limit>

In the directory "gold" you would have:

AuthUserFile /xampp/apache/.htpasswd
AuthGroupFile /xampp/apache/.htgroup
<Limit GET POST>
require group basic silver gold
</Limit>

I'm sure you can deduce how the .htaccess file would look in the "platinum" directory. Using this approach, you
can see how easily you can add a user at a particular access level, and move a user between access levels. All
you need to do is edit the .htgroup file.