dev@jersey.java.net

Re: [Jersey] Jersey-OAuth implementation

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Tue, 05 May 2009 11:40:35 +0200

On May 5, 2009, at 1:57 AM, Paul C. Bryan wrote:

> Hi Devs:
>
> I've created a new branch:
>
> https://jersey.dev.java.net/svn/jersey/branches/oauth-extensions/
>
> In this branch, I've checked-in the initial code dump for the OAuth
> digital signature library, including an initial unit test:
>
> jersey/contribs/jersey-oauth/oauth-sig/
>
> As I'm relatively new to Jersey and Maven, I would appreciate some
> feedback on whether I got this right, or if the work is in need of
> revision.
>

Looks OK. The only main thing is when we merge with the trunk the
version number of the oauth modules should be the same as that for the
modules in the trunk i.e. all modules are in sync.


I notice you checked in a class to support base 64 encoding.

I recently added one to the jersey-core module, so you could reuse
that if you wish (and modify that to suite your requirements):

   https://jersey.dev.java.net/nonav/apidocs/1.1.0-ea/jersey/com/sun/jersey/core/util/Base64.html


The jersey core also contains utilities to encode/decode components
URIs:

   https://jersey.dev.java.net/nonav/apidocs/1.1.0-ea/jersey/com/sun/jersey/api/uri/UriComponent.html

So rather than:

                buf.append('&').append(URLCodec.encode(constructRequestURL(request)));

you could do:

                 
buf
.append('&').append(UriComponent.encode(constructRequestURL(request),
UriComponent.Type.QUERY));

But i understand why you might be cautious as canonicalizing stuff is
so very sensitive to errors.

Jersey also contains URI building functionality, so one does not need
to utilize string buffers, but i am not sure that is suitable in your
case, given that URI building utilizes templates (however, we can
modify the implementation in Jersey as required).

Paul.