Support authorization_credentials

[roidelapluie]

This backward-compatible patch enables authorization header type to be
set.

For consistency, bearer_token is renamed to authorization_credentials
and a new authorization_type is introduced.

The terminology is taken from
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization

refs:
#271
prometheus/prometheus#5107

Signed-off-by: Julien Pivotto roidelapluie@inuits.eu

[roidelapluie]

Questions:
Do we want this?

Do we want the form:

authorization_credentials: superlongbearer
authorization_type: APIKEY

or

authorization:
   credentials: superlongbearer
   type: APIKEY

Note: the latter would mean always 2 lines (in pretty yaml) and therefore you can't easily sed your existing configuration file.

authorization_credentials: superlongbearer

or

authorization:
   credentials: superlongbearer

[dazinator]

My vote would be for the latter format

authorization:
   credentials: superlongbearer

[roidelapluie]

I have implemented the latter. cc @beorn7

[beorn7]

I'll review properly ASAP.

In the meantime, you can fix the CI failures. (o:

[dazinator]

What's the benefit for preventing "basic" as the auth type here? Just thinking the two config mechanisms are not strictly equivalent - as with one the user must save the username and password in the config in plain text. In the other the user can save the credentials pre encoded as they are transmitted over the wire. It may be preferable to the user to use the second mechanism?

[roidelapluie]

This is to reduce support requests. That prevents users to put clear text password here and expect it to work. We have a well defined way to do Basic auth, let's not add a second.

[roidelapluie]

I would also note that some users might have the fake sense of security that this method would use an encrypted password while it's not the case.