Hi Dan, Thanks for the reply, I am following user mailing list. I read through the dev mailing list, its interesting. It will be awesome if oAuth gets delivered as part of this usecase.
oAuth2 please have a look at libraries like oauth-jersey-client or Apache OLTU or Spring oAuth and yes Scribe is also good option. Mainly oAuth is used in Integration Projects (connecting 2 different systems). When it comes the oAuth client, its very simple you just need to follow the handshake process implemented by respective oAuth Serivice providers in above case context.io. In general they follow the spec, http://tools.ietf.org/html/rfc6749 To Save the trouble here is a quick gist on oAuth 2 client side explanation. (please read the documentation for detailed explanation below is the explanation based on my work done on oAuth) 1) oAuth2 is hosted service provided by a 3rd party for authentication through which once authenticated one can access the resources. 2) So one has to register for the service. All it requires is what is the external app which is trying to connect to its system and its *callback url*(this url which is hosted on the user side) is used in the authentication process. 3) Once registered, there is an *App Id* generated for identifying the application as such, then you will be given an *Client ID and Client Secret.* 4) In general there will be 3 urls for oAuth flow, (lets take google as an example, if required i can give you salesforce example as well) 1. https://accounts.google.com/o/oauth2/auth -- This is the authorizaiton URL provided by google 2. https://accounts.google.com/o/oauth2/token -- This is the token generation URL provided by google 3. http://localhost:9070/api/ga/oauthcallback -- This is the oauth call back URL hosted on the users end. (There are other options which can be set during the flow which i am not getting in to those details) 5) Handshake happens like this, 1. Make an Authorize request with client credentials, this will go and check whether our external app is up and running with the help of callback url. 2. Once done it will prompt for App Access with proper permissions like you see in facebook with "Allow" and "Deny" buttons. 3. Once you say Allow, it is redirected to the callback URL with a code. 4. Using the code, client credentials and token url we will get a Refresh Token as well as an Access Token. 5. Refresh token is equivalent to your password and access token is a short lived resource using which we can access the external system protected resource. 6. From here on you just require Refresh Token to generate access token to establish API to API communication from back-end. So any scheduling jobs or background jobs do not require an end user interaction. All in all this is the story of Client Side of oAuth. Sorry for this huge email, i thought i could help :) Building a client as such should be outside of WicketViewer on top of RestfulViewer. Or we need to write a custom component in wicket or servlet. I couldn't get much time in starting the project due to other work deliverables. HTH -Sunand On Thu, Mar 20, 2014 at 3:30 PM, Dan Haywood <[email protected]>wrote: > Sunand, > > Appreciate that no-one answered this posting of yours. > > Don't know if you've been following the Isis dev mailing list also, but > there's a thread [1] there discussing integrating Isis with context.io[2], > which also requires solving the oauth integration. > > I'm still not clear (myself) on how this would work, but hopeful that it's > doable one way or the other... > > Dan > > [1] http://markmail.org/thread/4ilfxcc2aoxy7nfw > [2] http://context.io > > > > On 18 February 2014 18:07, sunand p <[email protected]> wrote: > >> Hi All, >> >> I already have a thread running StackOverflow >> >> http://stackoverflow.com/questions/21547063/apache-isis-extending-rest-service >> , >> As per Dan's suggestion I am raising this topic in users list. Please Read >> through and let me know your suggestions, for a quick and short >> explanation >> on what i want to do, here is the gist >> >> "Let me explain with an example, ga-dev-tools.appspot.com/explorer once >> you >> open this link you will see a query explorer for Google Analytics API. In >> order to execute the Query first we need to Authorize Access which is a >> button on top right, once clicked it opens an external window with an URL >> (oAuth flow happens). Once we get token then we can fire a query and fetch >> the result. I want to build a web app similarly for other providers like >> LinkedIn, Salesforce, Facebook. All i need to do is store the connection >> properties make an oAuth call fetch the token and access the resources. >> Do you think Isis doesn't fit the above requirement? I feel that an >> External Link feature of Apache Wicket should suffice the requirement. >> Also >> redirecting it back to the original page. For fetching http response i can >> use apache http client and consume the entity." >> >> - Sunand >> > >
