- From: Jan Algermissen <algermissen1971@mac.com>
- Date: Fri, 08 Jan 2010 20:19:32 +0100
- To: Tim <tim-projects@sentinelchicken.org>
- Cc: ietf-http-wg@w3.org
Tim, On Jan 8, 2010, at 6:19 PM, Tim wrote: > 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 Sort of - I just meant to sketch how it might work. I think some standard link relation might be better, e.g. GET /protected.html 401 Authorization Required Content-Type: text/html <html> <head> <link rel="noauth-version" href="/unprotected.html"/> </head> <body>...</body> </html> Then the browser had a way to make a choice between - showing the dialog as currently done - showing a button in the browser GUI for this page and display the noauth version - provide the dialog but include a button in the dialog to go to the noauth version Browsers that do not know noauth-version would not change their behavior. This could also be used in a Link header if the payload is not HTML. Hmmm - that is actually all not bad - maybe someone should register such a relation? Jan > > > 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 > authentication. > > thanks, > tim > -------------------------------------- Jan Algermissen Mail: algermissen@acm.org Blog: http://algermissen.blogspot.com/ Home: http://www.jalgermissen.com --------------------------------------
Received on Friday, 8 January 2010 19:20:11 UTC