<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">i've hacked together a sample app that shows sort of the flow.<div><br></div><div><a href="https://github.com/lholmquist/oauth2test">https://github.com/lholmquist/oauth2test</a></div><div><br></div><div>it is still very rough</div><div><br><div><div>On Aug 27, 2013, at 12:42 PM, Bruno Oliveira <<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">+1 keep it simple, please<br><br>Lucas Holmquist wrote:<br><blockquote type="cite"><br>On Aug 27, 2013, at 3:39 AM, Sebastien Blanc <<a href="mailto:scm.blanc@gmail.com">scm.blanc@gmail.com</a><br><<a href="mailto:scm.blanc@gmail.com">mailto:scm.blanc@gmail.com</a>>> wrote:<br><br><blockquote type="cite">Hi,<br>That sounds good !<br>Just one question, instead of using the callApi function couldn't we<br>pass the oauth module (called 'thing' in your example) to the pipe<br>directly, using the 'authenticator' setting. Behind the scene, the<br>pipe manager will append the oauth token to the query or add the<br>bearer header ?<br></blockquote><br>I'm not sure if that is what this is going to do. This is more of an<br>Authorization thing and i don't think it totally fits the pipeline<br>stuff. ( or it would make it a bit more complicated, and we want to keep<br>it simple )<br><br><br> i should probably change the method to be "authorize" instead<br><br><blockquote type="cite">Seb<br><br><br><br>On Mon, Aug 26, 2013 at 8:05 PM, Lucas Holmquist <<a href="mailto:lholmqui@redhat.com">lholmqui@redhat.com</a><br><<a href="mailto:lholmqui@redhat.com">mailto:lholmqui@redhat.com</a>>> wrote:<br><br><br> OAuth2 AeroGear Workflow - High Level<br><br><br> Using Google api's<br><br> /Server Side/<br><br> 1. user needs to first create an "application/project" to get an<br> api key<br> 2. Then they would choose the services/api's then would like<br> there application to access<br> 3. other google server related items....<br><br> /Client Side/<br><br> 1. Create a new OAuth2 module thing<br> 2. Get access token for the services would need to specify the<br> services they would like to access<br> 3. validate the token<br> 4. make calls to the service<br><br><br> API<br><br> |var thing = AerGear.OAuth2({<br> name: googleEndPoints, //Just a Name<br> clientID: "12345" //The client ID of the app from the API console<br> settings: {<br> permissions: "..",<br> ...<br> }<br> }).somecoolmodulename.googleEndPoints;<br> |<br><br> /Settings: Multiple settings based on paramters here<br> <<a href="https://developers.google.com/accounts/docs/OAuth2UserAgent">https://developers.google.com/accounts/docs/OAuth2UserAgent</a>>/<br><br> /Methods/<br><br><br> authenticate<br><br> this will authenticate with the server to get the access token and<br> then validate the token, once that is all good then the response<br> is returned.<br><br> |thing.authenticate({<br> success:{},<br> error:{},<br> settings: {<br> //probably some settings here, like URL overides and such<br> }<br> });<br> |<br><br><br> callApi<br><br> not really a good name, but it would basically call the remote<br> api/services. we could either do a query string option or a Head<br> option<br><br> example:<br><br> |curl '<a href="https://www.googleapis.com/oauth2/v1/userinfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg'">https://www.googleapis.com/oauth2/v1/userinfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg'</a><br> |<br><br> or<br><br> |curl -H "Authorization: Bearer {accessToken}" <a href="https://www.googleapis.com/oauth2/v1/userinfo">https://www.googleapis.com/oauth2/v1/userinfo</a><br> |<br><br> code:<br><br> |thing.callApi({<br> service: "userinfo", //don't really like this name either<br> success:{},<br> error:{},<br> settings: {<br> ... //overridable baseURLs?<br> }<br> });<br> |<br><br><br> revoke<br><br> again, maybe not the best name. calls the "revoke" service, to<br> remove access to permissions<br><br> |thing.revoke({<br> success: {},<br> error: {},<br> settings: {}<br> });<br> |<br><br> Behind the scenes on all these calls, the "access_token" is<br> beining used and possibly refreshed for the user, so they don't<br> have to worry about it. They just need to call authenticate first.<br> Maybe we can have a refresh method if the user wants to refresh<br> the tokens themselves. this would do the token "dance"<br><br><br><br> On Aug 26, 2013, at 1:35 PM, Bruno Oliveira <<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a><br> <<a href="mailto:bruno@abstractj.org">mailto:bruno@abstractj.org</a>>> wrote:<br><br><blockquote type="cite"> +1 I think is a good start to us.<br><br> Kris Borchers wrote:<br><blockquote type="cite"> I would like to see that but what you are saying makes sense. It<br> sounds like where I was headed with the Basic and Digest<br> adapters before I ran into browser security issues with headers.<br> I think and authorization API that basically just wraps itself<br> around secured endpoints works for me.<br></blockquote><br> -- <br> abstractj<br><br><br> _______________________________________________<br> aerogear-dev mailing list<br> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a> <<a href="mailto:aerogear-dev@lists.jboss.org">mailto:aerogear-dev@lists.jboss.org</a>><br> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote><br><br> _______________________________________________<br> aerogear-dev mailing list<br> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a> <<a href="mailto:aerogear-dev@lists.jboss.org">mailto:aerogear-dev@lists.jboss.org</a>><br> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br><br><br>_______________________________________________<br>aerogear-dev mailing list<br><a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a> <<a href="mailto:aerogear-dev@lists.jboss.org">mailto:aerogear-dev@lists.jboss.org</a>><br><a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote><br>_______________________________________________<br>aerogear-dev mailing list<br><a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/aerogear-dev<br></blockquote><br>-- <br>abstractj<br><br><br>_______________________________________________<br>aerogear-dev mailing list<br><a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/aerogear-dev</blockquote></div><br></div></body></html>