Dr. McKay

Remove this line. The steam guard value doesn't exist anymore.

You're asking a few different questions, so let me clarify how Steam views "devices". The machine ID that's by default generated from your account name is sent in the logon message. To my knowledge, it isn't really used for anything except maybe family sharing. The "DESKTOP-xxxxxx" names you see on your authorized devices page are controlled by the machineName you supply to the logOn() method. If you don't provide one, then it's auto-generated as you see. A "new device" for purposes of trading is determined by the machine auth token. If you use a previously-issued machine auth token to log on, then you won't need to provide an email Steam Guard code and it'll be counted as a previously-authorized device for purposes of trading restrictions. Logging in with username + password is what generates a new entry in the authorized devices page. Saving and using a refresh token to login more than once is the same thing as checking the "remember me" box when you log into the Steam client; it's treated as the same session and thus isn't counted as a new device when you log in after the first time. You won't generate new entries on the authorized devices page by reusing a refresh token.

It should, yeah.

steam-session can approve QR login attempts, but not standard password logins.

Using the GetPlayerBans endpoint is going to be your best bet. There's no event for it.

That all looks fine to me at a glance. I'd look into whether it's actually possible to set cookies the way you are in a fetch request in a browser extension; that may be blocked for some reason.

RequestStoreSalesData -> RequestStoreSalesDataUpToDateResponse sounds a lot like there's some local caching involved. Try uninstalling and reinstalling the game, then see if it receives more data.

That's not a valid solution because consumer code that (correctly) calls logOn in response to an error event will enter an infinite loop.

From the Dota GC, most likely.

Using classids yourself is almost never a great idea. You'll run into tons of pairs of items that have identical descriptions but different classids. It's much better to use market_hash_name to uniquely identify a "kind" of item (that's what the Steam market uses, after all).

There isn't, but you could fairly easily keep track of it yourself. When you call logOn or disconnected is emitted, it's attempting to reconnect.

Why? This seems like a bad idea.

The type definition is wrong.

It's completely expected that you'd get undefined in your inventory variable, since the result is passed to the callback and not returned by the method.

I haven't tested it in years, but timestampTwoFactorEnabled should be non-null if you have mobile 2FA enabled.

Either works, but using steamcommunity is "better" since it more closely mimics how the official mobile app works. steam-user just happens to work but may break at any time (though it's been working since 2FA came out, so seems pretty unlikely that it'll break).

If log on succeeds, you get a loggedOn event. Check the example scripts in the GitHub repo.

Why do you have a stray / at the end of your GetPasswordRSAPublicKey request? It's probably interpreting that as part of the account name.

Sure

You'd want to call logOn for any error event, likely after a delay.

Catch the error event to prevent the crash, and call logOn again to kick off trying to connect.

https://steamerrors.com/5

Check the x-eresult header.

Not at the moment.

You should not be sending this stuff in the query string; it needs to go in a POST body.