[feat] Add X-Remote-User header

[MistaTwista]

In some cases there are needs to Authorize user not in Taskcafe itself. For this reason option server.remote_user_header was added.

[server]
remote_user_header = true

With turned on Taskcafe listens X-Remote-User http header and skip password checking. But still check user existence and active flag.

• Please check if the PR fulfills these requirements

• [x] You have read the contribution guidelines guidelines
• [x] The commit message follows our guidelines
• [x] Docs have been added / updated (for bug fixes / features)

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...) This was in discussion https://github.com/JordanKnott/taskcafe/discussions/49

• What is the current behavior? (You can also link to an open issue here) Check user and password at login handler. Add token in DB. Return cookie.

• What is the new behavior (if this is a feature change)? Add an option server.remote_user_header (bool). Default is false. If it's true – taskcafe will not check user password, but still find it in DB and check it's activeness.

• Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?) no

• Other information:

[JordanKnott]

Based on the discussions in #49, we should have the remote user header be accepted in place of the current access cookie rather than implementing a separate authentication path in /auth/login.

This way the authentication flow would be

User requests index.html -> Proxy handles authentication -> index.html loads -> `<Remote User Header>` is accepted in place of regular access cookie so user is immediately logged in.

So the changes would likely mostly be in the authentication middleware.

However, one problem with going this route would be that public routes would no longer be public since the proxy would require authentication.

I am also a little hesitant on adding features without some platform that I can actually test the implementation. @aroberts - what proxy setup were you planning on using with this added feature? Perhaps I can setup something similar for testing.

[aroberts]

I'll be using this with Authelia. There's a "getting started" compose file with documentation about defining users statically via file, rather than having to set up ldap. I'm not intending this service to be usable by anyone not logged in, but if I did, Authelia lets me scope the auth challenge to only specific path prefixes. I think that's a fairly common pattern (auth on specific prefixes only) in this space, due to this exact problem.

[aroberts]

@JordanKnott do you see a path forward for this? I don’t think the public routes are an issue- if I wanted them to remain public, I’d just configure my authentication proxy not to apply the auth challenge to those routes. This is a feature of virtually every tool that sits in this role (auth proxy) because of exactly the problem you point out.

[JordanKnott]

I think the way forward would be to change the authentication logic to what I described in the my last comment - and leave handling the public routes up to the user (like you described).

[aroberts]

Any luck here? I'd love to see this feature make it in.