WebLi Broadband Network

Prepare to be making Greatest, Happiness, and Supper First Internet Suffering. The sophistication and high capacity of WebLi Network helps us deliver the highest levels service to our customers.

Constructing a Internet Login Access

HTTP is a stateless protocol, and login implies maintenance of state information, which must therefore be added on top of it. There are two main mechanisms [2,3] for this:

  1. HTTP Authentication
  2. Cookies

In terms of HTTP, these are very similar: both work by passing an additional header that contains state information. However, they are less similar to work with, and each has its own advantages and drawbacks

Which to Use?

It is my considered opinion that for any serious Web application, this choice should be dictated by the impression you wish to present to the users of the system:

·  HTTP Authentication generates the familiar login/password browser authentication sequence. This has a relatively formal feel, and may be reassuring to users who need confidence in the security of their data. The main drawback is that it is essentially inflexible, and cannot easily be adapted to more complex tasks, such as presenting restricted (e.g. read-only) access to anonymous users.
·  Cookies may be presented as you see fit, but are typically set using a login/password HTML Form and CGI script. If security is a concern, you will have to encrypt passwords yourself, as neither the browser nor the server will do it for you. You may also have to work harder to inspire confidence amongst users of the security of your system. At the time of writing, cookies are also regarded with suspicion by many users, due to privacy concerns [4].

The chief advantage of cookies is flexibility: you are handling the whole process yourself and have more control. The ability to set a persistent cookie and save the user having to re-authenticate each time she logs in may be a major advantage in some cases, but is inherently insecure if, for example, more than one user might be sharing a browser

Programming to work with both methods

A program may be written to work with either option. A construct I have used in a number of systems is represented by the Perl code:

This little example summarises the difference in the approaches

  1. First, if the user is authenticated by HTTP, we use this. No programming effort required.
  2. If not, we parse the Cookie (if any) for username/password. This is more work, because we must write routines to set and decode the authentication details. However, a small set of functions to manage cookie-users is a one-off reusable exercise.
  1. If neither option is set, we fall back to behaviour specified in the program: either allow the user in as a default user, or (if we called getuser with no arguments) insist that she authenticates.

We'll return to a variant on this construct later

In summary:

·  In programming terms, working with cookies involves more initial effort, but is much easier to extend to complex applications. Cookies are usually my preferred choice for ordinary Intranet systems.
·  In human terms, I consider HTTP authentication usually preferable on the Web.

Server Mechanics

As with any programming task, there's more than one way to do it. You can customise a webserver - either directly or using an API if one is provided - or you can use CGI for a portable solution. This is of course purely an implementor's decision, and does not affect your users.

Login using HTTP Authentication with CGI

HTTP Authentication is built into HTTP Servers (and of course browsers). The underlying mechanism is:

  1. The browser requests a document from the server.
  2. The server issues an authentication challenge.
  3. The browser prompts the user for credentials (typically via a username/password popup).
  4. The browser sends a new request to the server, including the credentials (username and encrypted password) entered.
  5. The server validates the credentials supplied, and (if acceptable) returns the document requested.

Scope and Duration of Authentication

  1. If the credentials were accepted once, the browser will return the same credentials in future requests to the server for the duration of the session [5]. As far as the server is concerned, this may be interpreted as "until told otherwise".
  2. The first three steps will thus normally be omitted after the browser has authenticated successfully once.
  3. Credentials are regarded by the browser as valid for other URLs in the same hierarchy (typically a directory) as one that has validated successfully, and are supplied automatically when requesting another URL.
  4. The Server can permit a particular set of credentials (i.e. user) to access some areas and deny access to others, by rejecting the credentials when another access is attempted. This restarts the authentication process at step (2) above.

Setting up HTTP Authentication

From the above, we see that HTTP Authentication not merely supports, but is a simple login scheme. Setting it up is a server configuration issue, and is completely transparent to CGI, just as it is to a static document - be it HTML or any other media type. You will need to consult your server manuals for details of how to configure protection, but the key point to remember is that your CGI program will only ever run when the User has already been authenticated by the Server.

If you are serving static documents, or indeed dynamic documents whose permissions can be determined in advance (e.g certain specified user(s) or group(s) are always permitted), you generally can and should use the Server's configuration in preference to CGI.

The User's identity (the username entered in the browser dialogue box) is available to CGI in the REMOTE_USER environment variable. No other information is available to CGI[6], due to security risks (although 'extended' CGI-like tools may sometimes give you this information anyway

Hence what HTTP Authentication gives you automatically is:

  1. Users are required to supply a valid username and password to access a designated area of your Server.
  2. Different URLs may permit different users. Most servers also support Groups.
  3. A User ID is supplied to CGI programs.

For many purposes, this alone is perfectly adequate. However, what it does not provide for includes:

  1. Logout (cancelling of credentials)
  2. Mixed (authenticated and unauthenticated) access to a common URL
  3. Dynamic determination of document permissions

The first two of these are in fact impossible [7], and must be worked around using either server configuration or CGI (as before, server configuration should be preferred if it can do what you need). The third can be accomplished with CGI, but has no non-programming alternatives

How-to . . .


HTTP has no provision to cancel a user's credentials, and there is no general[8] way to do so. The workaround is to overwrite the user's credentials with those of another valid user at your site. Create a valid but unprivileged user ID, and a Logout URL which is permitted only to this user. This URL is now a logout button. This of course still leaves you the human task of persuading your users to use it.

Mixed Access

It is not possible[7] to provide open and authenticated access to a single URL. However, it is entirely possible to offer mixed access to a document or program, by mapping a protected and unprotected URLs to the same document or program. In the case of a program, it may of course behave differently according to the value of REMOTE_USER (which is set only when access is authenticated).

Dynamic Permissions

I'm not even going to try and talk generalities about this. Instead I'll outline a working system

An Example using Dynamic Authentication

The File Manager component of the Virtual Desktop at <URL:http://www.login.webli.co.in/> has a fairly complex dynamic authentication requirement, requiring permissions to be computed from a database. The authentication function is required to determine:

  1. The logged in user. This is dealt with by the HTTPD, as described below.
  2. The owner of the file area being accessed. This is an argument to every call to the file manager, and so easy to determine.
  3. The protection of the file area being accessed. This is an attribute of every Directory and File in the Virtual Desktop (Attachments inherit the attributes of their parent File), and may be Public, Private or Workgroup. They may be changed - by the owner or another authorised workgroup member - at any time.

The authorization level at which the logged in user accesses the owner's desktop. This is determined from the owner's Workgroup file, and may permit the user readonly or read/write access to Workgroup-protected areas, and may also by updated by the owner at any time

Having cross-referenced these, it must either allow the attempted operation, or permit the user to re-authenticate (if access is denied, it may be available to the user under a different userid, so the user is immediately invited to re-login).