[whatwg] Session Management

[Dave Kok]

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.
> > 
> > <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.

> 
> 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