[1737] in WWW Security List Archive
Re: User Auth.
daemon@ATHENA.MIT.EDU (Brian W. Spolarich)
Wed Mar 27 16:37:03 1996
Date: Wed, 27 Mar 1996 13:03:19 -0500 (EST)
From: "Brian W. Spolarich" <briansp@ans.net>
To: cdp@ecmwf.int
cc: www-security@ns2.rutgers.edu
In-Reply-To: <199603262229.WAA27507@agnar>
Errors-To: owner-www-security@ns2.rutgers.edu
On Tue, 26 Mar 1996 cdp@ecmwf.int wrote:
> Where did you get that idea that the "browsers have the notion ..." ?
> This has absolutly nothing to do with any browser.
> Before making any statement of that sort, check the documentation !
> The browsers are there to try to display HTML coded files, and to follow
> the http protocol, which does NOT provide for this feature alltogether.
Hmmm...I guess I have to disagree here. This is a client
implementation question more than a protocol question. The question is
(as I understood it): is there any way to discard the locally-cached
authentication data without exiting the program?
[ mucho stuff deleted ]
> When you say "unsuitable for a shared lab environment", this is true, but a
> telnet session has the same weakness, reading your mail as well: if you use a
> workstation, PC, mac whatever to do something, and this is personnal and should
> not be read by other people, then it is usually not at the application level
> that you block further access, but at the machine level itself (although, it
> would be nice to be able to selectively block individual applications).
Again, I disagree. This seems completely an application question to me.
Network sniffing, etc. aside, if I read mail on a shared PC, then my mail
program, if its running locally, should allow me to NOT download mail to
the local disk, cache my password indefinitely, etc. Similarly, a
reasonable function for the HTTP client would be to view, and optionally
delete, the cached authentication data (i.e. host/username/realm sets).
These are just implementation questions that for the most part aren't
specified by the protocol. HTTP/1.0 (last time I read the draft)
specified how this transaction should take place, but not how the client
presents and manipulates such information:
From the HTTP/1.0 spec:
11. Access Authentication
[ ... ]
A user agent that wishes to authenticate itself with a server--usually,
but not necessarily, after receiving a 401 response--may do so by
including an Authorization header field with the request. The
Authorization field value consists of credentials containing the
authentication information of the user agent for the realm of the resource
being requested.
credentials = basic-credentials
| ( auth-scheme #auth-param )
The domain over which credentials can be automatically applied by a user
agent is determined by the protection space. If a prior request has been
authorized, the same credentials may be reused for all other requests
within that protection space for a period of time determined by the
authentication scheme, parameters, and/or user preference. Unless
otherwise defined by the authentication scheme, a single protection space
cannot extend outside the scope of its server.
I saw the question and comment as entirely reasonable, and not
deserving of such a heavy flame. :-]
-brian
--
Brian W. Spolarich - ANS CO+RE Systems - briansp@ans.net - (313)677-7311
We're Starfleet officers...weird is part of the job.
