ECONNREFUSED with API key.

[stephenyeargin]

ECONNREFUSED with API key.

[stephenyeargin]

I did add some console.log statements to inspect variables and I noticed that the authHeader has some odd formatting around the Authorization:

So this indicates that is the correct format, but perhaps something else is at play.

Is your Hubot running on Heroku by chance? ECONNREFUSED would indicate to me that something network related is happening. This StackOverflow comment on a similar issue points to a similar issue in another node application.

[michaelcoyote]

Sorry, no Heroku. Just a shell on a Debian box in our internal datacenter.

I can do curl to that same instance from the same shell and get a response every time using the Authorization: Bearer eyJrIjoiWXXX...XXX0= string as my header however if I switch to Authorization: 'Bearer eyJrIjoiWXXX...XXX0=' it fails.

Setting NODE_ENV=production in my startup script did nothing.

[michaelcoyote]

According to the Grafana API Documentation the header is used like this:

GET http://your.grafana.com/api/dashboards/db/mydash HTTP/1.1
Accept: application/json
Authorization: Bearer eyJrIjoiT0tTcG1pUlY2RnVKZTFVaDFsNFZXdE9ZWmNrMkZYbk

Additionally the example in RFC 6750 also leaves out the single quotes:

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

[stephenyeargin]

Ok, so this starts to look like the culprit. The trouble is that I am using how Hubot's scripting guidelines say to add headers, but the output is invalid. Wonder if something changed upstream? It appears to be limited to certain versions of Grafana and Hubot core.

[michaelcoyote]

I'll get the version of Grafana we're working on today and report it here. I also did a bit more looking around and it seems like other programs construct their headers this way, so I'm not exactly sure why it should be an issue here.

[stephenyeargin]

Worth noting that what you console.log'd may have been correct per the spec for the HttpClient node object as well (which is what robot.http provides a wrapper). The assembly of the header string happens further down (and should happen without the quotes).

Wondering if we pointed the script at something like Runscope or a local machine with verbose logging if we could see what headers actually make it to the Grafana server.

[michaelcoyote]

I think you are right WRT robot.http doing the right thing with the header. I'm afraid I didn't dig into that.

Instead I did a bit of digging around our infrastructure and got it figured out. Looks like the folks who set this up used nginx on port 80 and then grafana on another port. Curl works on both ports but hubot-grafana didn't in my case. The fix was to aim directly at the grafana port. My theory is that there is some odd interop between robot.http and nginx/grafana enough to foul the key passing.

Again, thanks for your help. I'm going to close this, however if we want to dig into this further, please feel free to reopen.