W3C home > Mailing lists > Public > www-talk@w3.org > March to April 1997

RE: Browser authentication

From: Marc Salomon <marc@sfaids.ucsf.edu>
Date: Fri, 25 Apr 1997 05:47:38 -0700
Message-ID: <01BC513C.33FF2CA0@ucsfaids08.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>

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.


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
Received on Thursday, 24 April 1997 10:50:03 UTC

This archive was generated by hypermail 2.4.0 : Monday, 20 January 2020 16:08:22 UTC