Silence creator from HTTP header or Basic Auth username #2971
Conversation
|
@w0rm is there any chance you can take a quick peek at the above and guide me into how can I achieve the front-end bits? |
| func (api *API) usernameFromHeaderOrBasicAuth(request *http.Request) string { | ||
| // First, let's try getting the username from Basic Authentication. | ||
| if user, _, ok := request.BasicAuth(); ok { | ||
| return user |
There was a problem hiding this comment.
This is not correct, we should have this configured. if a specific header is specified in config, we should always use it, even if a user adds a custom authorization header.
use case for this:
- you put an open id connect proxy in front of alertmanager, which pass the username as http header
- communication between the proxy and alertmanager is done via static basic auth and TLS
|
This is my sample front-end program with this PR. Here
However, there are still some points to be discussed.
[demo] sample.UI.Silence.creator.from.HTTP.header.or.Basic.Auth.username.mov |
|
Wow! Thank you so much @m-masataka this looks great. I'm not sure a new API endpoint is the direction we'll take but the front-end changes look 👌 As for your questions:
Yes, if there is a value available for the creator we should always use it. Validation will fail if the user creating/editing the silence does not match the current value. This effectively turns the feature is a type of last-write wins semantic where the creator is actually a last modified.
Assuming that reload means on every time the silence form is rendered then we agree.
We'll return a 204 status code instead of a 200. 204 non-content basically means we have unable to a value. |
As part of #2971, I'm about to extend the test for silences - extract the functions into helpers as part of a separate file and add names to the expectations so that we can easily identify them.
As part of #2971, I'm about to extend the test for silences - extract the functions into helpers as part of a separate file and add names to the expectations so that we can easily identify them.
As part of #2971, I'm about to extend the test for silences - extract the functions into helpers as part of a separate file and add names to the expectations so that we can easily identify them.
As part of #2971, I'm about to extend the test for silences - extract the functions into helpers as part of a separate file and add names to the expectations so that we can easily identify them.
As part of #2971, I'm about to extend the test for silences - extract the functions into helpers as part of a separate file and add names to the expectations so that we can easily identify them.
As part of #2971, I'm about to extend the test for silences - extract the functions into helpers as part of a separate file and add names to the expectations so that we can easily identify them.
As part of #2971, I'm about to extend the test for silences - extract the functions into helpers as part of a separate file and add names to the expectations so that we can easily identify them.
As part of #2971, I'm about to extend the test for silences - extract the functions into helpers as part of a separate file and add names to the expectations so that we can easily identify them.
As part of #2971, I'm about to extend the test for silences - extract the functions into helpers as part of a separate file and add names to the expectations so that we can easily identify them. Signed-off-by: gotjosh <josue.abreu@gmail.com>
Signed-off-by: gotjosh <josue.abreu@gmail.com>
As part of #2971, I'm about to extend the test for silences - extract the functions into helpers as part of a separate file and add names to the expectations so that we can easily identify them. Signed-off-by: gotjosh <josue.abreu@gmail.com>
gotjosh
force-pushed
the
silence-creator-from-header-or-auth
branch
from
39d14f4 to
a4025de
Compare
As part of #2971, I'm about to extend the test for silences - extract the functions into helpers as part of a separate file and add names to the expectations so that we can easily identify them. Signed-off-by: gotjosh <josue.abreu@gmail.com>
gotjosh
force-pushed
the
silence-creator-from-header-or-auth
branch
from
a4025de to
af108fe
Compare
As part of #2971, I'm about to extend the test for silences - extract the functions into helpers as part of a separate file and add names to the expectations so that we can easily identify them. Signed-off-by: gotjosh <josue.abreu@gmail.com>
Signed-off-by: gotjosh <josue.abreu@gmail.com>
Signed-off-by: gotjosh <josue.abreu@gmail.com>
Signed-off-by: gotjosh <josue.abreu@gmail.com>
gotjosh
force-pushed
the
silence-creator-from-header-or-auth
branch
from
af108fe to
cd8cd33
Compare
Signed-off-by: gotjosh <josue.abreu@gmail.com>
|
Can we restrict for many and recheck the Restrictors/Creators by either username or email? |
If you means set username or email I think it depends on your identity proxy. @AakarshitAgarwal We can set one custom header to use restrict Creator in this PR. so we can't set many creators. |
As part of prometheus#2971, I'm about to extend the test for silences - extract the functions into helpers as part of a separate file and add names to the expectations so that we can easily identify them. Signed-off-by: gotjosh <josue.abreu@gmail.com> Signed-off-by: Yijie Qin <qinyijie@amazon.com>
|
Any update, i would really love this feature ;) |
|
I would like to see this feature as we have a reverse proxy in front Alertmanager for authentication that could easily add a username header for Alertmanager to consume and prefill the author, or even enforce the author. |
The discussion is long as part of #1196, so instead of building this in isolation - I'm putting this out there to gather some feedback as I know there's some historic context and I want people to voice their opinions.
The first step is the building block for the server part (I'd argue this is the easy part):
1. If the header name is configured, we'll only check that and return the value from that.2. If no basic auth is present, try the header which is specified via a configuration optionThe other bit is the front-end part (the actual hard one), a couple of thoughts:
/api/v1/me, including it as part of the status endpoint and calling that as we render the silence form, etc. any opinions on what route should we take? I can start to see what Brian meant that this can very quickly turn into a scope creep for authentication things.Fixes Feature request: restrict the identity of silence creator to one passed by some HTTP header #1196
TODO
[ ] front-endthe front-end part has been handled by @m-masataka and I think it's better discussed through a separate set of PRs.Signed-off-by: gotjosh josue.abreu@gmail.com