Hi, we recently started using the OAuth2 Java API in order to migrate from GoogleAnalytics v2 API to v3. However, I just discovered that we never explicitly requested offline access as part of our process: new GoogleAuthorizationCodeRequestUrl(CLIENT_ID, AUTH_URL, serviceScopes) .setState(state) .build();
However, we do receive refresh tokens when validating the authorization code: GoogleTokenResponse response = new GoogleAuthorizationCodeTokenRequest(netHttpTransport, jacksonFactory, CLIENT_ID, CLIENT_SECRET, authCode, AUTH_URL).execute(); response.getRefreshToken(); //Not null
Although I plan to fix the code for the offline access for future use, should we re-request new refresh-tokens, do they risk becoming invalid in any way the way they were created? With some of our tokens, we sometimes receive "invalid_grant" errors, but not all of them, could it be related or does it just mean the client revoked access? I though the fact that we do receive refresh-token indicated that we were granted offline access.
If it can have any impact our application is registered as an "Installed" application.
Thanks for any details/reassurance you could provide.
By default installed apps receive offline access (whereas web apps by
default get online access). I've recently updated the JavaDoc to specify
that, whereas previously the JavaDoc said online access is always the
default which is incorrect.
So the good news is that if you have a refresh token you are all set, you
do indeed have offline access, and don't need to re-request new refresh
tokens.
I don't know why you are sometimes getting "invalid_grant" errors. Those
can be tricky to debug.
And yes, there is a maximum # of refresh tokens the same application can
have with the same account. As far as I know this is not documented
anywhere, but it is in the order of 10s of refresh tokens. After a certain
# they simply invalidate the old ones. So it is very important that if you
are using refresh tokens that you store them in a persistent store.
On Thursday, September 13, 2012, Simon Berthiaume wrote:
> On a related note, is there a maximum number of RefreshToken the same
> application (same public+secret ID) can have with the same rights on the
> same account? Someone on our side seems to have registered multiple time
> the same Google Account (about 90 times :-/). It's something we allowed
> because it wouldn't cause issues with the old username+password
> authentication.
> Simon B.
> On Thursday, September 13, 2012 2:09:11 PM UTC-4, Simon Berthiaume wrote:
>> Hi, we recently started using the OAuth2 Java API in order to migrate
>> from GoogleAnalytics v2 API to v3. However, I just discovered that we never
>> explicitly requested offline access as part of our process:
>> new GoogleAuthorizationCodeRequest**Url(CLIENT_ID, AUTH_URL,
>> serviceScopes)
>> .setState(state)
>> .build();
>> However, we do receive refresh tokens when validating the authorization
>> code:
>> GoogleTokenResponse response = new GoogleAuthorizationCodeTokenRe
>> **quest(netHttpTransport, jacksonFactory,
>> CLIENT_ID, CLIENT_SECRET, authCode,
>> AUTH_URL).execute();
>> response.getRefreshToken(); //Not null
>> Although I plan to fix the code for the offline access for future use,
>> should we re-request new refresh-tokens, do they risk becoming invalid in
>> any way the way they were created? With some of our tokens, we sometimes
>> receive "invalid_grant" errors, but not all of them, could it be related or
>> does it just mean the client revoked access? I though the fact that we do
>> receive refresh-token indicated that we were granted offline access.
>> If it can have any impact our application is registered as an "Installed"
>> application.
>> Thanks for any details/reassurance you could provide.
As for the number of tokens, we do persist the tokens, the problem is we allow the same GA account to be "added" multiple times and each had their own token; I'm not too worried about that one, it shouldn't be too hard to fix.
Thanks for the very fast answer and if it can help document the "feature", from the empirical evidence I gathered, the number of refresh tokens would be around 20 ;)
Simon B.
On Friday, September 14, 2012 7:40:01 AM UTC-4, יניב ענבר Yaniv Inbar wrote:
> By default installed apps receive offline access (whereas web apps by > default get online access). I've recently updated the JavaDoc to specify > that, whereas previously the JavaDoc said online access is always the > default which is incorrect.
> So the good news is that if you have a refresh token you are all set, you > do indeed have offline access, and don't need to re-request new refresh > tokens.
> I don't know why you are sometimes getting "invalid_grant" errors. Those > can be tricky to debug.
> And yes, there is a maximum # of refresh tokens the same application can > have with the same account. As far as I know this is not documented > anywhere, but it is in the order of 10s of refresh tokens. After a certain > # they simply invalidate the old ones. So it is very important that if you > are using refresh tokens that you store them in a persistent store.
> -- Yaniv
> On Thursday, September 13, 2012, Simon Berthiaume wrote:
>> On a related note, is there a maximum number of RefreshToken the same >> application (same public+secret ID) can have with the same rights on the >> same account? Someone on our side seems to have registered multiple time >> the same Google Account (about 90 times :-/). It's something we allowed >> because it wouldn't cause issues with the old username+password >> authentication.
>> Simon B.
>> On Thursday, September 13, 2012 2:09:11 PM UTC-4, Simon Berthiaume wrote:
>>> Hi, we recently started using the OAuth2 Java API in order to migrate >>> from GoogleAnalytics v2 API to v3. However, I just discovered that we never >>> explicitly requested offline access as part of our process:
>>> new GoogleAuthorizationCodeRequest**Url(CLIENT_ID, AUTH_URL, >>> serviceScopes)
>>> .setState(state)
>>> .build();
>>> However, we do receive refresh tokens when validating the authorization >>> code:
>>> GoogleTokenResponse response = new GoogleAuthorizationCodeTokenRe
>>> **quest(netHttpTransport, jacksonFactory,
>>> CLIENT_ID, CLIENT_SECRET, authCode, >>> AUTH_URL).execute();
>>> response.getRefreshToken(); //Not null
>>> Although I plan to fix the code for the offline access for future use, >>> should we re-request new refresh-tokens, do they risk becoming invalid in >>> any way the way they were created? With some of our tokens, we sometimes >>> receive "invalid_grant" errors, but not all of them, could it be related or >>> does it just mean the client revoked access? I though the fact that we do >>> receive refresh-token indicated that we were granted offline access.
>>> If it can have any impact our application is registered as an >>> "Installed" application.
>>> Thanks for any details/reassurance you could provide.
Can you please provide proper steps to use Url shortner API with google app engine.
I really can't understand about "API key" and AuthToken.
I have used your sample code for URL Shortner using java.
But I am getting this error : "
> By default installed apps receive offline access (whereas web apps by > default get online access). I've recently updated the JavaDoc to specify > that, whereas previously the JavaDoc said online access is always the > default which is incorrect.
> So the good news is that if you have a refresh token you are all set, you > do indeed have offline access, and don't need to re-request new refresh > tokens.
> I don't know why you are sometimes getting "invalid_grant" errors. Those > can be tricky to debug.
> And yes, there is a maximum # of refresh tokens the same application can > have with the same account. As far as I know this is not documented > anywhere, but it is in the order of 10s of refresh tokens. After a certain > # they simply invalidate the old ones. So it is very important that if you > are using refresh tokens that you store them in a persistent store.
> -- Yaniv
> On Thursday, September 13, 2012, Simon Berthiaume wrote:
>> On a related note, is there a maximum number of RefreshToken the same >> application (same public+secret ID) can have with the same rights on the >> same account? Someone on our side seems to have registered multiple time >> the same Google Account (about 90 times :-/). It's something we allowed >> because it wouldn't cause issues with the old username+password >> authentication.
>> Simon B.
>> On Thursday, September 13, 2012 2:09:11 PM UTC-4, Simon Berthiaume wrote:
>>> Hi, we recently started using the OAuth2 Java API in order to migrate >>> from GoogleAnalytics v2 API to v3. However, I just discovered that we never >>> explicitly requested offline access as part of our process:
>>> new GoogleAuthorizationCodeRequest**Url(CLIENT_ID, AUTH_URL, >>> serviceScopes)
>>> .setState(state)
>>> .build();
>>> However, we do receive refresh tokens when validating the authorization >>> code:
>>> GoogleTokenResponse response = new GoogleAuthorizationCodeTokenRe
>>> **quest(netHttpTransport, jacksonFactory,
>>> CLIENT_ID, CLIENT_SECRET, authCode, >>> AUTH_URL).execute();
>>> response.getRefreshToken(); //Not null
>>> Although I plan to fix the code for the offline access for future use, >>> should we re-request new refresh-tokens, do they risk becoming invalid in >>> any way the way they were created? With some of our tokens, we sometimes >>> receive "invalid_grant" errors, but not all of them, could it be related or >>> does it just mean the client revoked access? I though the fact that we do >>> receive refresh-token indicated that we were granted offline access.
>>> If it can have any impact our application is registered as an >>> "Installed" application.
>>> Thanks for any details/reassurance you could provide.
