[whatwg] Session Management

[Cameron Heavon-Jones]

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

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