[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.
> >>> 
> >>> <form method="get" action="/resource" authorize>
> >>> 
> >>> <!-- use custom http header-->
> >>> <input type="header" name="Language" value="en_US">
> >>> 
> >>> <input type="text" authorization="username">
> >>> 
> >>> <input type="password" authorization="password">
> >>> 
> >>> <input type="submit" value="load">
> >>> 
> >>> </form>
> >>> 
> >>> --
> >>> 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 double login screen. First they get the form which 
doesn't do a thing then the server will sent a authorization required and the 
user-agent pop-ups the regular login dialog. Not very pretty but still 
acceptable.

> 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.
Using a new attribute for binding should not change this.

--
Dave Kok

Received on Tuesday, 14 June 2011 02:40:46 UTC