webSession expires, but loggin in again returns "Already logged on"

[esteamer]

I am creating node-steam-user and steamcommunity instances and passing them into the trade offer manager constructor. I then log in using the steam user instance (as provided in the example here), and set the cookies on the trade manager and steam community.

 

Now what's happening is when a new trade offer comes in and I attempt to accept, it fires the callback with an error "Not Logged In", and it automatically fires the "sessionExpired" steamcommunity event, which I then use to log in again the same way I did the first time -- with steam-user. However, the response is always "Already logged on".

 

1. Is this happening because the community session is expired but not the steam-user? Is that even possible?

2. The only thing I can think of is to change up my logic to use login() on steamcommunity, and then set the returned cookies on steam-user and trade manager. And when the web session expires, call the same login() again. Is that correct?

3. If the web session expires and I re-log in successfully, should I always set the new cookies on steam-user and trade manager?

 

Any help here would be appreciated.

[Dr. McKay]

1. Is this happening because the community session is expired but not the steam-user? Is that even possible?

 

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

[esteamer]

Thank you for the clarification. Yesterday I already went ahead and refactored to just use steamcommunity all around, and use the its login() method again when the sessionExpired event is fired. I think that will accomplish the same thing you said. I then set the cookies all around. Correct me if that's not right.

 

Also, minor OT detail, but the examples all show calling "setCookies" on the manager, and then on community. According to the source code, the manager's setCookies() itself calls community's setCookies, so the call in the examples is redundant.

 

Cheers.

Edited July 16, 2017 by esteamer

[Dr. McKay]

Also, minor OT detail, but the examples all show calling "setCookies" on the manager, and then on community. According to the source code, the manager's setCookies() itself calls community's setCookies, so the call in the examples is redundant.

 

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.

[esteamer]

On second thought... what I just said may be wrong. steam-user doesn't have a setCookies method. I think that with the change I made, after logging in to steam community again and setting cookies, I STILL need to call user.webLogOn()... and then set cookies again on the others...?

 

I think a readme or flow chart explaining how all three different libraries interact with each other would be super beneficial 

Edited July 16, 2017 by esteamer

[Dr. McKay]

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.

[Dr. McKay]

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

[esteamer]

Thanks very much, that clarifies things immensely! Two more minor things to clarify:

 

1. I am using a message queue to process requests for things like sending trade offers. Am I correct in understanding that there's no need to pause the queue workers upon receiving the `disconnected` event, and only do so on community's `sessionExpired`? Furthermore, according to the docs, `disconnected` will automatically try to reconnect, and thus will trigger both a `loggedOn` event and `webSession` event every time. The correct place to restart the queues is still only after re-setting the cookies after `webSession`, is that correct?

 

2. Lastly, if I call `webLogOn` every now and then and keep setting new cookies, does it pose any risk of interfering with simultaneously running operations?

 

Cheers!

Edited July 16, 2017 by esteamer

[Dr. McKay]

1. 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.
2. No, I don't believe that would be a problem.

[esteamer]

Thanks so much for the help!