[10778] in www-talk@info.cern.ch
RE: Browser authentication
daemon@ATHENA.MIT.EDU (Marc Salomon)
Thu Apr 24 10:59:49 1997
From: Marc Salomon <marc@sfaids.ucsf.edu>
To: "grahameg@kestral.com.au" <grahameg@kestral.com.au>,
"www-talk@w3.org"
<www-talk@w3.org>,
"'kdyer@draper.com'" <kdyer@draper.com>
Date: Fri, 25 Apr 1997 05:47:38 -0700
Resent-From: www-talk@w3.org
This is the space where authentication and cookies intersect. =
Authentication is a key, a domain and a scheme looking for a timeout =
while cookies are a key, a domain and a timeout looking for a scheme. =
Just as there is a mechanise for a server to swallow a cookie in the =
protocol, so should a server be able to unset authentication.
A 416 return code described below would be useful, but would only work =
in cases where the user agent were well-connected and if active enough =
to trigger the cancellation of authorization. This solution does not =
confront the other big unaddressed authentication security hole: =
public-area web station scenario where you want the user agent to lose =
browser-cached authentication information after a short idle time.
-marc
----------
From: Kevin J. Dyer
Sent: Thursday, April 24, 1997 4:35 AM
To: grahameg@kestral.com.au; www-talk@w3.org
Subject: Re: Browser authentication
On Apr 24, 4:39am, grahameg@kestral.com.au wrote:
> Subject: Browser authentication
> Is there anyway for a server to clear the authentication field carried =
in
> the HTTP header?
>
> We wish to time the authentications out, but returning an HTTP 401
> Authorisation failed
|[...]
|
|I made a suggestion late last year to add a 416 return code. The short
|of it required the UA to cancel all authentications with the current
|domain. This would be for both basic and digest authentication. But
|that was for 1.1+.
|Kevin J. Dyer
