Jump to content
McKay Development

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


Recommended Posts

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.

Link to comment
Share on other sites

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 by esteamer
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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  :lol:

Edited by esteamer
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by esteamer
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...