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
 209.85.214.41 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=Wh7OyK3bOSlzoenTED4LHQNivnKnB0LG5cYtX7rUHgyizWpB3KWIEVt/ikzoxe7hTz
         H0rVaG3ijtJOWFkfHb1UEbOu9jkhwF0wi79ZhZdPZAokaMvv7G4tldvPm4uJZyDI+ewV
         IyKFeGDwtmudWbuLMTotzL4dSFDvr48zpI6U4=
MIME-Version: 1.0
In-Reply-To: <AANLkTi=6qXdY2tXQ_mm0poLM+VxF0xVHfu=_4+w6dZEd@mail.gmail.com>
References: <AANLkTil0ssNOR6yeaE1FX8GpC0Y8TdMMWM93sCsuRE-K@mail.gmail.com>
	<AANLkTi=rQ91DXLN8d37F0VT4WMGpNrUSdiOJqNfg8m6g@mail.gmail.com>
	<AANLkTi=6qXdY2tXQ_mm0poLM+VxF0xVHfu=_4+w6dZEd@mail.gmail.com>
Date: Mon, 26 Jul 2010 12:11:18 +0100
Message-ID: <AANLkTik6B2fHaDPw3d++zthSoF+XrJ6DzWdBU=_oYnv7@mail.gmail.com>
Subject: Re: OAuth client and server demos
From: Sergey Beryozkin <sberyozkin@gmail.com>
To: dev@cxf.apache.org
Content-Type: multipart/alternative; boundary=0003255557ee981cf9048c4871ea

--0003255557ee981cf9048c4871ea
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Hi =A3ukasz

2010/7/26 =A3ukasz More=F1 <lukasz.moren@gmail.com>

> Hi Sergey,
>
> I'm really sorry for such commit, I know it shouldn't happen. I turned
> off checkstyle as i couldn't configure it properly on intellij and it
> was annoying during development.
> I will apply proper changes ASAP.
>
> no worries at all, I've broken the real builds with checkstyle errors so
many times and it is the CXF sandbox after :-)


> According to the demo, I built it as usual web-app, if it worked, use
> this same sources to deploy on GAE.
> However because of GAE restrictions it always needs minor changes
> before deploy, i.e. GAE can't read configuration files such as:
> cxf-extension-http.xml
> from jars, so I copied it to WEB-INF folder.
> Commited to svn version does not depend on GAE SDK and can be run
> locally with jetty:run.
>
> Yes, I warned about server configuration part:). I will take care to
> make it simpler.
>

I do not think it is too complicated - the simplification can be done once
the whole flow is sound...


> So far, oauth consumer properties are hardcoded and injected into
> oauth provider, as I think it is not oauth library responsibility to
> deal with consumer registration.
> Hovewer for demo it would be good to have something like that. I would
> do registration form at the server as it is done by current big oauth
> implementations.
>

I agree that conceptually the registration of consumers is a separate issue=
.
But it is part of the solution that users will be eventually offering so
just showing them that the consumers have to go and register themselves wit=
h
help people with coming up with some custom registration forms, etc. The
registration does not have to be done at the server hosting the resource, i=
t
is just important for the OAuth provider be able to get to the consumer
details. I'm fine with assuming at the moment that the registration handler
is collocated with the endpoints/providers enforcing OAuth flow.

But the callback uri which is being injected at the moment should go anyway
given that it is part of the actual flow, specifically, the consumer
provides it during the request token request


>
> Recently I've noticed that Camel have done oauth client as well:):
> http://camel.apache.org/tutorial-oauth.html
>
> Thanks much for review, and hints.
>
>
thanks for your effort :-)

Sergey


> Cheers,
> Lukasz
>
>
> 2010/7/24 Sergey Beryozkin <sberyozkin@gmail.com>:
> > Hi =A3ukasz
> >
> > Sorry for a delay,  I should've come back earlier to you.
> >
> > I've run the demo hosted at the app engine and I think from the educati=
on
> > point of view it is a good demo and it is handy one does not even has t=
o
> > build anything in order to try it.
> >
> > I've had a problem building the rt/rs/oauth tests - there's a bunch of
> > CheckStyle errors. Can you please build sandbox/oauth_1.0a from the
> trunk,
> > just do 'mvn install -Pfastinstall' and then do 'mvn install' from rt/r=
s/
> ?
> > One other thing, please move the demo to
> > "distribution/src/main/release/samples/" as well add Readme to it.
> >
> > Also I can not build the demo too, the client build fails with the
> following
> > dependency missing
> > 1) net.oauth.core:oauth-consumer:jar:20100527
> >
> > But I'm seeing an oauth repo in the rt/rs/oauth pom, have you built it =
in
> > the GAE dev environment ?
> >
> > Can you please spend a bit of time on cleaning the build a bit :
> > - fix the checkstyle errors and move the demo to the
> > ""distribution/src/main/release/samples/"" area and also add Readme;
> after
> > building the distribution (mvn install in trunk/distribution) you can
> easily
> > verify the demo can be run by locating in the target.
> > - add the oauth dependency in the parent pom so that the rs/oauth modul=
e
> can
> > depend on it without specifying a version and have the demo client modu=
le
> > depending on rt/rs/oauth module instead (similarly to the server one)
> > - during the main build please use the Spring version CXF depends upon
> and
> > use its -Pspring3 profile to build for the deployment into GAE
> >
> > As far as the demo is concerned. I looked at the server part and it loo=
ks
> > complicated enough :-) but I think it makes sense to me. I'll likely as=
k
> for
> > some modifications but perhaps if you could start with updating the dem=
o
> > such that a consumer initiates its own registration with the OAuth serv=
er
> :
> > I can see at the moment an oauth provider is injected with some sample
> > consumer properties. I'm not sure what is the best way to do it : may b=
e
> the
> > server can return a registration form or the client can just push the
> > registration info itself.
> >
> > Overall I think it is a good progress indeed especially given the
> complexity
> > of the whole effort.
> >
> >
> >
> > thanks, Sergey
> >
> > On Wed, Jul 14, 2010 at 10:14 PM, =A3ukasz More=F1 <lukasz.moren@gmail.=
com
> >wrote:
> >
> >> Hi all,
> >>
> >> I have managed to create two sample OAuth aplications:
> >> ordinary OAuth 1.0a client: http://www.oauthclient.appspot.com
> >> and authorization server that uses CXF OAuth module:
> >> http://www.cxfoauthserver.appspot.com
> >>
> >> Both sample applications and changes in oauth library are commited in
> >> sandbox.
> >>
> >> OAuth configuration in sample authorization server app looks a bit
> >> awfully but I think most of that can be hidden and done out of band.
> >> There is still some areas in specification not covered by
> >> implementation, so I would like to take care of that in next steps.
> >>
> >> Thanks in advance for some feedback.
> >>
> >> Cheers,
> >> Lukasz
> >>
> >
>

--0003255557ee981cf9048c4871ea--