Change from 1.5.5 to 1.6.2 results in authentication failure.

[michaelsafyan]

We have some code that successfully talks to a Google API using v1.5.5 but breaks under v1.6.2 with the following error:

"Request is missing required authentication credential. Expected OAuth 2 access token, login cookie or other valid authentication credential"

Our build statement looks like:

 return build(
     'monitoring',
     'v3',
     discoveryServiceUrl=discovery_url,
     developerKey=self.api_key,
     credentials=credentials)

I'm wondering if the following commit may be culprit here:

https://github.com/google/google-api-python-client/commit/068eb35c9a70e31a42f04d5cb69c36d59e4a2a69

Because we supply both "credentials" and "developerKey" and expect the bearer token / other context from the credentials to be propagated regardless of the presence of "developerKey" (it was my understanding that "developerKey" simply adds a "key=" to the discovery URL and to the API requests, but the headers implied by the credentials should still be provided in this case).

Can you fix this? Thanks!

[theacodes]

@michaelsafyan which API are you using that requires both a developer key and credentials?

[theacodes]

Oh, I see, monitoring. You can just leave out the developer key, the monitoring API does not use it.

[michaelsafyan]

The developerKey is needed for visibility labels.

[michaelsafyan]

Looking in more detail, it looks like the API key is needed on the discovery URL but not on subsequent API calls which only need the HTTP bearer token.

[michaelsafyan]

We can workaround by dropping developerKey and manually appending the API key to the discovery URL (building the discovery URL ourselves rather than relying on the client library to construct the discovery URL), but it would be ideal if this worked correctly without that workaround.

[michaelsafyan]

I should also add, on top of the above, that if both a developerKey and credentials object are supplied but only one of the two is applied, wouldn't credential make more sense? Typically credentials include more authority than a simple API key. It may also make sense to log a warning/error to make this condition easier to debug (it took about two days to figure out the issue was in the client library version, not a result of IAM permissions or other causes).

[theacodes]

Looking in more detail, it looks like the API key is needed on the discovery URL but not on subsequent API calls which only need the HTTP bearer token.

Weird, developerKey should only be needed there for non-public (alpha/beta/EAP) APIs.

I should also add, on top of the above, that if both a developerKey and credentials object are supplied but only one of the two is applied, wouldn't credential make more sense? Typically credentials include more authority than a simple API key. It may also make sense to log a warning/error to make this condition easier to debug (it took about two days to figure out the issue was in the client library version, not a result of IAM permissions or other causes).

Yeah, absolutely. This is a bit tricky. :) I agree it should either apply both or error.

[michaelsafyan]

Just to clarify, it is a non-public API (the Monitoring API includes both publicly released portions as well as portions that are restricted behind visibility labels). I'm currently working on a team that is iterating towards an EAP on one of these subsets of the API, and the code that broke is demo client code that uses only the external client library code to demo / test / verify the functioning of this part of the API.

[adeboor]

I'm having trouble understanding why the client changed this way, as the change is breaking my ability to call Google Drive's API. Credentials and API keys can serve the same purpose, but they also can serve different purposes for some APIs, like Drive's: the API key associates the request with a GCP project, telling the API what quotas to apply, while the credentials determine the user whose permissions should be applied in accessing the individual files / folders. With this change, I cannot supply both, which means I cannot actually use the Drive API anymore.

If I comment out the assertion and the check for whether a developerKey has been provided, the code works just fine: it sets the credentials on the request, and it passes the developer key in the calls.

[theacodes]

@adeboor this was a misunderstanding on my part. I'll send a PR and make a release to fix this.