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

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
<rvkuijk@intercommit.nl> 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: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
> ****************************************************************
>
>
>
>
>
>

Received on Monday, 13 September 2010 02:09:18 UTC