[Feature] OAuth configuration through ENV variables.

[LarssonOliver]

I have searched the existing feature requests to make sure this is not a duplicate request.

• Yes

The feature

It would be convenient to be able to be able to manage OAuth configuration using ENV vars. It would make it simple to import configurations such as the client secret from a secret manager.

Variable name suggestions: (documentation)

• OAUTH_ENABLED
• OAUTH_ISSUER
• OAUTH_CLIENT_ID
• OAUTH_CLIENT_SECRET
• OAUTH_CLIENT_SCOPE
• OAUTH_AUTO_REGISTER
• OAUTH_AUTO_LOGIN

Thanks for the cool project!

[johanohly]

I think this would be a great addition to the current config system, which I was planning on rewriting regardless.

How should the system handle both potential env vars and configuration done through the UI?
If the system propagates the (defined) env vars into the database (where dynamic configuration is stored currently) on startup, it could create confusion when a user changes the same config value in the UI, because it won't be updated in the env file, and so would be reset to the env value on restart.

[LarssonOliver]

A natural way of solving this would be to make any (valid) configuration specified using ENV vars read-only in the UI. To make it clear, there could be a hint in the UI, perhaps on hover, that states this.

Should a previously ENV-specified configuration no longer have a defined ENV, the in-UI field could once again become editable. It becomes a check on every startup.

[johanohly]

I like this very much, it's very clean and intuitive.
This will probably be the way I do it when I rewrite the app config system, although I won't have time to for another two weeks.

[johanohly]

I have begun work on this in #102

[johanohly]

This has been implemented in v1.1.0