WWW Authentication

Information providers may decide to protect their pages by password in order to restrict who can see them. (eg. Acorn's Clan only pages). To do this they construct a password file at the server end and put an access control file in the clan home directory, giving a symbolic name by which any files under that directory need to be accessed. Acorn chose "AcornClan" as their authentication 'realm' . This means that if you send a normal request to www.acorn.co.uk asking for one of the clan pages, you will get back:


HTTP/1.0 401 Unauthorized
Server: CERN/3.0 (or similar)
Date: .... etc. etc.
WWW-Authenticate: Basic "AcornClan"
Content-Type: text/html

<title>Unauthorized</title>
<h1>401 Unauthorized</h1>Your browser does not appear to support user
authentication.

At which point, ArcWeb will prompt you for a user name and password which will satisfy the "AcornClan" realm of www.acorn.co.uk. So you enter the user name and password and press RETURN and ArcWeb will resend the request but include an extra header. For example, suppose I enter user name 'Aladdin' and password 'open sesame', the following header will be sent with the repeated request:


Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

where it has converted the user name and password to a simple non-clear text format (note: this is NOT SECURE - any base64 decoder can decode that string I've given above back into 'Aladdin:open sesame') Note that the authentication information is cached by ArcWeb until it quits (unless you set the option in the configuration window to stop it deleting the cache upon exit), and that if you attempt to access another page under the clan hierarchy, then ArcWeb will speculatively add the cached authentication information to the original request in an attempt to pre-empt any challenge.

Stewart Brodie
21st November 1995