home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Acorn User 3
/
AUCD3.iso
/
airport
/
browsers
/
arcweb190
/
!ArcWeb
/
PublicHTML
/
authorise
< prev
next >
Wrap
Text File
|
1995-11-21
|
2KB
|
54 lines
<title>WWW Authentication</title>
<body>
<h1>WWW Authentication</h1>
Information providers may decide to protect their pages by password in
order to restrict who can see them. (eg. <a
"href=http://www.acorn.co.uk/acorn/clan/private/Home">Acorn's Clan only
pages</a>). 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:
<pre>
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.
</pre>
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:
<pre>
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
</pre>
where it has converted the user name and password to a simple non-clear
text format (note: this is <em>NOT SECURE</em> - 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.
<hr>
<address>Stewart Brodie<br>21st November 1995</address>