[feat] Remote header auth

[MarcHagen]

Description

• Allow basic User management without permissions #128 - Not fixes, but adds Remote User functionality through the use off Remote-User (configurable)
• Ability to skip login form when using Remote-User
• Validation if the remote user exists in the local database
  This raises the question if we want to auto generate users. But for now I've ignored that part
• Ability to change username through the cli/command line npm run change-username
• Hide UI elements when using Disabled Auth or Remote-User headers.

Type of change

Please delete any options that are not relevant.

• New feature (non-breaking change which adds functionality)

Checklist

• My code follows the style guidelines of this project
• I ran ESLint and other linters for modified files
• I have performed a self-review of my own code and tested it
• I have commented my code, particularly in hard-to-understand areas
  (including JSDoc for methods)
• My changes generate no new warnings
• My code needed automated testing. I have added them (this is optional task)

Screenshots (if any)

Small cosmetic change to settings page.

[louislam]

I think this maybe a similar pull request: #474.

[Computroniks]

#474 looks pretty inactive and would probably have a bunch of merge conflicts. This PR seems to be a bit more developed so I would be tempted to say go with this one when it is ready.

[MarcHagen]

Yes, #474 is outdated and failed to fix some critical issues. This code is in theorie complete. I'm using this version internally right now.
I've created a draft to get a discussion going.
The base for this PR is indeed #474, but better implemented and more up-to-date

[sevmonster]

I think this would be a good time to implement #1672? I personally have no need for native authentication and feed everything through authentik, it would be easier for future users to be able to simply disable it from the start.

I will look over these changes and try them in my environment as well.

[MarcHagen]

@sevmonster at the moment the code in this PR still relay on the internal user.

And I had too change the default admin to my own username to get it working with an SSO.
(Hence the change username script)

I'm not sure if we can bypass the whole internal user thing as it is used by some mechanisms that relay on some info like a userId or userName.

This is why this is also still a draft PR, any feedback on that is absolutely welcome!

[louislam]

Just a reminder, if the feature is finished, remember to click "Ready for Review".

[MarcHagen]

@louislam Too me this can be implemented, but SSO is mainly based on multi user.
So this will work for instance with an SSO with only 1 account. But SSOs with multiple users will fail as Uptime Kuma doesn't have multi user support and cannot find that user.

The other side it to disable all Uptime Kuma user management when using SSO. (introducing "multi user").
Thats some big steps/changes, and im not the person to make that call.

I'm happy to update and test to get it up-to-date with other features. But then it needs a sidenote about the username change and that it only works with 1 user SSO.

[CommanderStorm]

The same as #4751, this is blocked by #3571 which has slotted into the v2.2 release.

The current v2.0 release is tracked in #4500

[MarcHagen]

I’ll update the branch.
Since opening this PR I’m using SSO (Authelia) for my own instance. Never had issues 😁.