- From: Cameron Heavon-Jones <cmhjones@gmail.com>
- Date: Fri, 10 Jun 2011 13:25:07 +0100
i'd like to reference a proposal i put forward in relation to expanding the functionality of forms which displays how http authentication could be implemented declaratively by html authors: http://lists.w3.org/Archives/Public/public-html/2011Apr/0259.html thanks, cameron jones On 10/06/2011, at 1:00 AM, Ian Hickson wrote: > On Tue, 1 Mar 2011, Boris Zbarsky wrote: >> On 3/1/11 5:29 PM, Ian Hickson wrote: >>>> >>>> I am still faced with the fact that there is no way to clear the >>>> HTTP authentication credentials cache. >>> >>> To some extent that's up to the browser. It logs you in, it can offer >>> the ability to log you out. >> >> For what it's worth, Firefox even has UI for this.... > > Indeed. > > > On Wed, 2 Mar 2011, Dave Kok wrote: >> >> You can also login using AJAX requests. This breaks the idea of it being >> purely a UI matter. > > How so? > > >> Also browsers don't all do this. > > They all don't do whatever else we come up with to solve this, too. > > >> In my opinion it is not sufficient to have solely the browser UI cover >> this particular feature. Also looking forward to a feature like app mode >> shipping in Google chrome, I remember Firefox having something similar, >> it would be really useful if it could be controlled from within a web >> page. > > If you really want to control it from within the page, just use another > credential mechanism, like form-submitted login and cookies. > > >> Also as web developers are requesting this over and over again there >> seems to be a real need. > > Compared to other features, this is not requested that often. > > >> Just saying that the web browser UI should do it is not getting the job >> done. > > Why would it be any more effective to do anything else? > > >> Most prominently however how is a web browser suppose to know which >> credentials to dump when the user hits a logout button in the web >> browser UI. During a page load multiple origins can be accessed and all >> may require credentials. > > That's also a UI issue. For example, the browser could just dump all the > credentials for the sessions started in the current tab, or it could show > the user a list of credentials that the user can pick to drop. > > >> But it seems mostly natural in a web application to include a logout >> button. I don't know of any web applications not having one. > > If they all have it, then there's no problem. :-) > > >> So why is it suddenly sufficient that the browser UI could have a logout >> button? > > For HTTP auth, the login is also done by the browser's UI. So it makes > sense that the logout should be done by the browser also. > > >> And if it should why is it not being required in any spec? > > We don't require UI of any kind. > > >> The whole purpose of these specs is to have some common denominator so >> building web sites/applications does not require having to know >> everything about every possible browser in use. It's about making life >> easy not hard. I really think some influential spec should say something >> about this. > > There aren't really any influential specs when it comes to UI (or much of > anything else -- specs only appear influential if they happen to spec what > implementors want to do anyway). > > >>>> I prefer to use HTTP authentication mostly as it is build-in anyways >>>> and has richer features then pure form-based authentication. >>> >>> What features does it have that other mechanisms do not? >> >> HTTP authentication like HTTP itself is stateless. Form-based >> authentication isn't and requires the extra hurdle of having to persist >> a session key. > > Ironically, it's the fact that HTTP authentication is state_ful_ that is > causing you trouble here. > > >> As far as I can judge, form-based authentication has no pros over HTTP >> authentication. Other then the web developer being able to create a >> working logout procedure. Please note that one can also use a form to >> gather the credentials and login in through AJAX. But mostly I like the >> idea of it being in the HTTP protocol itself. Rather then implemented on >> top of it. > > That seems very arbitrary. > > >> It allows for futures expansions like upgrading to more secure >> authentication methods like Kerberos (I believe Microsoft is already >> doing this) or using client certificates (already possible). I don't see >> this happening with form-based authentication. When logging out is >> possible and well supported I actually see these more secure >> authentication methods becoming mainstream. > > I'm rather skeptical, personally. Client certificates are an > authentication mechanism that baffles regular users. > > > On Wed, 2 Mar 2011, Dave Kok wrote: >> >> Unrelated, how authentication is triggered has nothing to do with when >> it is cleared. But after authentication has been triggered and the user >> has entered it credentials (or used credentials that are pre- filled by >> the UA) those credentials are cached for automatic reuse, so the user >> does not have to log in and log in over and over again. Very useful, we >> all love it. But at some point those cached credentials must be cleared >> so the UA triggers again a dialog to require the user to log in again >> (possible again pre-filling credentials from some store). It is the >> clearing I propose a site should be able to aid the UA in. This is not a >> simple thing as the site does not know the credentials, as it should. >> But it often does now when a session starts and ends. So when it can >> communicate this to the UA, the UA can use this info to clear >> credentials at the appropriate time. Rather then waiting when the user >> closes the window or manually clears credentials using a browser UI >> feature. Should a user be expected to do this? > > I recommend bringing these questions up with browser vendors and seeing if > they are interested in implementing some experimental features for it, as > per this question in the FAQ: > > http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F > > One question that I think is relevant for such a proposal is: how can a > Web page know when a session has ended? Users don't typically hit the > logout button, do they? > > Then again, personally I never consider my sessions over. Once I've logged > in, I want to remain logged in until the machine dies a final death. It > drives me crazy that I keep having to log in to my bank's Web app. > > > On Thu, 3 Mar 2011, Dave Kok wrote: >> >> Please appreciate the notion that HTML5 is broader then just browsing >> the internet. > > At least for the purposes of the WHATWG, this is not the case. We are only > focusing on making the Web better. Other applications may benefit as a > side-effect, but they are not a consideration. We have enough difficulty > making a language for the Web without trying to make it fit other worlds > as well! > > > On Thu, 3 Mar 2011, Dave Kok wrote: >> >> Here is a more formal proposal for Session Management. Hoping to get >> more traction. >> >> SCOPE >> >> The proposal is restricted solely the HTML5 spec. Though in the rational >> HTTP and authentication are mentioned as by example. >> >> INTERFACE >> >> This proposal requests for an new interface to be added to HTML5 usable >> from script. The interface is currently defined on the window global >> object. The naming is chosen so it seems natural to co-exist with >> sessionStorage. > > The first step here is describing the problem, not the solution. > > We can't evaluate solutions without knowing what problems they solve. > > > On Fri, 11 Mar 2011, Dave Kok wrote: >> >> [In] the case of a web application in which a lot of documents are >> interdependent the use case becomes self-evidence, at least to me. Often >> these sites have a particular workflow. You start here then go there and >> so on. Often there is a single starting point. Like a page on which you >> get the option to login or register. Once logged in you are rerouted to >> a page for instance that contains messages of things that have changed >> since you last logged in. This off course all very much depends on the >> type of web site/application. However I don't think anyone is going to >> think that a web-based email client exists of independent pages that you >> can just bookmark and revisit later. These pages often have additional >> state that is build up in the course of using the web site/application. >> This state (session data) can't be bookmarked. > > You can bookmark GMail pages just fine as far as I can tell. > > >> In these instances having a defined method of telling the UA where a >> session begins and ends is useful to the point that it allows a UA to >> track what session data belongs to the session and clean it when no >> longer useful. > > That doesn't really seem compatible with how the Web works. In the Web you > can go to a page, then open links from that page in many tabs, then close > some, open more, then close all of them, then unclose a tab, then bookmark > it, then reboot, then reopen the bookmark... > > I don't really understand what problem a "session" concept solves. The > problems with authentication on the Web today aren't about session ends, > they're about identity, lack of multi-factor login, weak passwords, weak > account recovery features, etc. If anything is wrong with "logout" on the > Web, it's that sites are too _eager_ to log me out, IMHO! > > >> Think of sessionEnd as terminating a regular desktop application. > > Regular desktop applications are specifically moving _away_ from this > model. See OS X Lion's session resume features, session restore in > Firefox, Opera, Safari, or Chrome... heck, even software in the 90s (e.g. > Turbo Pascal) used to resume sessions automatically. OSes themselves have > long had suspend/hibernation features to resume state. > > Terminating sessions seems to be largely considered a bug, not a feature. > > >> Does an OS notify you when you logged out of your e-mail client? > > You can log out of desktop e-mail clients? > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 10 June 2011 05:25:07 UTC