Christian-Stieber
commented
5 months ago Ok, I still don't know how you're REALLY supposed to handle this -- nothing I've tried to avoid the timeouts has worked (sending heartbeats, doing the auth status poll, reading and re-reading the proto files to see if there are any hints -- I found a weak_token, but no clue as to what this can be used for.
Thus, I've implemented a "session state" type of thing that does the user interaction, and remembers things like passwords. Whenever the login module needs user information, it invokes this and terminates the client; when the user has entered the required information, the session manager will startup the client again which will then be able to just re-do previous steps using cached data. In other words:
- client starts up, needs a password for login.
- session manager has no password, so it asks the user to enter it and terminates the client
- user enters the password
- session manager starts the client again
- client starts up, needs a password for login
- this time around, session manager can supply one.
- client continues the login and learns that it needs a steamguard code
- session manager has no steamguard code, so it asks the user to enter it and terminates the client
- user enters steamguard code
- session manager starts the client again
- client starts up, needs a password for login, gets it from the session manager
- client needs the steamguard code, gets it from the session manager
- login completes
That way, the client never has to wait for the user to provide something and won't run into the timeout.
https://github.com/Christian-Stieber/Christians-Steam-Framework/commit/7901b11d650af50828dcdaecddf2576264bbc6e5 .. https://github.com/Christian-Stieber/Christians-Steam-Framework/commit/2e4df50bddf286745ab42e4ac29d99b29396b7ea
Both on password and Steamguard phases, timeouts can happen which appear to screw up the logic; I'll need to take a closer look at how this is supposed to work, and how we can make it work.