HTTP API Basic Auth response missing required header

Grafana Authentication
1

Hi.

According to https://grafana.com/docs/http_api/auth/ Grafana’s HTTP API will accept Basic Authentication using the same user / password as can be used to log in to the standard web interface.

The example is given using curl, and this works:

curl “http://admin:admin@localhost:3000/api/org”
{“id”:1,“name”:“Main Org.”,“address”:{“address1”:"",“address2”:"",“city”:"",“zipCode”:"",“state”:"",“country”:""}}

However, the same request made using wget fails:

wget -O- “http://admin:admin@localhost:3000/api/org”
–2019-05-10 11:14:36-- http://admin:password@localhost:3000/api/org
Resolving localhost (localhost)… 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:3000… connected.
HTTP request sent, awaiting response… 401 Unauthorized
Unknown authentication scheme.

Username/Password Authentication Failed.

This turns out to be because curl sends the username / password immediately in the first HTTP request, whereas wget works more like a standard browser, which makes the request without authentication, expects a 401 HTTP response, and then sends the request again, this time including the authentication credentials.

However, Grafana sends the 401 HTTP response without a WWW-Authenticate header, so wget doesn’t reply with an authenticated request.

This header is a required header in a 401 response according to https://tools.ietf.org/html/rfc1945#section-10.16 and https://tools.ietf.org/html/rfc7235#section-4

Can this header be added to a future version of Grafana so that standard clients can authenticate to the HTTP API?

Thanks,

Antony.

2

Hey Antony, thanks for the post. You are right seems like we are missing the header. Can you create an issue in https://github.com/grafana/grafana? It will be easier to track it and link to eventual fix.

3

Grafana cannot do this as basic auth is just an option not a requirement, if we return this header it would force browser to show a basic auth login modal

4

So, how about listening for API requests on a different port number than
standard browser access?

Antony.

5

@torkel What about returning it only for /api/* and if basicAuth = true in config and non api routes would still be redirected to login page instead (no need to have separate port)? That should not interfere with anything or would it?

6

This is still broken, and is out of spec for the related RFCs. As well, some clients APIs are now requiring that basic auth requests are only sent in response to the auth header being sent. This is breaking automation for some systems. At the very least, could you please put this behind a setting that users can control? Such as: “basic auth: enabled-as-spec | enabled-no-header | disabled” It’s not nice that developers have to hack around things to cater to non-compliant implementations. For users who enable basic auth as well, it’s not nice that they won’t be seeing appropriate auth challenges as one would expect.