You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Can not use 'my-api-key' on google.cloud.translate API. translate may support OAuth2 now? #2903
client = translate.Client('my API Key is given')
...
DefaultCredentialsError: Could not automatically determine credentials. Please set GOOGLE_APPLICATION_CREDENTIALS or
explicitly create credential and re-run the application. For more
information, please see https://developers.google.com/accounts/docs/application-default-credentials.
I just guess , now only OAuth2 is supported by translate API. Because of some information. Should the Doc updates or am I wrong ?
Help on class Client in module google.cloud.translate.client:
class Client(google.cloud.client.Client)
| Client to bundle configuration needed for API requests.
|
...
| :type credentials: :class:oauth2client.client.OAuth2Credentials
| :param credentials: (Optional) The OAuth2 Credentials to use for the
| connection owned by this client. If not passed (and
| if no http object is passed), falls back to the
| default inferred from the environment.
...
| Methods defined here:
|
| init(self, target_language='en', credentials=None, http=None)
@hidehara, I believe that it was always intended that Translate use Service Accounts.
Only recently was Service Account support added to the upstream Translate service.
@hidehara We elected to drop support for API key auth as a "library decision" but the backend still supports it. The auth doc linked to by @daspecster should have everything needed to authenticate. It's incorrect to say you must use a service account, you can also use OAuth 2.0 based credentials for user accounts. For deployed applications however, we strongly recommend the use of a service account.
The release listed the dropped feature, though maybe this wasn't clear enough?
Activity
daspecster commentedon Dec 28, 2016
@hidehara I'm sorry you ran into trouble with this!
I'll get a PR to update the docs going right now.
Support for the API key was removed via #2823 and released in 0.22.0.
The prefered way to authenticate is with service accounts. Which we do have docs explaining how to set that up here: https://googlecloudplatform.github.io/google-cloud-python/stable/google-cloud-auth.html.
hidehara commentedon Dec 28, 2016
@daspecster Thanks for nice reply.
I have a question , why API-Key was removed ?
Is that based on Google Cloud Translate life cycle OR just new policy of google-cloud-python ?
If you have any information, please let's me know.
I read #2823 , so I understand that I should use OAuth2 from 0.22.0.
daspecster commentedon Dec 28, 2016
Anytime!
@hidehara, I believe that it was always intended that Translate use Service Accounts.
Only recently was Service Account support added to the upstream Translate service.
@jonparrott or @dhermes would know more about it I'm sure.
hidehara commentedon Dec 28, 2016
@daspecster , Oh, sorry about type of Account.
I succeed to use translate with 'Service Accounts' by using following sytle.
I confused to use which type of Account , cause of help(translate.Client). But now I'm OK to use Service Account.
If Google will still support API-Key , It's easy & best way for me (;
Thanks for kind information.
dhermes commentedon Dec 28, 2016
@hidehara We elected to drop support for API key auth as a "library decision" but the backend still supports it. The auth doc linked to by @daspecster should have everything needed to authenticate. It's incorrect to say you must use a service account, you can also use OAuth 2.0 based credentials for user accounts. For deployed applications however, we strongly recommend the use of a service account.
The release listed the dropped feature, though maybe this wasn't clear enough?
hidehara commentedon Jan 6, 2017
@dhermes Thanks for above. I'm clear now.
I got background of "library decision" and the backend still supports API Key auth.
I succeed to use a service account, so I may implement with it.