Hello folks I’ve been thinking about providing a more fluid integration between authz and pipes. Right now to read a list of GoogleDrive document, we need to read the pipe in the success callback of authz’ requestAccess: AGAuthorizer* authorizer = [AGAuthorizer authorizer]; _restAuthzModule = [authorizer authz:^(id<AGAuthzConfig> config) { ... }]; [_restAuthzModule requestAccessSuccess:^(id object) { id<AGPipe> documents = [googleDocuments pipe:^(id<AGPipeConfig> config) { [config setName:@"files"]; [config setAuthzModule:authzModule]; // inject authz }]; [documents read:^(id responseObject) { // do sth with response } failure:^(NSError *error) { // when an error occurs... }]; } failure:^(NSError *error) { NSLog(@"Failure in getting access token"); }]; What about if we just initialize authzModule and inject it into pipe. Once the pipe read (or any crud) it will be the pipe that first fetch tokens (or renew - whaetever is needed) and on success read the pipe. Basically we do the callback chaining internally in the Pipe instead of letting the developer deal with it. AGAuthorizer* authorizer = [AGAuthorizer authorizer]; _restAuthzModule = [authorizer authz:^(id<AGAuthzConfig> config) { ... }]; id<AGPipe> documents = [googleDocuments pipe:^(id<AGPipeConfig> config) { [config setName:@"files"]; [config setAuthzModule:authzModule]; // inject authz }]; [documents read:^(id responseObject) { // do sth with response } failure:^(NSError *error) { // when an error occurs... }]; It feels much fluid on the user. Doing so we “force” the app flow to ask token when it needs it, not in advance at startup of app. but i think this is good practice to lazy authz your app. Thoughts? Test repo can be found here: https://github.com/corinnekrych/aerogear-ios/blob/transparent.refresh/Aer... https://github.com/corinnekrych/aerogear-ios-cookbook-1/blob/AGIOS-145.re... ++ Corinne _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

>Phone:404 941 4698 >Java is my crack.

So seamless refreshing token but declarative token initial request. Right? #agreed seamless refresh decalrative auhz request and revoke request. If we all agree (JS included) I’ll create an iOS JIRA ticket and go for it. JS folks, wdyt? ++ Corinne On 15 May 2014, at 17:44, Summers Pittman <supittma(a)redhat.com&gt; wrote: > I don't like it because it moves the concerns of bad accounts, account creation, authorization lifecycle error handling into the failure method of the pipe callback. Those concerns don't belong there. > > However I am fine with the module refreshing the accesstoken if a refresh token is provided. If an error happens then that is something more "in line" with reasonable expectations for a authorized request. > > > On Thu 15 May 2014 03:56:28 AM EDT, Corinne Krych wrote: >> Hello folks >> >> I’ve been thinking about providing a more fluid integration between authz and pipes. >> >> Right now to read a list of GoogleDrive document, we need to read the pipe in the success callback of authz’ requestAccess: >> >> AGAuthorizer* authorizer = [AGAuthorizer authorizer]; >> _restAuthzModule = [authorizer authz:^(id<AGAuthzConfig> config) { >> ... >> }]; >> >> [_restAuthzModule requestAccessSuccess:^(id object) { >> id<AGPipe> documents = [googleDocuments pipe:^(id<AGPipeConfig> config) { >> [config setName:@"files"]; >> [config setAuthzModule:authzModule]; // inject authz >> }]; >> >> [documents read:^(id responseObject) { >> // do sth with response >> } failure:^(NSError *error) { >> // when an error occurs... >> }]; >> } failure:^(NSError *error) { >> NSLog(@"Failure in getting access token"); >> }]; >> >> What about if we just initialize authzModule and inject it into pipe. Once the pipe read (or any crud) it will be the pipe that first fetch tokens (or renew - whaetever is needed) and on success read the pipe. Basically we do the callback chaining internally in the Pipe instead of letting the developer deal with it. >> >> AGAuthorizer* authorizer = [AGAuthorizer authorizer]; >> _restAuthzModule = [authorizer authz:^(id<AGAuthzConfig> config) { >> ... >> }]; >> >> id<AGPipe> documents = [googleDocuments pipe:^(id<AGPipeConfig> config) { >> [config setName:@"files"]; >> [config setAuthzModule:authzModule]; // inject authz >> }]; >> >> [documents read:^(id responseObject) { >> // do sth with response >> } failure:^(NSError *error) { >> // when an error occurs... >> }]; >> >> It feels much fluid on the user. >> Doing so we “force” the app flow to ask token when it needs it, not in advance at startup of app. but i think this is good practice to lazy authz your app. >> >> Thoughts? >> >> Test repo can be found here: >> https://github.com/corinnekrych/aerogear-ios/blob/transparent.refresh/Aer... >> https://github.com/corinnekrych/aerogear-ios-cookbook-1/blob/AGIOS-145.re... >> >> ++ >> Corinne >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Summers Pittman >>> Phone:404 941 4698 >>> Java is my crack. > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Hello Luke, Our native clients (with Google Drive app) use authz code grant type [1]. With this mode refresh token are issued. Our JS GoogleDrive demo is using implicit grant[2] as recommended for browser based app. In this mode no refresh token is issued and grant should be asked as often as the access token expired (1h for Google). What about hybrid? We could use something like the demo in this blog post[3]. so we can have refresh token too.

wdyt? ++ Corinne [1] http://tools.ietf.org/html/rfc6749#section-4.1 [2] http://tools.ietf.org/html/rfc6749#section-4.2 [3]http://www.itsalif.info/content/oauth-google-api-gapi-phonegap-childbrowser-jquery On 15 May 2014, at 18:12, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > for js we don’t have refresh tokens, for security reasons. > > > I know with googles js api, they do a background refresh( iframe stuff ). > > > go for it > > > On May 15, 2014, at 12:08 PM, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: > >> So seamless refreshing token but declarative token initial request. Right? >> #agreed seamless refresh >> decalrative auhz request and revoke request. >> If we all agree (JS included) I’ll create an iOS JIRA ticket and go for it. >> >> JS folks, wdyt? >> >> ++ >> Corinne >> On 15 May 2014, at 17:44, Summers Pittman <supittma(a)redhat.com&gt; wrote: >> >>> I don't like it because it moves the concerns of bad accounts, account creation, authorization lifecycle error handling into the failure method of the pipe callback. Those concerns don't belong there. >>> >>> However I am fine with the module refreshing the accesstoken if a refresh token is provided. If an error happens then that is something more "in line" with reasonable expectations for a authorized request. >>> >>> >>> On Thu 15 May 2014 03:56:28 AM EDT, Corinne Krych wrote: >>>> Hello folks >>>> >>>> I’ve been thinking about providing a more fluid integration between authz and pipes. >>>> >>>> Right now to read a list of GoogleDrive document, we need to read the pipe in the success callback of authz’ requestAccess: >>>> >>>> AGAuthorizer* authorizer = [AGAuthorizer authorizer]; >>>> _restAuthzModule = [authorizer authz:^(id<AGAuthzConfig> config) { >>>> ... >>>> }]; >>>> >>>> [_restAuthzModule requestAccessSuccess:^(id object) { >>>> id<AGPipe> documents = [googleDocuments pipe:^(id<AGPipeConfig> config) { >>>> [config setName:@"files"]; >>>> [config setAuthzModule:authzModule]; // inject authz >>>> }]; >>>> >>>> [documents read:^(id responseObject) { >>>> // do sth with response >>>> } failure:^(NSError *error) { >>>> // when an error occurs... >>>> }]; >>>> } failure:^(NSError *error) { >>>> NSLog(@"Failure in getting access token"); >>>> }]; >>>> >>>> What about if we just initialize authzModule and inject it into pipe. Once the pipe read (or any crud) it will be the pipe that first fetch tokens (or renew - whaetever is needed) and on success read the pipe. Basically we do the callback chaining internally in the Pipe instead of letting the developer deal with it. >>>> >>>> AGAuthorizer* authorizer = [AGAuthorizer authorizer]; >>>> _restAuthzModule = [authorizer authz:^(id<AGAuthzConfig> config) { >>>> ... >>>> }]; >>>> >>>> id<AGPipe> documents = [googleDocuments pipe:^(id<AGPipeConfig> config) { >>>> [config setName:@"files"]; >>>> [config setAuthzModule:authzModule]; // inject authz >>>> }]; >>>> >>>> [documents read:^(id responseObject) { >>>> // do sth with response >>>> } failure:^(NSError *error) { >>>> // when an error occurs... >>>> }]; >>>> >>>> It feels much fluid on the user. >>>> Doing so we “force” the app flow to ask token when it needs it, not in advance at startup of app. but i think this is good practice to lazy authz your app. >>>> >>>> Thoughts? >>>> >>>> Test repo can be found here: >>>> https://github.com/corinnekrych/aerogear-ios/blob/transparent.refresh/Aer... >>>> https://github.com/corinnekrych/aerogear-ios-cookbook-1/blob/AGIOS-145.re... >>>> >>>> ++ >>>> Corinne >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> -- >>> Summers Pittman >>>>> Phone:404 941 4698 >>>>> Java is my crack. >>> >> >> >> _______________________________________________ >> 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