Re: [whatwg] Session Management
On Fri, 10 Jun 2011, Cameron Heavon-Jones wrote: > > 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 > > [user authentication in forms] We've tried to address this several times over the past few years, each time unsuccessfully. The biggest problem is that we lack good implementation experience to guide us. Browser vendors have started looking at identity more seriously in recent months, which may end up addressing this problem at a more fundamental level. In the meantime, I encourage you to approach browser vendors directly to propose experimental extensions to the form features to address this issue, so that we can get the implementation experience we need to make progress on this issue. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Session Management
On 14/06/2011, at 10:40 AM, Dave Kok wrote: >> What do you mean by "it's a protocol thing"? The idea is to provide a UI to >> enable a human to interact with the protocol, this must be present in some >> way, either by the UA as at present, or through forms as suggested. > Personally I prefer the perspective that you are providing a UI for the use > case 'to log in', not to give access to the protocol. Yes, this is how we would like to implement this on a service or application level however it is not what http authentication requires for the protocol. Http authentication is stateless (state held by UA, not protocol) and it must be, potentially, applied to any request. Therefore it must be possible to additionally declare authentication on any form, constructing any representation, using any protocol method. That the UA retains authentication and automatically applies to subsequent requests only allows for the possibility for a single-use login form to be authored. The login form would be used to tailor a request's headers and not specifically for the construction of a URI or form-encoded representation, although this would additionally be possible. > If you limit it to a use > case without knowledge of the protocol you also allow for broader > implementation. For instance when the HTTP protocol isn't used. There is nothing explicitly tying the design to the http protocol, especially if input type of 'header' is viewed as capturing metadata for a protocol request. > Using forms as > suggested I fully support. But my preference is to limit the forms to > gathering the information needed to login and let a user-agent worry about > the > details. Yes, it is the ideal to have this level of abstraction but it is also an abstraction based on a single use and so looses any potential general applicability through lack of specification. All logins can't be reduced down to just a username\password and a domain, but some authentication models can. > I would expect that the only information required is the user's > credentials and perhaps a domain (never fully read up on digest > authentication). If you disagree then I am afraid we have to settle on this > by > agreeing that we disagree. Very well, i will stand in disagreement :) [snip] > Binding on a new attribute gives authors a choice. The introduction of a new input element type 'header' is the new attribute which may activate new behaviour. > They can > either choose to include both a name attribute and the new attribute for > binding and things are as you commented. Or authors can use a different > approach. What worries me is that if a author does not account for > user-agents > not handling the authorization, the user's credentials are sent in the clear > for all the see, especially when using the GET method. For plain text passwords to be visible in the URI in an old non-compatible browser, the author will have chosen to use plain http (no ssl) and as a GET request. If the form is set to POST it will operate the same way people send passwords through forms today. Thanks, Cameron Jones
Re: [whatwg] Session Management
Op vrijdag 10 juni 2011 19:36:15 schreef u: > On 10/06/2011, at 4:23 PM, Dave Kok wrote: > >>> Ultimately a user-agent must use whatever > >>> method required by the server not the method defined by the author. A > >>> user- agent can transparently find out which method to use with a HEAD > >>> request. Or if transport layer security is used simply guess one and > >>> see if it works and try again if it doesn't. > >> > >> I'm not sure i agree. The server has served up the page so ultimately it > >> is in control. If the author specifies something which the server can > >> not handle, that's just an authoring bug is it not? > >> > >> I also don't think an agent should be making any guesses...this would > >> definitely seem to violate the authority to define the modus operandi. > > > > This is assuming the form's action targets the same domain. I see no > > reason why it should. On top of that authentication is a protocol thing > > so it's best to leave most of the details at that level and not expose > > those to a higher level. As rational you can look at the > > XMLHttpRequest.open function. It only allows an author to supply a > > username and password and not what method to use or any additional > > parameters. > > But, it also allows for manually setting the Authorization header which > takes precedence over the method arguments. Really, never tested that, could be interesting. > > What do you mean by "it's a protocol thing"? The idea is to provide a UI to > enable a human to interact with the protocol, this must be present in some > way, either by the UA as at present, or through forms as suggested. Personally I prefer the perspective that you are providing a UI for the use case 'to log in', not to give access to the protocol. If you limit it to a use case without knowledge of the protocol you also allow for broader implementation. For instance when the HTTP protocol isn't used. Using forms as suggested I fully support. But my preference is to limit the forms to gathering the information needed to login and let a user-agent worry about the details. I would expect that the only information required is the user's credentials and perhaps a domain (never fully read up on digest authentication). If you disagree then I am afraid we have to settle on this by agreeing that we disagree. > >>> Also binding the username and password input fields to the > >>> authorization header should properly not be done by reserving names in > >>> the name attribute of the input field. I would suggest using a special > >>> purpose attribute like authorization to declare their binding. > >>> Otherwise authors have to cope with reserved names which is properly > >>> unacceptable backwards-compatible wise. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> Dave Kok > >> > >> But, in reference to backwards compatibility, the authorization must be > >> explicitly declared so this wouldn't be applied universally. > > > > Yes but browsers not supporting the new feature would simply post the > > username and password without using any authentication method. However > > those fields are suppressed if no the name attribute isn't used. Thus > > using a new attribute has my preference. Also to allow building a work > > around for non-conforming browser which will exists for many years to > > come even is this feature finds it way into the spec. > > But, the authorization would only be applied when instructed through the > application of the specific header. Yes indeed. > This means that there can't be any conflict with existing pages\forms as form > headers don't currently exist. I can't determine the validity of the claim. That in itself worries me. I you are right I would agree. Personally I would take the safe road. > There is a benefit to binding the parameters from input names - for old > browsers which don't support the new headers they will at least send a > request to the server which can be setup to handle legacy requests as form > encoding, probably falling back to setting up a cookie session. As you > noted, if new attributes are introduced, no data will be sent. The problem is that by binding it on the name attribute, authors no longer have a choice. Binding on a new attribute gives authors a choice. They can either choose to include both a name attribute and the new attribute for binding and things are as you commented. Or authors can use a different approach. What worries me is that if a author does not account for user-agents not handling the authorization, the user's credentials are sent in the clear for all the see, especially when using the GET method. By giving authors the choose you also force them to think it over. At least to some degree. Those that just copy&paste stuff will properly never think it over. But disregarding those if authors have to choice those not accounting for the user agent to handle it will only have a
Re: [whatwg] Session Management
On 10/06/2011, at 4:23 PM, Dave Kok wrote: >>> Ultimately a user-agent must use whatever >>> method required by the server not the method defined by the author. A >>> user- agent can transparently find out which method to use with a HEAD >>> request. Or if transport layer security is used simply guess one and see >>> if it works and try again if it doesn't. >> >> I'm not sure i agree. The server has served up the page so ultimately it is >> in control. If the author specifies something which the server can not >> handle, that's just an authoring bug is it not? >> >> I also don't think an agent should be making any guesses...this would >> definitely seem to violate the authority to define the modus operandi. > This is assuming the form's action targets the same domain. I see no reason > why it should. On top of that authentication is a protocol thing so it's best > to leave most of the details at that level and not expose those to a higher > level. As rational you can look at the XMLHttpRequest.open function. It only > allows an author to supply a username and password and not what method to use > or any additional parameters. > But, it also allows for manually setting the Authorization header which takes precedence over the method arguments. What do you mean by "it's a protocol thing"? The idea is to provide a UI to enable a human to interact with the protocol, this must be present in some way, either by the UA as at present, or through forms as suggested. >> >>> Also binding the username and password input fields to the authorization >>> header should properly not be done by reserving names in the name >>> attribute of the input field. I would suggest using a special purpose >>> attribute like authorization to declare their binding. Otherwise authors >>> have to cope with reserved names which is properly unacceptable >>> backwards-compatible wise. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> Dave Kok >> >> But, in reference to backwards compatibility, the authorization must be >> explicitly declared so this wouldn't be applied universally. > Yes but browsers not supporting the new feature would simply post the > username > and password without using any authentication method. However those fields > are > suppressed if no the name attribute isn't used. Thus using a new attribute > has > my preference. Also to allow building a work around for non-conforming > browser > which will exists for many years to come even is this feature finds it way > into > the spec. But, the authorization would only be applied when instructed through the application of the specific header. This means that there can't be any conflict with existing pages\forms as form headers don't currently exist. There is a benefit to binding the parameters from input names - for old browsers which don't support the new headers they will at least send a request to the server which can be setup to handle legacy requests as form encoding, probably falling back to setting up a cookie session. As you noted, if new attributes are introduced, no data will be sent. The benefit i see in allowing binding from input name is that any of the input types can be used to collect the necessary data to form the request. For realms, this could be a multi-select. sorry, i didn't mean to pollute the thread...it seemed related to the issue but is probably going on a tangent. thanks, cameron jones
Re: [whatwg] Session Management
On 10/06/2011, at 4:23 PM, Dave Kok wrote: > Op vrijdag 10 juni 2011 16:07:01 schreef u: >> On 10/06/2011, at 2:12 PM, Dave Kok wrote: >>> I very much like the header type as a generic feature but would suggest >>> not using it for HTTP authorization. As for user-agents to support it >>> through forms have to use special processing anyways. So I would suggest >>> simply declaring it on the form element itself as an attribute. When >>> using XMLHttpRequest one already has the ability to supply credentials >>> with the open function. So when using a input elements without a form >>> element there is no need for an authorization feature. Also I would >>> suggest that the attribute does not have a value or that it is at least >>> optional and when supplied is only a hint to the user-agent. >> >> I most definitely concur the usefulness of header fields :) >> >> The problem with authentication is it's pre-existing complexity and getting >> existing technologies to converge in a unified way. >> >> The attraction to this is that with the base extensions to forms it seems >> like the ability to declare authentication is only a short step away, and >> it's complexity provides a thorough use case for identifying the necessary >> specification edge cases. > My my most important comment. Is not to use the name attribute of the input > field for specifying a binding to an extension. You don't want to constrain > the > usage of existing attributes for new extensions. Use new attribute to specify > the binding. > hmmmi see your point >> >>> Ultimately a user-agent must use whatever >>> method required by the server not the method defined by the author. A >>> user- agent can transparently find out which method to use with a HEAD >>> request. Or if transport layer security is used simply guess one and see >>> if it works and try again if it doesn't. >> >> I'm not sure i agree. The server has served up the page so ultimately it is >> in control. If the author specifies something which the server can not >> handle, that's just an authoring bug is it not? >> >> I also don't think an agent should be making any guesses...this would >> definitely seem to violate the authority to define the modus operandi. > This is assuming the form's action targets the same domain. I see no reason > why it should. On top of that authentication is a protocol thing so it's best > to leave most of the details at that level and not expose those to a higher > level. As rational you can look at the XMLHttpRequest.open function. It only > allows an author to supply a username and password and not what method to use > or any additional parameters. > I agree, there is no reason the action should be the same domain. >> >>> Also binding the username and password input fields to the authorization >>> header should properly not be done by reserving names in the name >>> attribute of the input field. I would suggest using a special purpose >>> attribute like authorization to declare their binding. Otherwise authors >>> have to cope with reserved names which is properly unacceptable >>> backwards-compatible wise. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> Dave Kok >> >> But, in reference to backwards compatibility, the authorization must be >> explicitly declared so this wouldn't be applied universally. > Yes but browsers not supporting the new feature would simply post the > username > and password without using any authentication method. However those fields > are > suppressed if no the name attribute isn't used. Thus using a new attribute > has > my preference. Also to allow building a work around for non-conforming > browser > which will exists for many years to come even is this feature finds it way > into > the spec. > understood >> >> I'm more thinking of a way to initiate the http authentication in html >> instead of as a browser popup. This allows for the author to define the >> user experience in the same way they do for cookie-based authentication >> which people have come to expect and trust. >> >> I was thinking the authentication would not be applied to all forms, but >> just as a replacement for the login form. After successful login the UA >> would continue to apply the Authorization headers to each subsequent >> request, until shutdown or logout. > > I would expect no less. Otherwise this exercise is rather useless. > > -- > Dave Kok thanks for the feedback, will need to mull over this some more :) thanks! cameron jones
Re: [whatwg] Session Management
Op vrijdag 10 juni 2011 16:07:01 schreef u: > On 10/06/2011, at 2:12 PM, Dave Kok wrote: > > I very much like the header type as a generic feature but would suggest > > not using it for HTTP authorization. As for user-agents to support it > > through forms have to use special processing anyways. So I would suggest > > simply declaring it on the form element itself as an attribute. When > > using XMLHttpRequest one already has the ability to supply credentials > > with the open function. So when using a input elements without a form > > element there is no need for an authorization feature. Also I would > > suggest that the attribute does not have a value or that it is at least > > optional and when supplied is only a hint to the user-agent. > > I most definitely concur the usefulness of header fields :) > > The problem with authentication is it's pre-existing complexity and getting > existing technologies to converge in a unified way. > > The attraction to this is that with the base extensions to forms it seems > like the ability to declare authentication is only a short step away, and > it's complexity provides a thorough use case for identifying the necessary > specification edge cases. My my most important comment. Is not to use the name attribute of the input field for specifying a binding to an extension. You don't want to constrain the usage of existing attributes for new extensions. Use new attribute to specify the binding. > > > Ultimately a user-agent must use whatever > > method required by the server not the method defined by the author. A > > user- agent can transparently find out which method to use with a HEAD > > request. Or if transport layer security is used simply guess one and see > > if it works and try again if it doesn't. > > I'm not sure i agree. The server has served up the page so ultimately it is > in control. If the author specifies something which the server can not > handle, that's just an authoring bug is it not? > > I also don't think an agent should be making any guesses...this would > definitely seem to violate the authority to define the modus operandi. This is assuming the form's action targets the same domain. I see no reason why it should. On top of that authentication is a protocol thing so it's best to leave most of the details at that level and not expose those to a higher level. As rational you can look at the XMLHttpRequest.open function. It only allows an author to supply a username and password and not what method to use or any additional parameters. > > > Also binding the username and password input fields to the authorization > > header should properly not be done by reserving names in the name > > attribute of the input field. I would suggest using a special purpose > > attribute like authorization to declare their binding. Otherwise authors > > have to cope with reserved names which is properly unacceptable > > backwards-compatible wise. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Dave Kok > > But, in reference to backwards compatibility, the authorization must be > explicitly declared so this wouldn't be applied universally. Yes but browsers not supporting the new feature would simply post the username and password without using any authentication method. However those fields are suppressed if no the name attribute isn't used. Thus using a new attribute has my preference. Also to allow building a work around for non-conforming browser which will exists for many years to come even is this feature finds it way into the spec. > > I'm more thinking of a way to initiate the http authentication in html > instead of as a browser popup. This allows for the author to define the > user experience in the same way they do for cookie-based authentication > which people have come to expect and trust. > > I was thinking the authentication would not be applied to all forms, but > just as a replacement for the login form. After successful login the UA > would continue to apply the Authorization headers to each subsequent > request, until shutdown or logout. I would expect no less. Otherwise this exercise is rather useless. -- Dave Kok
Re: [whatwg] Session Management
On 3/11/11, Dave Kok wrote: > This may very well be a natural consequence of having a proposal like > this implemented. But this would assume that implementers feel that > having a logout button embedded into documents is considered superior > then having a UA provided logout button. Otherwise such a thing would > never happen. Also authors have the freedom to use either a custom > authentication method or a UA provided authentication method. Though I > too prefer the UA provided authentication method we can't force authors > to do so. A UA provided logout button alone thus not cover custom Authors shouldn't be able to force users to use their homebrew (NIH, anyone?) authentication UI instead of the familiar one my browser of choice sports. Whatever you do, don't encourage authors to use authentication methods that my UA doesn't understand, and will thus not be able to provide an interface for.
Re: [whatwg] Session Management
On 10/06/2011, at 2:12 PM, Dave Kok wrote: > I very much like the header type as a generic feature but would suggest not > using it for HTTP authorization. As for user-agents to support it through > forms have to use special processing anyways. So I would suggest simply > declaring it on the form element itself as an attribute. When using > XMLHttpRequest one already has the ability to supply credentials with the > open > function. So when using a input elements without a form element there is no > need for an authorization feature. Also I would suggest that the attribute > does not have a value or that it is at least optional and when supplied is > only a hint to the user-agent. I most definitely concur the usefulness of header fields :) The problem with authentication is it's pre-existing complexity and getting existing technologies to converge in a unified way. The attraction to this is that with the base extensions to forms it seems like the ability to declare authentication is only a short step away, and it's complexity provides a thorough use case for identifying the necessary specification edge cases. > Ultimately a user-agent must use whatever > method required by the server not the method defined by the author. A user- > agent can transparently find out which method to use with a HEAD request. Or > if > transport layer security is used simply guess one and see if it works and try > again if it doesn't. I'm not sure i agree. The server has served up the page so ultimately it is in control. If the author specifies something which the server can not handle, that's just an authoring bug is it not? I also don't think an agent should be making any guesses...this would definitely seem to violate the authority to define the modus operandi. > > Also binding the username and password input fields to the authorization > header > should properly not be done by reserving names in the name attribute of the > input field. I would suggest using a special purpose attribute like > authorization to declare their binding. Otherwise authors have to cope with > reserved names which is properly unacceptable backwards-compatible wise. > > > > > > > > > > > > > > > -- > Dave Kok > But, in reference to backwards compatibility, the authorization must be explicitly declared so this wouldn't be applied universally. I'm more thinking of a way to initiate the http authentication in html instead of as a browser popup. This allows for the author to define the user experience in the same way they do for cookie-based authentication which people have come to expect and trust. I was thinking the authentication would not be applied to all forms, but just as a replacement for the login form. After successful login the UA would continue to apply the Authorization headers to each subsequent request, until shutdown or logout. thanks, cameron jones > Op vrijdag 10 juni 2011 14:25:07 schreef u: >> 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
Re: [whatwg] Session Management
I very much like the header type as a generic feature but would suggest not using it for HTTP authorization. As for user-agents to support it through forms have to use special processing anyways. So I would suggest simply declaring it on the form element itself as an attribute. When using XMLHttpRequest one already has the ability to supply credentials with the open function. So when using a input elements without a form element there is no need for an authorization feature. Also I would suggest that the attribute does not have a value or that it is at least optional and when supplied is only a hint to the user-agent. Ultimately a user-agent must use whatever method required by the server not the method defined by the author. A user- agent can transparently find out which method to use with a HEAD request. Or if transport layer security is used simply guess one and see if it works and try again if it doesn't. Also binding the username and password input fields to the authorization header should properly not be done by reserving names in the name attribute of the input field. I would suggest using a special purpose attribute like authorization to declare their binding. Otherwise authors have to cope with reserved names which is properly unacceptable backwards-compatible wise. -- Dave Kok Op vrijdag 10 juni 2011 14:25:07 schreef u: > 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
Re: [whatwg] Session Management
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
Re: [whatwg] Session Management
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,
Re: [whatwg] Session Management
Op 10-03-11 20:02:26 schreef Bjartur Thorlacius: >On 3/3/11, Dave Kok wrote: >> Here is a more formal proposal for Session Management. Hoping to get >> more traction. >> >Your former proposal was very well formed. The only thing I don't see >is a good use case making this proposal worthy of endorsement and >implementation. The use case, as I imagine it, is mostly for web applications. I noticed that WHATWG also maintains a web application spec containing HTML5. I wasn't aware of it, I thought it was the same spec. This feature may better fit within that spec then HTML5. But I'll leave that to the spec writers. For web sites that have no defined workflow and thus every document has it's own merit for existing there may not be a use case. However 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. 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. This proposal simply provides for a fine-grained method of clean up after the web site/application much like an OS does for a desktop applications. Having such a method also paves the way better resource management by UA and perhaps better separation between web sites/applications. For instance one can imagine a UA imposing more security by not allowing documents from a different origin (and optionally path) access to any session data including reusing cached credentials. In the case of off line applications (using the CACHE MANIFEST) it may even be of interest to have a session survive even beyond the UA itself terminating and only have it end when sessionEnd is called. (Just wild thoughts outside the scope of this proposal.) >> >> SCOPE >> >> The proposal is restricted solely the HTML5 spec. Though in the >> rational HTTP and authentication are mentioned as by example. >> >Fair enough. > >> >> RATIONAL >> >> The rational of this feature is to provide an easy method to clean >> session data/state after it is no longer required. How and when >> session data is cleaned when sessionStart is never called is not >> specified by this proposal. Implementers are encouraged to ignore >> any calls to sessionEnd if sessionStart has never been called. They >> may off course emit a warning/notice to aid an author in debugging. >> >Blame my ignorance, but I haven't got this straight yet: >When is sessionEnd supposed to be called? Is it for garbage >collection? Is it to be called before a user hands a public UA >(public terminal) over to another user? Think of sessionEnd as terminating a regular desktop application. Like the user clicking on the close button in the upper right corner. However the user doesn't use it directly but an author can use it at an appropriate place within a web site/application. Please note that sessionEnd is not meant to be a security feature. UA's can not rely on this to provide better security. Thus in the case of a public terminal some other method must be used to ensure session data has been cleared before switching users (if this is at all possible). But it may help a UA to determine what needs to be cleaned. Also as the proposal is currently formulated an author may request a session to automatically end when the user navigates away from the origin (and optional path) of the web site/application. In this case the UA triggers the sessionEnd on it own. Alternatively if a UA provides a logout button this may too trigger sessionEnd. In the case of public terminals it may be interesting to force the auto_end feature. >> 3. The user follows a link on which to author registered a onclick >> event handler. The event handler calls sessionEnd. The UA now >> unreferences any session data associated with the session, event >> handler ends and the UA loads the document indicated by the link. On >> a side note this may very well be superior to a UA UI logout >> button. As the author can also specify a URL to go to after the >> session has ended. A UA UI logout button may not be able to do this >> in a meaningful way. >> >This is were we disagree. >I find it annoying to
Re: [whatwg] Session Management
On 3/3/11, Dave Kok wrote: > Here is a more formal proposal for Session Management. Hoping to get > more traction. > Your former proposal was very well formed. The only thing I don't see is a good use case making this proposal worthy of endorsement and implementation. > > SCOPE > > The proposal is restricted solely the HTML5 spec. Though in the > rational HTTP and authentication are mentioned as by example. > Fair enough. > > 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. > > > Prototype: > window.sessionStart([string path = "/", [boolean auto_end = false]]); > > The session start function should indicate to the UA that a new session > is requested by the author for the current browsing context. From this > point forward any session data should be associated with this session. > However this is only done for documents loaded from the same origin or > if a path is supplied for that path and sub paths of that path within > the current origin. The auto_end argument may be supplied if a session > should automatically end when the user navigates away from documents > within the origin[/path]. > Are authentication mechanisms guaranteed to use origins as defined by HTML? Or are UAs to apply unobvious criteria to credential discarding? > > Prototype: > window.sessionEnd([boolean clearHistory = false]); > > The session end function should indicate to the UA that the current > session is no longer valid. The UA can now stop associating session > data with this session and unreference any session data associated with > this session. The clearHistory parameter requests the UA, if true, to > clear any documents within the back/forward history that have been > loaded between session start and session end. UA's are only encouraged > to do this for documents that required authentication and for which re- > authentication is required after sessionEnd. This to prevent > unauthorized access to cached documents by using the back/forward > functionality to access information that would otherwise require > authentication. > > > Session data: > > What a UA considers session data in the context of this proposal is > for a UA to decide but at minimal it is required to include data stored > in the sessionStorage and cookies created through the document.cookie > interface without expiration and any credentials supplied through the > XMLHttpRequest.open function if the UA manages these. Additionally > a UA is encouraged to include any cookies received without expiration > from any source especially when made available through the > document.cookie interface pertaining to the current origin[/path]. Any > credentials that are cached for documents within origin[/path] and > additional resources referenced by these documents whether or not > within the origin[/path]. But only if the UA marks these for auto > cleaning when the UA itself terminates. > > > Ending sessions > > A UA is never required to wait until the sessionEnd is called before > it ends a session and cleans associated data/state. But is encouraged > not to selectively clean session data/state while sessionEnd has not > been called. In others words all or nothing is preferred. A session is > automatically ended when a current browsing context is closed. A UA may > also have additional methods to force a session to end. > > > RATIONAL > > The rational of this feature is to provide an easy method to clean > session data/state after it is no longer required. How and when session > data is cleaned when sessionStart is never called is not specified by > this proposal. Implementers are encouraged to ignore any calls to > sessionEnd if sessionStart has never been called. They may off course > emit a warning/notice to aid an author in debugging. > Blame my ignorance, but I haven't got this straight yet: When is sessionEnd supposed to be called? Is it for garbage collection? Is it to be called before a user hands a public UA (public terminal) over to another user? > Basic usage scenario: > 1. The user has navigated to a document and follows a link on which the > author registered a onclick event and the event handler calls > sessionStart. The UA now creates a new session, event handler ends and > the UA loads the indicated document. If this document is within the > scope of the session and authentication is required and no prior > credentials exists, it gathers these credentials either from an > external source or from the user and associates these with the > session if it intends to dispose of these automatically when the UA > itself terminates. > 2. The user reads, clicks, types and follows links to other documents > within the same origin[/path]. Possibly causing additional session data > to be associated with this session. > 3. The user follows a link on which to author registered a
[whatwg] Session Management
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. Prototype: window.sessionStart([string path = "/", [boolean auto_end = false]]); The session start function should indicate to the UA that a new session is requested by the author for the current browsing context. From this point forward any session data should be associated with this session. However this is only done for documents loaded from the same origin or if a path is supplied for that path and sub paths of that path within the current origin. The auto_end argument may be supplied if a session should automatically end when the user navigates away from documents within the origin[/path]. Prototype: window.sessionEnd([boolean clearHistory = false]); The session end function should indicate to the UA that the current session is no longer valid. The UA can now stop associating session data with this session and unreference any session data associated with this session. The clearHistory parameter requests the UA, if true, to clear any documents within the back/forward history that have been loaded between session start and session end. UA's are only encouraged to do this for documents that required authentication and for which re- authentication is required after sessionEnd. This to prevent unauthorized access to cached documents by using the back/forward functionality to access information that would otherwise require authentication. Session data: What a UA considers session data in the context of this proposal is for a UA to decide but at minimal it is required to include data stored in the sessionStorage and cookies created through the document.cookie interface without expiration and any credentials supplied through the XMLHttpRequest.open function if the UA manages these. Additionally a UA is encouraged to include any cookies received without expiration from any source especially when made available through the document.cookie interface pertaining to the current origin[/path]. Any credentials that are cached for documents within origin[/path] and additional resources referenced by these documents whether or not within the origin[/path]. But only if the UA marks these for auto cleaning when the UA itself terminates. Ending sessions A UA is never required to wait until the sessionEnd is called before it ends a session and cleans associated data/state. But is encouraged not to selectively clean session data/state while sessionEnd has not been called. In others words all or nothing is preferred. A session is automatically ended when a current browsing context is closed. A UA may also have additional methods to force a session to end. RATIONAL The rational of this feature is to provide an easy method to clean session data/state after it is no longer required. How and when session data is cleaned when sessionStart is never called is not specified by this proposal. Implementers are encouraged to ignore any calls to sessionEnd if sessionStart has never been called. They may off course emit a warning/notice to aid an author in debugging. Basic usage scenario: 1. The user has navigated to a document and follows a link on which the author registered a onclick event and the event handler calls sessionStart. The UA now creates a new session, event handler ends and the UA loads the indicated document. If this document is within the scope of the session and authentication is required and no prior credentials exists, it gathers these credentials either from an external source or from the user and associates these with the session if it intends to dispose of these automatically when the UA itself terminates. 2. The user reads, clicks, types and follows links to other documents within the same origin[/path]. Possibly causing additional session data to be associated with this session. 3. The user follows a link on which to author registered a onclick event handler. The event handler calls sessionEnd. The UA now unreferences any session data associated with the session, event handler ends and the UA loads the document indicated by the link. On a side note this may very well be superior to a UA UI logout button. As the author can also specify a URL to go to after the session has ended. A UA UI logout button may not be able to do this in a meaningful way. What if's: 1. the user follows a link, clicks on a bookmark or enters a URL outside the origin[/path] for the current session. If auto_end was set to true. The session is ended as in step 3 of above scenario. 2. a session has been started with aut
Re: [whatwg] Session Management
Op 03-03-11 12:17:22 schreef Roger Hågensen:
>On 2011-03-03 10:44, Dave Kok wrote:
>> Op 02-03-11 22:11:48 schreef Roger Hågensen:
>>> Method #3:
>>> The server (or serverside script, like PHP or similar) sends the
>>> following to the browser:
>>> header('HTTP/1.0 401 Unauthorized');
>>> header('WWW-Authenticate: Close realm="My Realm"');
>>> *PS! the auth stuff is much longer here obviously, this was
>just
>>> to show the use of "Close"*
>>>
>>> Note:
>>> If Method 1 or 2 is used the browser should probably send the
>>> following
>>>
>>> to the server:
>>> GET /private/index.html HTTP/1.1
>>> Authorization: Close username="something"
>>> *PS! the auth stuff is much longer here obviously, this was
>just
>>> to show the use of "Close"*
>> May I point out that the HTTP is outside the scope of the HTML5
>> spec.
>> Also the HTTP is stateless. This requires both parties keep state
>which
>> breaks the statelessness property of the HTTP. I, for one, prefer to
>> preserve the statelessness property of HTTP.
>
>"Please appreciate the notion that HTML5 is broader then just browsing
>the internet." - Dave Kok
>
>And indeed it is. HTTP Authentication (especially Digest) is far from
>stateless,
>it's state chances with every single nonce number change.
>It's basically a constant (but very cheap cpuwise)
>handshake/hmac/diffie-hellman agreement.
>Also if you are thinking about the HTTP status codes, those are beyond
>stateless,
>but if you insist, then simply re-use the 403 with some minor tweaks
> so
>
>it acts as a logoff,
>because re-using 401 would break the statelessness as you say.
>
>I'm surprised you advocate ajax/XMLHttpRequest and allow to close from
>a
>form,
>that would open up to some security issues.
>The beauty of HTTP Digest Authentication is that the password is never
>sent as plaintext or in any form that can compromise the user's
>password.
>Only the user themself (and thus indirectly the browser) or the server
>should be able to initiate a session close of Auth Digest,
>allowing it to close from a script is just bad, and... dare I say it,
>counter to the statelessness of HTTP *laughs*
>
>At least we agree on one thing, that where HTTPS is not available or
>where the site owners have either not discovered or is too lazy or
>unable to take advantage of StartSSL.com which is free,
>then HTTP Digest Authentication should almost be a requirement for any
>site that need login credentials. (like forums, shops etc.)
>Funny how many stores only pull out the HTTPS stuff when paying for
>things you buy (or use a specialist service), but not at all when you
>log in to your account with them otherwise. *sigh*
>
>Heck, I even have https on my own little site, my hoster provided the
>ip
>for free, they set up the certificate etc, for free, excellent
> service.
>
>(I only pay the hoster a small yearly fee, domeneshop.no for you
>Norwegians out there)
>and combine that with startssl.com and my total cost of "securing" the
>communication with my site should I ever need it or others need
>it??? PRICELESS, since it was absolutely free, not a single cent
>paid.
>But... a lot of web hotels or hosters out there do not allow you to do
>SSL or it costs extra, or they can not give you a ip or it costs
> extra,
>
>and, and, and.
>So I have sympathy for those unable to. but hey with the CA that
>provides free domain/server certs there is no excuse if you ARE able
>to,
>and programmingwise it's less work too, Auth Digest needs some extra
>massaging from PHP to work nicely in a "integrated" way but even then
>the logout issue still exist (and even if you "log out" the sie is
>still
>spammed by the browser with login credentials all the time)
>I've never really worked with the Apache auth_digest stuff, but it's
>probably even more restricted than doing it yourself via PHP.
>
>And don't forget that you complain that my suggestions messed with
> HTTP
>
>which HTML5 had no business to mess with,
>yet you yourself suggested XMLHttpRequest and some ajax stuff to
>close/end a HTTP authentication?
>This already proves that HTML5 isn't just HTML + CSS + Javascript +
>lots
>of other stuff, but we can also add + HTTP
>Now if this Auth Digest is so important for web apps, then shouldn't
>WHATWG work together with (um what is the HTTP group called?)
>
>
>--
>Roger "Rescator" Hågensen.
>Freelancer - http://www.EmSai.net/
>
>
Hmm, within the scope of this feature request I am not advocating AJAX.
Just mentioned it as it can be used to login, see XMLHttpRequest.open.
It allows for a username and password to be passed in. Personally
however I prefer to let the UA handle this. Please note that at
XMLHttpRequest.open level nothing is known of HTTP or whether HTTP-
basic or HTTP-digest is used. To me this is an issue to be solved at
a layer lower then HTML5. And whether HTTP, FTP or some other protocol
is used to transfer data and do authentication it pretty muc
Re: [whatwg] Session Management
On 2011-03-03 10:44, Dave Kok wrote:
Op 02-03-11 22:11:48 schreef Roger Hågensen:
Method #3:
The server (or serverside script, like PHP or similar) sends the
following to the browser:
header('HTTP/1.0 401 Unauthorized');
header('WWW-Authenticate: Close realm="My Realm"');
*PS! the auth stuff is much longer here obviously, this was just
to show the use of "Close"*
Note:
If Method 1 or 2 is used the browser should probably send the
following
to the server:
GET /private/index.html HTTP/1.1
Authorization: Close username="something"
*PS! the auth stuff is much longer here obviously, this was just
to show the use of "Close"*
May I point out that the HTTP is outside the scope of the HTML5 spec.
Also the HTTP is stateless. This requires both parties keep state which
breaks the statelessness property of the HTTP. I, for one, prefer to
preserve the statelessness property of HTTP.
"Please appreciate the notion that HTML5 is broader then just browsing
the internet." - Dave Kok
And indeed it is. HTTP Authentication (especially Digest) is far from
stateless,
it's state chances with every single nonce number change.
It's basically a constant (but very cheap cpuwise)
handshake/hmac/diffie-hellman agreement.
Also if you are thinking about the HTTP status codes, those are beyond
stateless,
but if you insist, then simply re-use the 403 with some minor tweaks so
it acts as a logoff,
because re-using 401 would break the statelessness as you say.
I'm surprised you advocate ajax/XMLHttpRequest and allow to close from a
form,
that would open up to some security issues.
The beauty of HTTP Digest Authentication is that the password is never
sent as plaintext or in any form that can compromise the user's password.
Only the user themself (and thus indirectly the browser) or the server
should be able to initiate a session close of Auth Digest,
allowing it to close from a script is just bad, and... dare I say it,
counter to the statelessness of HTTP *laughs*
At least we agree on one thing, that where HTTPS is not available or
where the site owners have either not discovered or is too lazy or
unable to take advantage of StartSSL.com which is free,
then HTTP Digest Authentication should almost be a requirement for any
site that need login credentials. (like forums, shops etc.)
Funny how many stores only pull out the HTTPS stuff when paying for
things you buy (or use a specialist service), but not at all when you
log in to your account with them otherwise. *sigh*
Heck, I even have https on my own little site, my hoster provided the ip
for free, they set up the certificate etc, for free, excellent service.
(I only pay the hoster a small yearly fee, domeneshop.no for you
Norwegians out there)
and combine that with startssl.com and my total cost of "securing" the
communication with my site should I ever need it or others need
it??? PRICELESS, since it was absolutely free, not a single cent paid.
But... a lot of web hotels or hosters out there do not allow you to do
SSL or it costs extra, or they can not give you a ip or it costs extra,
and, and, and.
So I have sympathy for those unable to. but hey with the CA that
provides free domain/server certs there is no excuse if you ARE able to,
and programmingwise it's less work too, Auth Digest needs some extra
massaging from PHP to work nicely in a "integrated" way but even then
the logout issue still exist (and even if you "log out" the sie is still
spammed by the browser with login credentials all the time)
I've never really worked with the Apache auth_digest stuff, but it's
probably even more restricted than doing it yourself via PHP.
And don't forget that you complain that my suggestions messed with HTTP
which HTML5 had no business to mess with,
yet you yourself suggested XMLHttpRequest and some ajax stuff to
close/end a HTTP authentication?
This already proves that HTML5 isn't just HTML + CSS + Javascript + lots
of other stuff, but we can also add + HTTP
Now if this Auth Digest is so important for web apps, then shouldn't
WHATWG work together with (um what is the HTTP group called?)
--
Roger "Rescator" Hågensen.
Freelancer - http://www.EmSai.net/
Re: [whatwg] Session Management
Op 02-03-11 22:11:48 schreef Roger Hågensen:
>Method #3:
>The server (or serverside script, like PHP or similar) sends the
>following to the browser:
> header('HTTP/1.0 401 Unauthorized');
> header('WWW-Authenticate: Close realm="My Realm"');
> *PS! the auth stuff is much longer here obviously, this was just
> to show the use of "Close"*
>
>Note:
>If Method 1 or 2 is used the browser should probably send the
>following
>
>to the server:
> GET /private/index.html HTTP/1.1
> Authorization: Close username="something"
> *PS! the auth stuff is much longer here obviously, this was just
> to show the use of "Close"*
>
May I point out that the HTTP is outside the scope of the HTML5 spec.
Also the HTTP is stateless. This requires both parties keep state which
breaks the statelessness property of the HTTP. I, for one, prefer to
preserve the statelessness property of HTTP.
Re: [whatwg] Session Management
02-03-11 18:42:41 schreef Bjartur Thorlacius: >On 3/2/11, Dave Kok wrote: >> Op 02-03-11 13:16:11 schreef Bjartur Thorlacius: >>>On 3/2/11, Dave Kok 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? >> >> 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 beg to differ. When credentials have been entered, it may be > feasible >to cache them as long as they're valid. In fact, writing autologin >daemons, renewing security tokens periodically, is on my to-do list. So what does your argument boil down to. Having a method that a site can communicate to a UA that a session starts and ends, means that a UA can not provide a feature to keep a user always logged in? And because this interests you such a feature should not be included in the spec? Even for those UA's that do not have such a feature or in which it is very much desirable to have such a feature. Isn't it simply more interesting to say that a site may communicate when a session starts and ends and that a UA behaves the way a user wants it to (or a developer of the UA, proxy or what not, designed it to do). Whether this means clearing credentials or not. As far as I am concerned all that a site needs to know about, is about a session. And all it should be able to do is tell the UA when it starts or ends. Does having such a feature make it impossible for you to implement what you intend to? > >> Simple use case description: >> - user navigates to start page of site, no authentication required, >> site knows session starts and tells UA. >> - user follows link to other page on same site, requiring >> authentication, UA associates credentials with current session (if >> it >> exists) somewhere hidden in the background. >> - user follows link named logout for instance. Site knows >> session ends and tells UA. UA now clears credentials cached between >You're suggesting that documents *should* duplicate UA functionality? >So I can use inconsistent UIs specific to each site, rather than >customizable UI that works with all sites? > >This is not a use case that should be catered to specifically. No no no, there is no duplication. A UA doesn't manage sessions. Sites manage sessions. All a UA does is cleanup when it knows sessionStorage, session cookies and cached credentials are not going to be used any more or when a user requests those to be cleaned. A site enters stuff in the sessionStorage and creates session cookies when it needs to. And if it hampers functionality of the site cleans these thing up so if the user wishes to end and start a new session without opening a new window it gets a clean session. The only thing which makes the session unclean is those credentials still hanging around somewhere. Personally I just don't understand why you aren't thrilled about having this feature. It sounds like you are very infested in HTTP authentication. If all sites where to use it this would definitely broaden your scope for what you are doing. I just don't see how having a form of session control added to the spec restricts a UA in anyway of providing any feature a user desires. Just because a site says: 'UA session ends', doesn't mean that the UA has to do anything. Only those things that are sensible for the user experience. And for those UA's for which it is sensible to clear cached authentication tokens, they can do so. For those for which it is no
Re: [whatwg] Session Management
On 2011-03-02 18:42, Bjartur Thorlacius wrote:
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.
Yes but do they? Theory is nice but can't a site aid a user in this?
If neither the sysadmin, nor the user, clear the credentials - who will?
This specifically is probably the main use case for expiring auth tokens.
Three Ways...
Method #1:
Browser timeout. For legacy reasons the browser could default to within
a sensible min/max timeout.
Once the timeout is triggered, the HTTP Authentication is ended, and the
the user has to log in again.
Like say maybe 30 minutes to 60 minutes.
This can easily be done right now for all current browsers. No UI
changes or any real code changes at all.
Note:
Ideally the user should be able to adjust the default timeout within
some sensible min/max range,
but this would require a UI change/addition.
Method #2:
A second way to "logout" from a HTTP Authentication would be to end the
HTTP Authentication when the LAST tab or window is closed that is using
the authentication to that site/directory.
Note:
It's a shame one can not use javascript to let the webdesigner provide a
button or url with "javascript:window.close()" or similar.
Perhaps a "javascript:crypto.httpauth_closesession()" or similar could
be added in the future.
Method #3:
The server (or serverside script, like PHP or similar) sends the
following to the browser:
header('HTTP/1.0 401 Unauthorized');
header('WWW-Authenticate: Close realm="My Realm"');
*PS! the auth stuff is much longer here obviously, this was just to
show the use of "Close"*
Note:
If Method 1 or 2 is used the browser should probably send the following
to the server:
GET /private/index.html HTTP/1.1
Authorization: Close username="something"
*PS! the auth stuff is much longer here obviously, this was just to
show the use of "Close"*
I think that Method 3 is the real key piece here, on it's own it allows
the server to "timeout" the client/user AND notify the client that this
has happen.
combined with Method 1 and 2 it is now possible for either the client or
browser to end the http authentication session and notify each other,
and let the user know as well.
Method 3 alone would not need a UI change, it would simply instruct the
browser to clear it's auth session, the page content itself could hold a
message from the server to the user that they are now logged out.
Explained as easily as possible, the closing is exactly the same as
serverside "WWW-Authenticate: Digest" and clientside "Authorization:
Digest" but
instead of the word Digest it is replaced with Close, the rest of the
auth should otherwise be just like a normal Digest auth to ensure it's
not a fake close.
just doing "WWW-Authenticate: Close" might be an issue with future
improvements beyond Digest method, so maybe "WWW-Authenticate: Close
Digest " would make more sense.
Just avoid calling it "Digest Close" as that could be confused with a
normal "Digest".
"Close" is just an example, "End" or "Quit" or "Clear" could just as
well be used, the word doesn't matter, the hint brings from the server
to the browser is the vital key though.
It is basically the server saying to the browser that "those session
credentials are no longer valid, please stop spamming me with them"
*laughs* at which point the browser clears the auth session,
and starts talking to the site with a clean slate again. If something
like Method 3 was implemented then I'm pretty sure that the devs of
phpBB, vBulletin and who knows how many CMS devs out there would be
happy to support this.
Sidesubject:
Hopefully the old WWW-Authenticate: Basic is fully deprecated soon as it
is no different from plaintext html login forms (almost all forums and
websites out there that do not use SSL/certificates).
WWW-Authenticate: Digest should be minimum requirement. I'm not sure but
I believe that Opera did fix some of the issue with Basic being fallen
back to, no idea how all browsers lay on this currently.
It would be tempting to fix the Basic issue and security "hole" by
instead changing things so that it's called: "WWW-Authenticate2: Digest"
and "WWW-Authenticate2: Close Digest" where Basic is not allowed at all,
this would prevent exploits that try to sneak Basic into the header and
make the browser use plain text instead.
--
Roger "Rescator" Hågensen.
Freelancer - http://www.EmSai.net/
Re: [whatwg] Session Management
On 3/2/11, Dave Kok wrote: > Op 02-03-11 13:16:11 schreef Bjartur Thorlacius: >>On 3/2/11, Dave Kok 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? > > 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 beg to differ. When credentials have been entered, it may be feasible to cache them as long as they're valid. In fact, writing autologin daemons, renewing security tokens periodically, is on my to-do list. > Simple use case description: > - user navigates to start page of site, no authentication required, > site knows session starts and tells UA. > - user follows link to other page on same site, requiring > authentication, UA associates credentials with current session (if it > exists) somewhere hidden in the background. > - user follows link named logout for instance. Site knows > session ends and tells UA. UA now clears credentials cached between You're suggesting that documents *should* duplicate UA functionality? So I can use inconsistent UIs specific to each site, rather than customizable UI that works with all sites? This is not a use case that should be catered to specifically. > session start and session end. Note UA is still managing the > credentials not the site. Site has no knowledge of the credentials in > any way as this is all handled within the HTTP protocol. The site > doesn't even sees the credentials. > - Alternative session end is when the user navigates away from origin > (as specified in session start) or closes the browser window. > >>Ultimately, UAs must be able to discard all credentials (from all, or >>a specific site) upon a single command. > > Yes, and this is unrelated to my feature request. I am not requested > UA's should be disallowed to do this. > >>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. > > Yes but do they? Theory is nice but can't a site aid a user in this? > If neither the sysadmin, nor the user, clear the credentials - who will? This specifically is probably the main use case for expiring auth tokens. >>> [..] 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 no
Re: [whatwg] Session Management
Op 02-03-11 13:16:11 schreef Bjartur Thorlacius: >On 3/2/11, Dave Kok 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? 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? Simple use case description: - user navigates to start page of site, no authentication required, site knows session starts and tells UA. - user follows link to other page on same site, requiring authentication, UA associates credentials with current session (if it exists) somewhere hidden in the background. - user follows link named logout for instance. Site knows session ends and tells UA. UA now clears credentials cached between session start and session end. Note UA is still managing the credentials not the site. Site has no knowledge of the credentials in any way as this is all handled within the HTTP protocol. The site doesn't even sees the credentials. - Alternative session end is when the user navigates away from origin (as specified in session start) or closes the browser window. >Ultimately, UAs must be able to discard all credentials (from all, or >a specific site) upon a single command. Yes, and this is unrelated to my feature request. I am not requested UA's should be disallowed to do this. >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. Yes but do they? Theory is nice but can't a site aid a user in this? >> [..] 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. Yes, that is why I included a alternative session ending. In my original proposal. And no where that I propose UA's do not 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 di
Re: [whatwg] Session Management
On 3/2/11, Dave Kok 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 t
Re: [whatwg] Session Management
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. 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? 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. > > >> 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. > > >> 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. > >This is an interesting idea. I recommend following the steps described >here to see if it can get traction: > >http://wiki.whatwg.org/wiki/ > FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F Looking
Re: [whatwg] Session Management
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 -Boris
Re: [whatwg] Session Management
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. > 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? > 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. This is an interesting idea. I recommend following the steps described here to see if it can get traction: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Session Management
Hi Subscribers, I am not sure if I am at the right mailing list for this. But I was wondering if it would be beneficial to have some kind of session control feature in the Web Applications spec. Currently the spec defines sessionStorage which I think is a great. It allows me to stop using cookies and maintaining session state completely in the browser. However I am still faced with the fact that there is no way to clear the HTTP authentication credentials cache. I prefer to use HTTP authentication mostly as it is build-in anyways and has richer features then pure form-based authentication. 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 would be interested to know if such a feature would be worth considering. Looking forward to comments and possibly a discussion. Regards, Dave Kok
