Yellow-Dog-Man
Support 2FA Login on Headless Startup
Is your feature request related to a problem? Please describe.
When starting up a headless client with credentials stored in the configuration file, login will fail for an account that has 2FA login enabled. The headless client will attempt to login but will fail the 2FA step and continue running the headless as a local user instead. I don't consider this a bug since it's a pretty reasonable way to handle the situation. However it means I can't easily host sessions automatically based on my configuration as I have to manually log in after the headless has started up and manually begin sessions from the console after logging in to host them as my user.
Describe the solution you'd like
As an example, SteamCMD currently deals with this in a couple of ways:
- You can provide a 2FA code as a command-line parameter: logon [username] [password] [2FA code]
- SteamCMD will prompt for a 2FA code when attempting to log in if one is required. You can enter it on-demand and authentication will continue.
- SteamCMD caches authentication so subsequent runs don't require user interaction (basically the "Remember Me" checkbox)
In the case of Resonite's headless it would be useful if I could pass a 2FA code when starting the client or be prompted when it runs to enter a code if needed prior to starting any worlds/sessions.
For example as a parameter:
mono Resonite.exe -HeadlessConfig /Config/Config.json -2FA 012345
Or prompted:
Logging in as [email protected]
2FA Code: 012345
Logging in...
In my use-case, cached credentials wouldn't help as I start a fresh docker container for my headless every time. But it would be useful to do so for others I'm sure.
Describe alternatives you've considered
The current accepted workaround is to just make a separate account to act a Headless host. This isn't unreasonable but I can easily imagine cases where one wants access to their own inventory and user benefits on their headless server.
There could be some account setting that allows 2FA login to be bypassed for a headless client. However this obviously opens up security holes and would not be ideal.
A more practical alternative may be some kind of Access Token or API key that one specifically generates for use-cases like a headless client or a bot. This doesn't seem likely until the API is considered stable and supported for end-users but I figured I'd mention it.
Additional Context
No response
