Hi Łukasz 2010/7/26 Łukasz Moreń <lukasz.mo...@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 with 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, it 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 <sberyoz...@gmail.com>: > > Hi Łukasz > > > > 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 education > > point of view it is a good demo and it is handy one does not even has to > > 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/rs/ > ? > > 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 module > can > > depend on it without specifying a version and have the demo client module > > 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 looks > > complicated enough :-) but I think it makes sense to me. I'll likely ask > for > > some modifications but perhaps if you could start with updating the demo > > such that a consumer initiates its own registration with the OAuth server > : > > 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 be > 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, Łukasz Moreń <lukasz.mo...@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 > >> > > >
