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
