Re: Authentication

rhb@hotsand.att.com
From: rhb@hotsand.att.com
Date: Sun, 2 Jan 94 19:24:34 EST
Original-From: hotsand!rhb (Rich Brandwein)
Message-id: <9401030024.AA29725@hotsand.dacsand>
To: www-talk@nxoc01.cern.ch
Subject: Re: Authentication
Content-Length: 1977
> ---From Robert S. Thau:
> If you control the server in question, then there is a trick which lets
> you make Mosaic forget the information --- create a directory with a
> .htaccess file which *always* denies access, by, e.g., requiring
> membership
> in an empty group.  Attempts to retrieve a file in that directory will
> result in authentication failures, to which Mosaic responds by letting
> you
> enter a new name and password.
> 
> But this is a kludge, and for foreign servers, I still don't know
> anything
> that works.

This doesn't seem to work because of the answer to my second question:

> 
> ----From Rob McCool:
>  * Secondly, how many different servers can Mosaic 2.x authenticate
>  * to within the same window/process?  Is it greater than 1?
>  */
> 
> The libwww code uses a linked list to store the information about the
> servers and therefore it can authenticate to a large number of
> different
> servers.
> 

When you go back to the authenticated directory, you will still
be authenticated.

There is no indication in Mosaic as to which places you
may be currently authenticated to and the authentication session
never "times out".  People also tend to open up multiple Mosaic sessions
and then it becomes a complete question as to which is authenticated.

This is particularly a problem in placing Mosaic on public
workstations, where there may be users using the same Mosaic
application.  The real current cludge is to force users to 
completely close the window when they are done. 

Leaving "sessions" open even on personal workstations (which can be
locked) is also troublesome for people creating applications.
It would be nice if Mosaic could be set to flush this info about 
particular sessions after some period of time.

It seems that I could (if I bothered to figure out where the cache is
stored) run a local process to do this for me on the client
as an interim kludge. 

Rich

----
Rich Brandwein
AT&T Bell Labs
rich.brandwein@att.com