On 3/2/11, Dave Kok <upda...@davekok.net> wrote: > Op 01-03-11 23:29:26 schreef Ian Hickson: >>On Thu, 25 Nov 2010, Dave Kok 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. > > You can also login using AJAX requests. [..] Application protocols (FTP, HTTP) can trigger authentication. Users can authenticate, and refuse to authenticate (e.g. by discarding credentials). What additional features do you need, and to serve what use cases?
Ultimately, UAs must be able to discard all credentials (from all, or a specific site) upon a single command. Just see what happens when users login to a site, then navigate to another and authenticate to the latter, and then logout from the latter. In that case, they're still authenticated to the former site. In theory, this shouldn't be a problem, as users should clear all UA data before granting anyone else access to the UA data store, but in ill-managed public terminals, that may not be the case. > [..] This breaks the idea of it > being purely a UI matter. Also browsers don't all do this. 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. Also as web developers are requesting this over and over again > there seems to be a real need. Just saying that the web browser UI > should do it is not getting the job done. 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. 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. So why is > it suddenly sufficient that the browser UI could have a logout button? It is not sufficient for a document to have one. It has to be possible to discard credentials when no document is being rendered. For that to happen, the UA needs to manage credentials. > And if it should why is it not being required in any spec? 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. > How users discard credentials is not up to the spec, neither HTML nor HTTP. It shouldn't be against the spec to hard code credentials for corporate sites into the UA used by the corporation. >> >> >>> 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. 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. 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. > tl; dr: We need to patch logout buttons into mainstream UAs. >> >> >>> The only problem is that you can't clear credentials when a session >>is >>> terminated. So I am wondering whether some kind of session control >>that >>> is somewhat broader then just clearing sessionStorage could be >>included >>> into the standard. >>> >>> Personally I would imagine such a API existing out of just two >>> functions: a start and a terminate function. After an session has >>> started all credentials cached for HTTP authentication and >>> everything >> >>> stored in sessionStorage and all cookies without explicit expiration >>> created, would all be destroyed when the terminate function is >>> called >>or >>> when the user navigates away from the origin in the top-browser >>context. >>> Using such a method would give a web application developer just the >>> right amount of control and would allow the implementation of a >>logout >>> button that actually works. Currently it is possible the clean out >>> sessionStorage and destroy cookies but not to clear cached >>credentials >>> for HTTP authentication. >>> >>> Possibly the start function could also accept a path argument to >>specify >>> just a sub area of the origin on which the session is valid. This >>would >>> allow more fine-grained control. Please note that the session would >>be >>> specific to the top-browser context. Also HTTP authentication >>> credentials belonging to the current session should not be limited >>> to >> >>> just credentials cached for the top-browser context origin but all >>> credentials cached. This should also be the case for sessionStorage >>and >>> cookies without expiration specified. >>> >>> As for backwards-compatibility since the feature requires a >>> developer >>to >>> call a function to make use of it. It would not impact current web >>> applications and thus would be fully backwards-compatible. A >>developer >>> must already know about the feature to use it. So I would expect >>> that >> >>> such a consideration would not be an obstacle. >> I think users should initiate authentication and deauthentication. Also an HTML renderer and JavaScript VM may not have a communication channel with a HTTP UA feeding it data.
