-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support "Authorization: Bearer <token>" #4483
Comments
@splashx This seems like a reasonable request. The Authorization header with the Bearer auth scheme seems to be an exact match for how the tokens are used. I am not sure when the team could get around to implementing it but we would be open to a PR for this. |
I'd be happy to take this up! Can y'all can give me some pointers regarding the implementation since I'm very new to the code base? 😄 |
@shubheksha there is a pending PR #4502 for this already ... feel free to chip in. |
Added Authorization Bearer token support as per RFC6750 * appended Authorization header token parsing after X-Consul-Token * added test cases * updated website documentation to mention Authorization header * improve tests, improve Bearer parsing
Feature Description
It would be great if consul could support
Authorization: Bearer <token>
.Use Case(s)
There are some tools which won't support custom headers (see prometheus/prometheus#2346 and prometheus/prometheus#1724).
One should not expect the world would interface with Consul using a non-standard
X-Consul-Token
header.Authorization: Bearer <token>
andX-Consul-Token: <token>
could be interchangeable for long-lasting backwards compatibility.The text was updated successfully, but these errors were encountered: