W3C home > Mailing lists > Public > www-forms@w3.org > September 2010

base64 encoding for HTTP Basic Authentication - a gap in the XForms function library? (RFE)

From: C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>
Date: Sat, 11 Sep 2010 09:06:18 -0600
Message-Id: <B59CB449-C39A-491F-AF86-5C4D715B2774@blackmesatech.com>
To: www-forms@w3.org
Cc: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>
When a submission resource is protected by HTTP Basic
Authentication, some existing XForms implementations (or,
quite possibly, the browsers they are running in) prompt
the user for a userid and password and use them to supply
an appropriate HTTP Authorization header.  For other
implementations, this does not happen and a form author
may need or wish to supply the header field using the
xf:header element.

The value needed takes the form of the string 'Basic ',
concatenated with the base64 encoding of the concatenation
of the username, a colon, and the user's password.

Unless I'm missing something, however, neither the XPath
Functions and Operators nor XForms provide a function that
can perform the required base64 encoding.  All XForms processors
already possess the required functionality if they implement
the digest() function, since the result of the MD5 or SHA-n
hashing must be base64 encoded, but there is no way (that I've
seen) to obtain base64 encoding on a simple Unicode or ASCII
string.

It's easy enough to implement a base64 encoding routine in
any environment supporting user extensions, but it seems to
this user that it would be convenient to be able to do this
without relying on a non-standard extension function.

Would it be a good idea to provide a suitable new keyword for
the second argument of digest()?

I assume the process to be described by that new keyword is
almost, but not quite, an identity function, since the
characters in the XForms document will be ISO 10646 / Unicode
UCS characters, and I assume that the HTTP specs all work in
ASCII (or rather, in octets, but in any case not in UCS code
points), and the process defined by the new keyword will
need to do whatever the HTTP specs (and existing users and
browsers and servers) expect when non-ASCII characters appear
in a username or password.

If there is another way to address this problem, I'll be
happy to learn about it.

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************
Received on Saturday, 11 September 2010 15:03:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:21 GMT