Basic authentication for XForms submission

  This message completes action 
http://lists.w3.org/Archives/Public/public-forms/2010Sep/att-0026/2010-09-15.html#ACTION3

I was asked to see if XHR can accept dynamic authentication for HTTP.
I believe the answer is yes, both in practice, and in the XHR CR.

In the face of all this implementability in common desktop browsers, I 
believe that we can safely resume our discussion of clear syntax for 
providing authentication information to submission.

BACKGROUND:
In last week's meeting we discussed [1] base64 encoding for HTTP Basic 
Authentication.

I noted that there is already an HTTP URI syntax for expressing 
authentication information, and that it is independent of the 
authentication mechanism used.
http://user:pass@host.example.com/path/to/resource

Therefore, the following should work just fine for passing 
authentication information:

<submission ... >
<resource value = "concat('http://', instance('secrets')/user, ':', 
instance('secrets')/password', '@hostname.example.com/path/to/resource')" />
</submission>
or
<load show="replace">
<resource value = "concat('http://', instance('secrets')/user, ':', 
instance('secrets')/password', '@hostname.example.com/path/to/resource')" />
</load>

However, there are two concerns at play here:

1. Security concerns normally dictate that such URIs not be stored in 
plain text, but it's important to note that the URI is not serialized in 
that form in HTTP; instead, the serialization depends on the 
authentication mechanism used by the user agent and server.  It's 
possible that at some future date, this usage, benign though it is, 
might be seen as a security risk under a blanket ban.

2. The syntax is cumbersome and the lack of support for relative URIs is 
problematic.

To answer these concerns, I proposed we consider allowing an equivalent 
representation of submission/resource and load/resource which would be 
equivalent to providing the authentication information in an HTTP URI, 
but which would ease the security concern, provide a less-cumbersome 
syntax which supports relative URIs, and work with schemes other than HTTP"

<resource user="instance('secrets')/user" 
password="instance('secrets')/password">/path/to/resource</user>
or
<resource value="/path/to/data" user="instance('secrets')/user" 
password="instance('secrets')/password" />

where in this example the base URI provides http://hostname.example.com.

This proposal uncomfortably overloads the binding sites on the resource 
element with additional XPath expressions. Additionally, it doesn't 
provide for a clear role for the Domain or Realm, which is used in some 
authentication schemes.

Another proposal added username and password static attributes and 
dynamic child elements to teh submission and load elements, but this 
proposal has the problem that the authentication information is not tied 
closely to the submission resource; there may be other URIs used in 
submission (such as access control) in the future, and I believe we 
should tie the authentication information closely to the resource URI.

We've made no progress on this aspect of the discussion; however, the 
question came up as to whether this plumbing actually works and I was 
assiged ACTION13 to investigate.


RESULTS:
My experiments, folk research, and specification-reading show that the 
ability to provide authentication information to XHR is supported:

1. In experiments, I was able to set up a basic-auth protected page at 
http://xformstest.org/cgi-bin-protected/echo.sh username test password 
test and successfully modified a copy of XSLTForms to access it by 
specifying test:test@ additionally in the test form's 
submission/resource.  See 
http://xformstest.org/klotz/2010/09/auth/index.xml .  The one problem I 
found is that instead of getting xforms-submit-error in the case of of 
present-but-wrong authentication information, you get a browser basic 
auth dialog box.

2. As for folk research, Blog user 'awinanand' reports [2] that the XHR 
setRequestHeader ("Authorization", base64encode("user:pass")) mechanism 
is supported, and gives a variety of sources for JavaScript and offline 
base64 conversion.

3. As for specifications, I found that the XHR Candidate Recommendation 
documents XHR setRequestHeader [3] and XHR open with username and 
password arguments [4], though it is hazy on whether support is 
required.  Given that #1 already works and XHR is already in Candidate 
Rec, I did not do any tests on the XHR open with username and password 
arguments, because I believe the implementability question is already 
answered.

[1] 
http://lists.w3.org/Archives/Public/public-forms/2010Sep/att-0026/2010-09-15.html#topic12
[2] http://www.aswinanand.com/2009/01/http-basic-authentication-using-ajax/
[3] http://www.w3.org/TR/XMLHttpRequest/#the-setrequestheader-method
[4] http://www.w3.org/TR/XMLHttpRequest/#request-username

Leigh.

Received on Wednesday, 22 September 2010 17:55:42 UTC