Most services do have a shared database, but not all of them. I continued investigating this issue, and I've also tried the Service Account approach which uses a private key instead of getting an authorization through a browser URL. However, this keeps giving me a "bad grant" exception if I try to actually use the credential, so I am not sure what I am doing wrong there.
On Thursday, September 27, 2012 3:34:38 PM UTC-4, Oliver wrote: > > Excellent questions, and I hope someone can answer them soon. > > Do your servcies not access a shared database to store a common token to > be used by all services? > > Oliver > > On Thursday, September 27, 2012 7:24:50 PM UTC+1, j.e.frank wrote: >> >> I'm looking at migrating to the new Java client library as part of the >> upgrade from v201109. One thing I thought was going to be a benefit of >> this migration was long-lived access tokens, to enable long-running >> services to use the API without having to worry about refreshing the >> ClientLogin token. Now that I've done some more digging, it appears that >> OAuth2 doesn't have long-lived tokens. Instead, you get an access token >> and a refresh token, and there is some way that an expired access token >> gets refreshed behind the scenes. >> >> I'm unclear on the implications of this for how I can deploy multiple >> services that use the API without any user interaction. I have >> successfully followed the OAuth2 example to get an authorization code using >> a browser, and then I can take that code and get a credential with an >> access and refresh token. Subsequently, I can create an OAuth2 credential >> from these 2 tokens, without using the browser to get a new authorization >> code. However, this doesn't work after some period of time -- I have to >> start over and get a new authorization code using the browser. I've seen >> reference to the CredentialsStore where you keep track of new >> access/refresh tokens as they change, which would be fine for a single >> service to manage. But with multiple services, would I need a centralized >> CredentialsStore that they would all share, so that each one gets the >> latest token? That's a non-starter for me. Is there something I'm missing >> about how I can use OAuth2 with multiple long-lived services? Otherwise I >> am going to continue with ClientLogin, and give up on my dream of >> non-expiring tokens. Or is there some way of re-obtaining an authorization >> token without user interaction? >> > -- =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Also find us on our blog and discussion group: http://adwordsapi.blogspot.com http://groups.google.com/group/adwords-api =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ You received this message because you are subscribed to the Google Groups "AdWords API Forum" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/adwords-api?hl=en
