Re: Past Proposals for HTTP Auth Logout

David Morris wrote:
>
>
> 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?
>

Browsers just need to provide a standardized javascript API for setting 
and flushing the Authorization header (per domain).

'Logging In and Out' is a purely client-side concern, so it seems a good 
candidate for solving with code on demand - since there's really no 
visibility to lose.

- Mike

Received on Saturday, 9 January 2010 15:20:11 UTC