Skip to content

feat: HTTP Bearer Authorization for simple use cases#193

Open
robbat2 wants to merge 1 commit into
prometheus:masterfrom
robbat2:auth-bearer
Open

feat: HTTP Bearer Authorization for simple use cases#193
robbat2 wants to merge 1 commit into
prometheus:masterfrom
robbat2:auth-bearer

Conversation

@robbat2

@robbat2 robbat2 commented Jan 7, 2024

Copy link
Copy Markdown

Add support for HTTP Bearer Authorization for simple use cases, where HTTP Basic might not fit workflows.

Signed-off-by: Robin H. Johnson robbat2@gentoo.org

@SuperQ

SuperQ commented Jan 7, 2024

Copy link
Copy Markdown
Member

I wonder if we should support arbitrary headers, rather than specifically one kind of bearer token. The reason we have the basic auth here is because there's some standard encoding involved. Authorization: Bearer xxxx is a simple opaque string.

@SuperQ SuperQ requested review from SuperQ and roidelapluie January 7, 2024 13:28
@robbat2

robbat2 commented Jan 7, 2024

Copy link
Copy Markdown
Author

I actually started considering other auth to add, including HTTP Digest (which also needs special handling like Basic)

For your proposal, it would be match header to accept:

match_header:
  authorization:
    - "Bearer foo"
    - "FakeAuth value2"
  x-random-stuff:
    - "abc123"

@SuperQ

SuperQ commented Jan 8, 2024

Copy link
Copy Markdown
Member

Some work on Digest auth was being done over in the common package.

prometheus/common#553

Add support for HTTP Bearer Authorization for simple use cases, where
HTTP Basic might not fit workflows.

Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
@robbat2

robbat2 commented Jan 10, 2024

Copy link
Copy Markdown
Author

@SuperQ hmm, reading that, I realize there is more auth support in common already that not being exposed in toolkit; should I include that in this PR?

@roidelapluie

Copy link
Copy Markdown
Member

@SuperQ hmm, reading that, I realize there is more auth support in common already that not being exposed in toolkit; should I include that in this PR?

Anything beyond basic auth would require you to set a proxy. The exporter toolkit is limited to: TLS, and simple use case. The idea is to enable you to have a trusted connection between your exporter and the proxy of your choice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants