feat: use X-Goog-Api-Key header #719
Conversation
|
|
||
| if (this.apiKey) { | ||
| return {headers: {}}; | ||
| return {headers: {'X-Goog-Api-Key': this.apiKey}}; |
There was a problem hiding this comment.
So further down, in the requestAsync method, there's a bit of code that grabs the API key and stuffs it in a querystring parameter (I think). Could I trouble you to modify that code to use the HTTP header instead as well? Or alternatively, file an issue to come back around for it?
There was a problem hiding this comment.
So I checked it and verified it works, but I'm still not sure if it's a safe change to remove that &key= and replace it with the API token.
But here are my examples that I checked.
Sample JSON request to Vision API:
$ cat request.json
{
"requests": [
{
"image":{
"source": {
"imageUri": "https://timedotcom.files.wordpress.com/2019/03/kitten-report.jpg"
}
},
"features":[
{
"type":"LABEL_DETECTION",
"maxResults":1
}
]
}
]
}
Passing API key in a GET parameter:
$ curl -H 'Content-Type: application/json' \
-X POST -d '@request.json' \
https://vision.googleapis.com/v1/images:annotate?key=$GOOGLE_API_KEY
{
"responses": [
{
"labelAnnotations": [
{
"mid": "/m/01yrx",
"description": "Cat",
"score": 0.99598557,
"topicality": 0.99598557
}
]
}
]
}
No API key - does not work:
$ curl -H 'Content-Type: application/json' \
-X POST -d '@request.json' \
https://vision.googleapis.com/v1/images:annotate
{
"error": {
"code": 403,
"message": "The request is missing a valid API key.",
"status": "PERMISSION_DENIED"
}
}
Passing API key in an HTTP header - it works again:
$ curl -H "X-Goog-Api-Key: $GOOGLE_API_KEY" \
-H 'Content-Type: application/json' \
-X POST -d '@request.json' \
https://vision.googleapis.com/v1/images:annotate
{
"responses": [
{
"labelAnnotations": [
{
"mid": "/m/01yrx",
"description": "Cat",
"score": 0.99598557,
"topicality": 0.99598557
}
]
}
]
}
What's your call @JustinBeckwith?
There was a problem hiding this comment.
(I made the change, PTAL)
There was a problem hiding this comment.
I double checked that those two (&key= query string parameter and X-Goog-Api-Key header) are interchangeable so it should be ok to remove the query string parameter in favor of the header.
Can I have one more look at the added changes @JustinBeckwith?
Codecov Report
@@ Coverage Diff @@
## master #719 +/- ##
=======================================
Coverage 84.77% 84.77%
=======================================
Files 18 18
Lines 939 939
Branches 209 209
=======================================
Hits 796 796
Misses 83 83
Partials 60 60
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #719 +/- ##
==========================================
+ Coverage 84.77% 84.78% +0.01%
==========================================
Files 18 18
Lines 939 940 +1
Branches 209 209
==========================================
+ Hits 796 797 +1
Misses 83 83
Partials 60 60
Continue to review full report at Codecov.
|
JustinBeckwith
left a comment
There was a problem hiding this comment.
Thanks for the fix!
We have this thing called gRPC Fallback, which supports API keys and requires them to be sent in this special header
X-Goog-Api-Key. Some details here and more details - with JavaScript code sample I wrote - here.Let's set this header so that the JavaScript code could use
getRequestHeadersin both service account and API key use cases.