6:04 a.m.
On Aug 27, 2013, at 3:39 AM, Sebastien Blanc <scm.blanc(a)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 ?
I'm not sure if that is what this is going to do. This is more of an Authorization
thing and i don't think it totally fits the pipeline stuff. ( or it would make it a
bit more complicated, and we want to keep it simple )
i should probably change the method to be "authorize" instead
Seb
On Mon, Aug 26, 2013 at 8:05 PM, Lucas Holmquist <lholmqui(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev