[aerogear-dev] OAuth2 Adapter

[Sebastien Blanc]

On Tue, Aug 27, 2013 at 10:16 AM, Corinne Krych <corinnekrych at gmail.com>wrote:

> And then to actually do callApi?
> customPipe.call({})
>

No, then just calling our existing functions on the pipe : read, save ...


>
>
> On Aug 27, 2013, at 10:10 AM, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>
> >
> >
> >
> > On Tue, Aug 27, 2013 at 9:56 AM, Corinne Krych <corinnekrych at gmail.com>
> wrote:
> > Indeed it will be less intrusive to do as suggested by Seb.
> > using something like:
> > pipe.call({…})
> >
> > Well, I was more thinking using our actual API, for i.e
> >
> > var customPipe = AeroGear.Pipeline([{
> >
> >     name
> > : "customPipe",
> >
> >     settings
> > : {
> >
> >        authenticator: thing
> >
> >
> > }
> > }]).pipes[0];
> >
> > Still on callAPi section where do we pass the access token? in the
> settings section?
> >
> > I think that after thing.authenticate() we don't have to worry to pass
> the token, it's automagically added.
> >
> > Coud we put the 'service' into settings too?
> >
> > ++
> > Corinne
> >
> > On Aug 27, 2013, at 9:39 AM, Sebastien Blanc <scm.blanc at gmail.com>
> wrote:
> >
> > > Hi,
> > > That sounds good !
> > > Just one question, instead of using the callApi function couldn't we
> pass the oauth module (called 'thing' in your example) to the pipe
> directly, using the 'authenticator' setting. Behind the scene, the pipe
> manager will append the oauth token to the query or add the bearer header ?
> > > Seb
> > >
> > >
> > >
> > > On Mon, Aug 26, 2013 at 8:05 PM, Lucas Holmquist <lholmqui at redhat.com>
> wrote:
> > > OAuth2 AeroGear Workflow - High Level
> > >
> > > Using Google api's
> > >
> > > Server Side
> > >
> > >       • user needs to first create an "application/project" to get an
> api key
> > >       • Then they would choose the services/api's then would like
> there application to access
> > >       • other google server related items....
> > > Client Side
> > >
> > >       • Create a new OAuth2 module thing
> > >       • Get access token for the services would need to specify the
> services they would like to access
> > >       • validate the token
> > >       • make calls to the service
> > > API
> > >
> > > var thing = AerGear.OAuth2({
> > >                 name: googleEndPoints, //Just a Name
> > >                 clientID: "12345" //The client ID of the app from the
> API console
> > >                 settings: {
> > >                     permissions: "..",
> > >                     ...
> > >                 }
> > >             }).somecoolmodulename.googleEndPoints;
> > >
> > > Settings: Multiple settings based on paramters here
> > >
> > > Methods
> > >
> > > authenticate
> > >
> > > this will authenticate with the server to get the access token and
> then validate the token, once that is all good then the response is
> returned.
> > >
> > > thing.authenticate({
> > >     success:{},
> > >     error:{},
> > >     settings: {
> > >         //probably some settings here, like URL overides and such
> > >     }
> > > });
> > >
> > > callApi
> > >
> > > not really a good name, but it would basically call the remote
> api/services. we could either do a query string option or a Head option
> > >
> > > example:
> > >
> > > curl '
> https://www.googleapis.com/oauth2/v1/userinfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg
> '
> > > or
> > >
> > > curl -H "Authorization: Bearer {accessToken}"
> https://www.googleapis.com/oauth2/v1/userinfo
> > > code:
> > >
> > > thing.callApi({
> > >     service: "userinfo", //don't really like this name either
> > >     success:{},
> > >     error:{},
> > >     settings: {
> > >         ... //overridable baseURLs?
> > >     }
> > > });
> > >
> > > revoke
> > >
> > > again, maybe not the best name. calls the "revoke" service, to remove
> access to permissions
> > >
> > > thing.revoke({
> > >     success: {},
> > >     error: {},
> > >     settings: {}
> > > });
> > >
> > > Behind the scenes on all these calls, the "access_token" is beining
> used and possibly refreshed for the user, so they don't have to worry about
> it. They just need to call authenticate first. Maybe we can have a refresh
> method if the user wants to refresh the tokens themselves. this would do
> the token "dance"
> > >
> > >
> > >
> > > On Aug 26, 2013, at 1:35 PM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
> > >
> > >> +1 I think is a good start to us.
> > >>
> > >> Kris Borchers wrote:
> > >>> I would like to see that but what you are saying makes sense. It
> sounds like where I was headed with the Basic and Digest adapters before I
> ran into browser security issues with headers. I think and authorization
> API that basically just wraps itself around secured endpoints works for me.
> > >>
> > >> --
> > >> abstractj
> > >>
> > >>
> > >> _______________________________________________
> > >> aerogear-dev mailing list
> > >> aerogear-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130827/a0d9288b/attachment.html