IssueTracker

Problem you have encountered:

(1) We want to require an API key for most of our methods. This as AND requirement along either a Google ID token or a Firebase token. So for almost all our methods we use the following security:

security:
  - google_id_token: [ ]
    api_key: [ ]
  - firebase: [ ]
    api_key: [ ]

(2) For security reasons, we have been asked to avoid the key parameter showing up in logs. So we also want to allow the API key as header x-api-key like this:

securityDefinitions:
  api_key:
    type: "apiKey"
    name: "x-api-key"
    in: "header"

(3) However, we have learned that Endpoints dev portal’s “Try this API” works only with “query”, not with “headers”. If we configured “headers”, we see this error in the “Try this API” box:

"Try this API" is disabled on this method.

Don't worry—only portal admins can see this.

"Try this API" is disabled for users on this page for the following reasons:

Unsupported auth type for "Try this API" - api_key:apiKey.

Furthermore, API key definition limitations states that “one of the following schemes” is required. It sounds like we can use only either "header" or "query" on any method at any given time.

What you expected to happen:

I expected, that defining "header" schema would work with Endpoints dev portal's "Try this API" feature. It does not.

However, only "query" works with the feature. But surprisingly, if we define "query", the portal feature works, and clients can still send the x-api-key header instead of the query.

Although the current behavior is desirable for us, as it meets all our requirements, I feel unsettled because it seems to be in contradiction to the documentation. Maybe the documentation is outdated or could be improved.

I just don’t want us to get problems if this is not supposed to actually work, and a patch on Google’s side could break our deployed APIs.

Can you please confirm, that we can safely rely on this behavior and that it isn't a bug that will be patched away?

Steps to reproduce:

(1) Define this as security definition for API keys:

securityDefinitions:
  api_key:
    type: "apiKey"
    name: "key"
    in: "query"

(2) Try this API in Cloud Endpoints dev portal will work.

(3) And you still can send a request with the API key in the header x-api-key. It seems to work, but in contradiction to my understanding of the documentation.

Other information (workarounds you have tried, documentation consulted, etc):