Dr. McKay

And your versions: npm list

Cookies obtained from a CM are invalidated as soon as the connection drops. You should pause your queue when you get disconnected, and only restart it once webSession gets emitted after reconnection. No, I don't believe that would be a problem.

I've added a section to the "Cookies" guide post about how different modules use them.

No, the sentries aren't particularly important if you're using 2FA.

Yes, use the setPersona method.

SteamCommunity and TradeOfferManager need only cookies to operate. That's how they keep track of their session. SteamUser operates directly through Steam's CM servers, not through the web. It doesn't need cookies for anything; it's merely capable of creating them (via the CM). Thus, you can create cookies through either SteamUser or SteamCommunity, and then provide them to SteamCommunity and TradeOfferManager. If you're already logging in with SteamUser then cookies are created automatically, even if you don't request them. Thus, it's unnecessary (and potentially problematic) to also create them via SteamCommunity. Basically, you want: user.on('webSession', function(sessionID, cookies) { manager.setCookies(cookies, function(err) { if (err) { throw err; } }); community.setCookies(cookies); }); community.on('sessionExpired', function() { user.webLogOn(); }); It's also potentially helpful to just automatically call webLogOn every 30-60 minutes, just to be sure that it's always fresh. And finally, don't run the same account in two places or else the cookies have a nasty habit of expiring prematurely.

Show your code, please. And your versions.

I don't know offhand why it wouldn't be writing the files at all, but why not just disable the singleSentryFile option to get the behavior you want without implementing your own save handler?

That is the case if you passed the community instance into the constructor. Those examples were written before that was possible so it's necessary to call setCookies on both.

\n

Yes, that's exactly what is happening. You should call user.webLogOn() and set the resulting cookies normally.

You're listening for events that steam-user emits on a steamcommunity instance.

You're pushing the data correctly, you just seem to not understand async. Calling market.getItemPrice is essentially requesting that it retrieve the item price and then let you know when it's finished. You then return immediately, without waiting for the callback.

Listen for the sentOfferChanged event and see if the new state is Accepted.

An HTTP/S proxy over IPv6? Maybe. I don't know.

Make sure your server is able to access api.steampowered.com.

It's not a bad idea to add a short delay. acceptConfirmationForObject has nothing to do with the confirmation checker. It operates immediately. If you're using it, you probably don't necessarily need the confirmation checker.

Socks proxies are currently not supported. You'll need to use an HTTP proxy. I don't believe I've pushed support for HTTPS proxies (HTTP is just as secure for this case). Example: const Steam = require('steam-client'); const SteamUser = require('steam-user'); let client = new Steam.CMClient(); let user = new SteamUser(client); client.setHttpProxy("http://user:[email protected]:12345"); user.logOn(/* options go here */);

It will already retry connection until either it succeeds or error gets emitted.

No.

classid and instanceid can change on an item, yes.

Is steamcommunity up to date?

Yes, it's rate-limited by Steam. I can't tell you what the limit is, exactly, as I don't work for Valve.

No. If the error event is emitted, it's always fatal and it will never retry on its own.

loadInventory is deprecated and won't be updated. If Steam is reporting "Failure" then there's not really any way to know for sure if it means that the user doesn't have that particular inventory or if there was truly a failure somewhere. If the user has ever owned an item for that game and thus the inventory exists but is empty, it will return an expected empty response (no error, empty arrays).