Re: Past Proposals for HTTP Auth Logout

Hi Jan,

> >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.

Ok, so thinking about this more, is this the algorithm you propose
browsers use?

  Browser receives 401

  If auth type and realm match those of any cached credentials, then:
    Clear cached credentials
    Show body of 401 response to user

  Otherwise: Prompt user for new credentials

That's the only way I can think of where this would be workable.  It's
clearly not the way any browser does it today.  Is this kind of
algorithm mentioned anywhere in any of the RFCs?  I'm guessing not...
Don't get me wrong, it does make sense, but I can also understand why
browsers never got around to doing this.

My goal is to make HTTP-based (basic, digest, or other) authentication
viable in the majority of web applications.  While it might be
possible to convince the top 2-3 browsers to change behavior by asking
nicely, it may be easier to define an explicit logout response header
or type which makes it blatantly obvious what's supposed to happen.
If I can't convince at least the top 2 browsers to make logouts user
friendly, then no app developer will ever even consider HTTP based


Received on Friday, 8 January 2010 17:20:13 UTC