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

Martin,

Personally I do not think the form author should have the need to know all these kinds of submission protocol related technical things and should be allowed to just rely on functional elements

Using e.g. http://username:password@host.domain.tld/path/... for absolute resources or adding a username and password attribute to the submission element makes more sense. These are (almost as) easy to implement as adding a base64 encoding function. I implemented the first one in less than an hour for betterFORM and know the second example is already supported at least by Orbeon[1] and I'm working on it now for betterFORM[2]. So I would suggest to focus on these two options instead of the (relatively) more complex use of headers.

Cheers,

Ronald

[1] http://wiki.orbeon.com/forms/doc/developer-guide/xforms-advanced-submissions#TOC-HTTP-authentication
[2] http://sourceforge.net/mailarchive/message.php?msg_name=20100911140526.716a0cb4%40mail.intercommit.nl
  _____  

From: C. M. Sperberg-McQueen [mailto:cmsmcq@blackmesatech.com]
To: www-forms@w3.org
Cc: C. M. Sperberg-McQueen [mailto:cmsmcq@blackmesatech.com]
Sent: Sat, 11 Sep 2010 17:06:18 +0200
Subject: base64 encoding for HTTP Basic Authentication - a gap in the XForms function library? (RFE)

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