Silence creator from HTTP header or Basic Auth username

[gotjosh]

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 option~~

1. If a header is set, use that no matter what.
2. if no header is set, try basic auth.
3. if none of the above returns an username, carry on as normal.
4. if there's a discrepancy between what's in the params the value extracted from 1 and 2 error out.

The other bit is the front-end part (the actual hard one), a couple of thoughts:

• When the silence form is rendered, there's no HTTP call as part of that and we all know that is not possible to access headers from javascript.
• There are several approaches to solving the above, it can range from: Including the parsed username as part of the response to every HTTP call, creating a dedicated endpoint e.g. /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.
• The front-end experience that I have in my head is the following:
  • Sever tells you your current username (try basic auth first, if not then header)
  • If there's any, created by field gets filed in and disabled (greyed-out) Fixes #1196

TODO

• [x] tests
• ~~[ ] front-end~~ the 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 [email protected]

[gotjosh]

@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?

[m-masataka]

This is my sample front-end program with this PR. Here I'm implementing this based on the following idea

creating a dedicated endpoint e.g. /api/v1/me

However, there are still some points to be discussed.

• Should the creator be overwritten on the edit silence view?
• When the front-end get username? (I think it should be called on reload.)
• How to know whether this auth option is enable or not in front-end?
  • I think we should get the status with the response of api/v../me .

[demo]

https://user-images.githubusercontent.com/15244170/177025919-1b2010f6-0336-4238-8424-edd3895bd051.mov

[gotjosh]

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:

Should the creator be overwritten on the edit silence view?

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.

When the front-end get username? (I think it should be called on reload.)

Assuming that reload means on every time the silence form is rendered then we agree.

How to know whether this auth option is enabled or not in front-end?

We'll return a 204 status code instead of a 200. 204 non-content basically means we have unable to a value.

[AakarshitAgarwal]

Can we restrict for many and recheck the Restrictors/Creators by either username or email?

[m-masataka]

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.

[genofire]

Any update, i would really love this feature ;)

[matzarah]

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.