Re: base64 encoding for HTTP Basic Authentication - a gap in the XForms function library? (RFE)
Erik Bruchez <[email protected]> Sun, 12 Sep 2010 19:08:23 -0700
| Newsgroups | gmane.comp.web.xforms |
|---|---|
| Message-ID | <[email protected]> |
I would agree with both: * Higher-level support is in general desirable to make the form author's life easier. * Any serious work with XForms in practice requires a more complete function library than what is provided currently. In Orbeon we have tended to implement these as extension functions on a need basis [1]. -Erik [1] http://wiki.orbeon.com/forms/doc/developer-guide/xforms-xpath-functions On Sat, Sep 11, 2010 at 8:38 AM, Ronald van Kuijk <[email protected]> wrote: > 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:[email protected]/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:[email protected]] > To: [email protected] > Cc: C. M. Sperberg-McQueen [mailto:[email protected]] > 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 > **************************************************************** > > > > > >