Dr. McKay

Nothing I can do about it, I didn't write the forum software.

I've added initial support for using the new login scheme in the api-login branch: https://github.com/DoctorMcKay/node-steamcommunity/pull/292 But I've done it using protobufs to match how the proper Steam website does it. Where'd you get the values that you're sending?

That's correct.

That's probably down to Steam not sending it because it's not used in chat, which is the only official consumer of web logon tokens. I'm not aware of any way to force it to be sent, but you should be able to retrieve your wallet balance using steamstore.

You aren't waiting for the loggedOn event.

You would need to wrap logOn and the loggedOn handler in a promise. You'd also need to account for the error event in case you fail to log on, and remove the event listeners when you resolve the promise.

https://steamerrors.com/20 It's a problem with Steam. Nothing we can do about it.

That means that the request timed out. It's not an error in my code. My code is what's informing you of the timeout.

offer.send((err, status) => { if (err) throw err; console.log(`https://steamcommunity.com/tradeoffer/${offer.id}`); });

Nope.

Yes, it's gone.

Sounds to me like you probably aren't properly sending your cookies in your requests. The sessionid cookie is just a CSRF token; it can be anything at all.

I don't see any reason why that would happen unless you installed a really old version somehow. Could you paste the contents of node_modules/steamcommunity/package.json?

There's no list of the order that events get emitted in because it isn't really defined. loggedOn happens first, unless steamGuard happens before you log on. Once you're logged on, everything else happens as Steam sees fit. Obviously, once you're disconnected (disconnected and error events) then further events stop. You could add an event listener inside of another event listener, but unless you use user.once or manually remove the listener every time, then your event handler will start getting called multiple times when the event fires.

webSession will be emitted some time after loggedOn. loggedOn is the first event to be emitted after you log on; everything follows from there. Send your trade inside the webSession event and you should be good to go. Also, there's nothing that says you couldn't keep the bot logged on between requests, avoiding the need to log back on every time.

Your promise is getting resolved synchronously before anything actually happens.

Where are you logging accessToken? After the promise is resolved? If that's the case, you need to move your resolve(this) line after when the access token is set. I need to see all relevant code, along with debugging output (add console.log statements in places) to provide any further help.

What output are you getting, if any?

It looks like you're passing the same code to the steamGuard event as you used in the logOn method. If it didn't work the first time, it's not going to work a second time. You likely need to wait 30 seconds for the next code to come round, or add 30 seconds to your time offset.

Sounds like it's crashing. Not much that can be done to help you without a stack trace.

It certainly won't hurt anything to keep forcing the protocol to WebSocket, and it might improve compatibility with your proxy.

4.24.6 should improve this issue.

"Encrypted message authentication failed" should honestly never happen. If it does, either something is very broken in your setup, or else someone (e.g. your proxy) is modifying your network traffic in transit. Could you please provide the versions of everything involved? steam-user, @doctormckay/steam-crypto, node.js, operating system, etc. I'll try to make recovery from that error a little more gracious, but in the meantime you might be able to work around it by forcing the protocol to WebSocket: let user = new SteamUser({ protocol: SteamUser.EConnectionProtocol.WebSocket });

I could be wrong, but as far as I remember there's no concrete way to know that an offer is a counter offer. You could possibly check the offer created time and see if it closely matches the updated time of a previous offer sent to that user which has status Countered.