- From: Cameron Heavon-Jones <cmhjones@gmail.com>
- Date: Fri, 10 Jun 2011 16:37:59 +0100
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
Received on Friday, 10 June 2011 08:37:59 UTC