W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2011

[whatwg] Session Management

From: Cameron Heavon-Jones <cmhjones@gmail.com>
Date: Fri, 10 Jun 2011 16:37:59 +0100
Message-ID: <ECC01FBA-EB44-4ACC-B6A7-DBF2892322FB@gmail.com>

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.

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

thanks for the feedback, will need to mull over this some more :)


cameron jones
Received on Friday, 10 June 2011 08:37:59 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:33 UTC