W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2010

Re: Past Proposals for HTTP Auth Logout

From: David Morris <dwm@xpasc.com>
Date: Fri, 8 Jan 2010 11:02:24 -0800 (PST)
To: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-ID: <Pine.LNX.4.64.1001081049430.1262@egate.xpasc.com>


On Fri, 8 Jan 2010, Jan Algermissen wrote:

>
> On Jan 7, 2010, at 10:51 PM, David Morris wrote:
>
>> 
>> 
>> On Thu, 7 Jan 2010, Nicolas Alvarez wrote:
>> 
>>> Tim wrote:
>>>> I'm doing some research and I'm interested in learning about any past
>>>> proposals to augment HTTP authentication (basic/digest) with a logout
>>>> feature.  I have spent several hours reading mailing list archives and
>>>> searching the web, and while I've found plenty of related information,
>>>> I'm surprised to find no concrete proposals for this feature.
>>> 
>>> I don't see how that concerns HTTP; it's a missing feature on the 
>>> browsers.
>>> 
>>> Credentials are sent on every request. All you need is a logout button on
>>> the *browser* that makes it stop sending credentials. Go file feature
>>> requests to the browser vendors :)
>> 
>> So on what basis does the browser prompt again? It is likely a better user
>> experience if the flush credentials is part of a server response to a
>> web page logout button which lets both ends know the logout occured and
>> takes the user to a page which doesn't immediately present a new credential 
>> dialog.
>> 
>
> This is a hypermedia and/or browser issue, not an HTTP issue. The server can 
> send along with the 401 response a representation to display. Maybe the 
> version of the page for unauthenticated users. The browser can display a less 
> annoying dialog or button in the GUI showing the client that it *can* login. 
> Otherwise the client could continue or be redirected to a non-auth version of 
> the Web site.
>
> It is just a matter of what the browser makes of the 401 response. It need 
> not display the login dialog right away.

That is really not true ... what any part of the process 'could' or 'can'
do is not relavent to interoperability. The point of standards is that all
parties know what is expected of their behavior and what they can expect
from the other parties.

web authentication lacks a specified way to close the door once it is 
open. Providing a door close function is a requirement on HTTP.

There is sufficient evidence after 15 years that browser implementors 
haven't chosen to implement even a simple credential flush dialog. 
When you use a browser to access www-auth protected content, do you have a 
solid understanding of when your credentials are invalidated? Or exactly
how they are used? If you use multiple browser windows, opened as 
processes? Opened as new windows? How about tabs? I have no confidence 
that I understand the span of applicability with anything short of 
rebooting the system insuring credentials are purged. I've been an 
implementor of web technology based applications since 1994. If I'm not 
confident, how do you expect the average user to even understand there
to be a problem?
Received on Friday, 8 January 2010 19:02:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:16 GMT