Jump to content
McKay Development

Has cookies changed?


Porcellian

Recommended Posts

 

yes, i can confirm that the last update did break something. my bots keeps saying "error: not logged in" even after forcing client.webLogOn(); every 5 mins with a cronjob...

var task = cron.schedule('*/5 * * * *', function() {
	console.log('New session (Cronjob)');
	client.webLogOn();
});

client.on('webSession', function(sessionID, cookies) {
	manager.setCookies(cookies, function(err) {
		if (err) {
			console.log(err);
			process.exit(1);
			return;
		}

		console.log("Got API key");
	});

	community.setCookies(cookies);
	client.setPersona(SteamUser.Steam.EPersonaState.Online);
});

community.on('sessionExpired', function(err) {
	if (err) {
		console.log(err);
	}
	
	client.webLogOn();
});

 

I can't reproduce this:

const SteamUser = require('./index.js');
const SteamTotp = require('steam-totp');
const TradeOfferManager = require('steam-tradeoffer-manager');

const SHARED_SECRET = "redacted";

let user = new SteamUser();
let manager = new TradeOfferManager({
	"domain": "doctormckay.com",
	"steam": user
});

user.logOn({
	"accountName": "redacted",
	"password": "redacted",
	"twoFactorCode": SteamTotp.generateAuthCode(SHARED_SECRET)
});

user.on('loggedOn', () => {
	console.log("Logged on");
});

user.on('webSession', (sessionID, cookies) => {
	console.log("Web session id " + sessionID);
	console.log(cookies);

	manager.setCookies(cookies, (err) => {
		console.log(err);
		console.log(manager.apiKey);
	});
});

4dw0r.png

 

Oh alright, so you don't need that cookie to send trades anymore?

 

Does that mean I also have to run my website over an SSL? 

 

I don't think you ever needed it to send trades as long as steamLoginSecure has existed... if you're on a secure connection it ignored steamLogin. You don't need to run your website over HTTPS (although you really should); all connections to Steam have to be done over HTTPS (which my modules have done as long as they could).

Link to comment
Share on other sites

the first trade offer after starting the bot works mostly, but after refreshing the session (forced via cronjob or expired) it will fail with "error: not logged in". webSession gets everytime triggered succesfully, so it looks like that there is some cookie / session problem?

 

Hmm... It must be a cookie/session problem of some sort. What else came with this new steam update?

Link to comment
Share on other sites

Hello, guys. Same issue with WebAuth - doesn't work at all after N period of time. Only possible solution from my sight is to client.logOn(ws login) again. I assume there should be more convenient solution to handle it. Thanks, steam update. Any ideas?

Edited by vmysiur
Link to comment
Share on other sites

as best I can work this out (i'm stupid) web sessions seem to be expiring really quickly now. maybe less than a minute, if there is no activity. successful calls to endpoints that require authentication will keep the session alive, but it has to more or less be continually doing stuff. failing that, the user will have to use webLogOn to refresh.

Edited by byteframe
Link to comment
Share on other sites

as best I can work this out (i'm stupid) web sessions seem to be expiring really quickly now. maybe less than a minute, if there is no activity. successful calls to endpoints that require authentication will keep the session alive, but it has to more or less be continually doing stuff. failing that, the user will have to use webLogOn to refresh.

I can confirm it's something in this direction.

Link to comment
Share on other sites

Wanted to poke my head in and confirm that Valve has done something screwy with the login cookies that results in sessions expiring quickly and seemingly randomly. The code I could repro on was not touched for a month or so at least. So I don't believe it is a bug in either my stuff or steam-community.

 

It doesn't appear to be an issue of session conflicts as I have ensured my code only does that initial AuthenticateUser call and then reuses the cookies/request object for community, store and other httpRequest endpoints. So it would seem that something Steam side is deciding they need to be expired ASAP.

 

Calling webLogOn instead of the webauth protobuf that logOn calls automatically seems to be *slightly* more reliable. Not sure what can be done here besides calling webLogOn on a timer. Is this what the client does now or something? Would definitely explain the "Verifying login information" interstitial every other page.

Link to comment
Share on other sites

Assuming this is all the new normal, (and pending any built in mitigation from a future node-steam-user update), you will all have to implement some kind of keep-alive system within your own code.

 

First, once you establish a web session, you should run an authorized POST call to an endpoint, if you're code isnt going to do that very soon thereafter. For a dummy, I recommend 'my/commentnotifications' with your sessionid and action: 'markallread', I guess. This first call seems to be important for keeping the session alive for whatever is the normal time, lets say a minute. Without that call I've had bots get sessionExpired just several seconds after getting their first session.

 

Overall though, the idea is such that If you don't do anything on your websession it will 'shortly' logout, (sessionExpired: Error: Not Logged In), If your bot is active throughout, it generally doesnt seem to lose the session.

 

If not, after a period of inactivity, the bot's next call to an authorized endpoint on steam will fire off the sessionExpired event. Typically you will have defined that event handler to call webLogon again; but the call still fails though and can cock up your code accordingly.

 

You can implement a retry system that waits a second for the new session before retrying, or you can maybe prevent the failures by knowing when to, or otherwise prempting them by calling webLogon manually. I do the former, because I can coordinate on one call to retry, blah blah, but chances are others might have more pain.

 

I doubt using setInterval to periodically refresh the session is a good idea. Also this is only affecting me in my calls to community.httpRequest, I dont use the trade modules or know how those are affected.

Link to comment
Share on other sites

Also, some calls to endpoints do not fire the sessionExpired event, but just report 'NotLoggedOn' in the error result. Also straight up GET calls to steamcommunity.com pages will not show from the view of the user if the session is lost, and you can detect this by the presence of 'g_steamid = false' in the body.

Link to comment
Share on other sites

Assuming this is all the new normal, (and pending any built in mitigation from a future node-steam-user update), you will all have to implement some kind of keep-alive system within your own code.

 

First, once you establish a web session, you should run an authorized POST call to an endpoint, if you're code isnt going to do that very soon thereafter. For a dummy, I recommend 'my/commentnotifications' with your sessionid and action: 'markallread', I guess. This first call seems to be important for keeping the session alive for whatever is the normal time, lets say a minute. Without that call I've had bots get sessionExpired just several seconds after getting their first session.

 

Overall though, the idea is such that If you don't do anything on your websession it will 'shortly' logout, (sessionExpired: Error: Not Logged In), If your bot is active throughout, it generally doesnt seem to lose the session.

 

If not, after a period of inactivity, the bot's next call to an authorized endpoint on steam will fire off the sessionExpired event. Typically you will have defined that event handler to call webLogon again; but the call still fails though and can cock up your code accordingly.

 

You can implement a retry system that waits a second for the new session before retrying, or you can maybe prevent the failures by knowing when to, or otherwise prempting them by calling webLogon manually. I do the former, because I can coordinate on one call to retry, blah blah, but chances are others might have more pain.

 

I doubt using setInterval to periodically refresh the session is a good idea. Also this is only affecting me in my calls to community.httpRequest, I dont use the trade modules or know how those are affected.

 

What endpoint or method I have to use to keep alive my session?

Can you give me an example please bro? :(

Link to comment
Share on other sites

  • 2 weeks later...

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...