Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (nike.apache.org: domain of sberyozkin@gmail.com designates
 74.125.82.177 as permitted sender)
Message-ID: <4E77451F.5000900@gmail.com>
Date: Mon, 19 Sep 2011 14:35:27 +0100
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: dev@cxf.apache.org
Subject: OAuth 1.0 contribution on the trunk
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi

I've been working during the last week exclusively on migrating a GSOC 
2010 contribution from Lukasz Moren to the trunk.
It proved to be a high quality contribution - many thanks to Lukasz.

I've spent most time last week on trying to make things as 
simple/trivial as possible, as far as users trying to come up with their 
own initial OAuth 1.0 applications is concerned. I've tried to bring a 
number of required packages, classes to a bare minimum and remove a 
dependency on the OAuth 1.0 Google lib from interfaces to be implemented 
by users (ex, OAuthDataProvider).

Some basic properties from OAuth 2.0 made it too into the model classes 
as well as some extension properties.

JavaDocs and docs to follow, and some changes to OAuthDataProvider and 
some of the model classes are very likely to happen.

I was not sure if we'd keep OAuth 1.0a and (future) OAuth 2.0 modules 
separately of if we'd replace OAuth 1.0a in time with OAuth 2.0 - 
probably would make sense to get two modules, unless the OAuth 2.0 impl 
would be capable of handling OAuth 1.0 users, so for now I chose to
have
rs/security/oauth-parent
   oauth
   oauth-test

with the 2nd module containing a Memory provider. This one is duplicated 
in a demo as I did not want to have the oauth-test dependency there and 
I think we should write a more interesting DB based provider for a demo 
anyway

Comments are welcome

thanks, Sergey