Supplying steamGuardCode in startWithCredentials() still causes a guard code E-Mail to be sent

[3urobeat]

Hey,
I've run into unexpected behavior when calling startWithCredentials() with the parameters accountName, password and steamGuardCode for E-Mail Steam Guard accounts.

steam-session resolves the promise with actionRequired: false, emits authenticated and populates refreshToken as expected, however I still receive a Steam Guard Code E-Mail from Steam.
I believe this is a bug since actionRequired is false, indicating that the steamGuardCode supplied is valid and was used.

Supplying a steamGuardCode generated from a shared_secret using steam-totp's generateAuthCode() function for an account that has mobile steam guard instead of e-mail steam guard set, however works as expected.

I have tried to supply the same name for steam-user's machineName and steam-session's deviceFriendlyName to see if this makes a difference, however it does not.

The Steam Guard Code I receive in the "unexpected" E-Mail is the same as I supplied.

 

Context

I'm currently trying to write compatibility code between the old `steam-user` `logOn()` flow and the new session login flow to make updating my bot automatically possible. It tries to login with steam-user's `logOn()` which succeeds if a sentry file exists, however if the `steamGuard` event fires, it waits for user input, creates a new steam-session object and supplies it with the retrieved code instead of steam-user to port over this account to the new login system. steam-user's `logOn()` is then called again using the acquired refreshToken and the refreshToken is stored in my database to be used in future login attempts. It does not make a difference if I call steam-user's `logOff()` and wait a few seconds before making a new steam-session obj btw, I tried that as well. This should hopefully slowly fade out the old system - it was my best idea on how to implement the new system atm while not breaking automatic updates. (I'm open for suggestions if you can think of a better way lol)

[3urobeat]

Oh I guess I can think of why this happens...
If I understand your code correctly you are starting a login session, then wait for Steam's response and only then supply the provided steamGuardCode using submitSteamGuardCode(), basically like I would do manually as a user.
By doing a normal login attempt using credentials, Steam sends the Steam Guard E-Mail.

So this is probably unavoidable and intended(?) behavior, just a little bit unexpected for the user as I thought you would directly supply this information to Steam, bypassing getting an E-Mail sent.
Might be something to add to the documentation and otherwise forget, as I'm basically using the lib in a way that was probably not intended.

[DoctorMcKay]

At the time when I originally wrote this, Steam would only send the email after the client has checked their device auth to see if it's valid (if a valid device auth exists, there's no need to supply a code at all, so no email needs to be sent). It's possible that something has changed.

Could you try the latest version from master instead of the npm version?

[3urobeat]

Sure!
Sadly nothing changed, the behavior appears to be the same.

[DoctorMcKay]

What EAuthTokenPlatformType are you using? I'm seeing expected behavior using WebBrowser, but what you describe is happening when using MobileApp or SteamClient.

[DoctorMcKay]

Documentation has been updated. An email is always generated when using EAuthTokenPlatfornType = SteamClient or MobileApp.

[3urobeat]

What EAuthTokenPlatformType are you using?

I'm using SteamClient as I'm supplying the token to steam-user (decision based on the comment you made here)

Thank you for clarifying it in the docs!