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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

C. M. Sperberg-McQueen-2
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
****************************************************************





Reply | Threaded
Open this post in threaded view
|

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

Ronald van Kuijk-4
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:[hidden email]/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:[hidden email]]
To: [hidden email]
Cc: C. M. Sperberg-McQueen [mailto:[hidden email]]
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
****************************************************************





Reply | Threaded
Open this post in threaded view
|

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

Erik Bruchez
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
<[hidden email]> 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@.../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:[hidden email]]
> To: [hidden email]
> Cc: C. M. Sperberg-McQueen [mailto:[hidden email]]
> 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
> ****************************************************************
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

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

C. M. Sperberg-McQueen-2

On 12 Sep 2010, at 20:08 , Erik Bruchez wrote:

> I would agree with both:
>
> * Higher-level support is in general desirable to make the form
> author's life easier.

As a would-be form author, I can only say hear, hear!  I would
very much like my life to be made easier!

But I hope the long-term goal of making the form author's life
easier doesn't get in the way of providing the tools necessary to
allow a certain amount of self-help in the meantime.  I'd rather
solve my problem by using xf:header elements than by writing
new Java code for my task, if I possibly can!

Michael Sperberg-McQueen

--
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************





Reply | Threaded
Open this post in threaded view
|

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

Ronald van Kuijk-4
In reply to this post by C. M. Sperberg-McQueen-2
----- Original Message -----
From: C. M. Sperberg-McQueen [mailto:[hidden email]]
To: Erik Bruchez [mailto:[hidden email]]
Cc: C. M. Sperberg-McQueen [mailto:[hidden email]], [hidden email]
Sent: Mon, 13 Sep 2010 22:08:51 +0200
Subject: Re: base64 encoding for HTTP Basic Authentication - a gap in the  XForms function library? (RFE)


>
> On 12 Sep 2010, at 20:08 , Erik Bruchez wrote:
>
> > I would agree with both:
> >
> > * Higher-level support is in general desirable to make the form
> > author's life easier.
>
> As a would-be form author, I can only say hear, hear!  I would
> very much like my life to be made easier!
>

And we are all willing to help. This kind of feedback is valuable (imo)

> But I hope the long-term goal of making the form author's life
> easier doesn't get in the way of providing the tools necessary to
> allow a certain amount of self-help in the meantime.  I'd rather
> solve my problem by using xf:header elements than by writing
> new Java code for my task, if I possibly can!
>

You don't have to. For Orbeon Erik or one of the other dev's did this. For betterFORM I'll be the one to do this for you.

Again, this kind of feedback about what is missing in the implementation in the eye of  'would be form authors' ;-)
 
Cheers,

Ronald van Kuijk