Re: Using Apache Isis Can i call an external Http Link and redirect it back to the original Page

[Dan Haywood <da...@haywood-associates.co.uk>]

Thanks for this great write-up of how oAuth works, Sunand.

I'm cc'ing dev for this, and copying it into ISIS-736 and ISIS-739 as a
comment.

https://issues.apache.org/jira/browse/ISIS-736
https://issues.apache.org/jira/browse/ISIS-739



On 22 March 2014 05:16, sunand p <su...@gmail.com> wrote:

> 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 <dan@haywood-associates.co.uk
> > 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 <su...@gmail.com> 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
>>>
>>
>>
>