Jump to content


Photo

Has cookies changed?


  • Please log in to reply
15 replies to this topic

#1 Porcellian

Porcellian

    Newbie

  • Member
  • Pip
  • 3 posts

Posted 24 October 2018 - 09:41 AM

Hello,

 

I wonder if the steam webcookies has changed?

Because now when I print them, I see "SteamCountry, steamLoginSecure, SteamMachineAuth, SteamRememberLogin, sessionid, browserid".

 

Where is the "SteamLogin" cookie? Is it nescessary anymore? And is browserid a new thing that is nescessary?



#2 Dr. McKay

Dr. McKay

    Developer

  • Administrator
  • 1,787 posts

Posted 24 October 2018 - 02:07 PM

steamLogin probably went away because Steam can only be accessed over HTTPS now. browserid is unnecessary.



#3 nimorida

nimorida

    Newbie

  • Member
  • Pip
  • 2 posts

Posted 24 October 2018 - 03:00 PM

del


Edited by nimorida, 25 October 2018 - 06:14 AM.


#4 Porcellian

Porcellian

    Newbie

  • Member
  • Pip
  • 3 posts

Posted 24 October 2018 - 03:07 PM

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? 



#5 Dr. McKay

Dr. McKay

    Developer

  • Administrator
  • 1,787 posts

Posted 24 October 2018 - 03:19 PM

 

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



#6 Porcellian

Porcellian

    Newbie

  • Member
  • Pip
  • 3 posts

Posted 24 October 2018 - 03:33 PM

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?



#7 vmysiur

vmysiur

    Member

  • Member
  • PipPip
  • 22 posts

Posted 25 October 2018 - 12:23 PM

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, 25 October 2018 - 12:24 PM.


#8 byteframe

byteframe

    Newbie

  • Member
  • Pip
  • 8 posts

Posted 25 October 2018 - 05:33 PM

I can also report this new problem of 'web sessions constantly expiring' or something to that effect. I thought it was just me.



#9 byteframe

byteframe

    Newbie

  • Member
  • Pip
  • 8 posts

Posted 25 October 2018 - 09:05 PM

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, 25 October 2018 - 09:05 PM.


#10 Heartz

Heartz

    Newbie

  • Member
  • Pip
  • 1 posts

Posted 26 October 2018 - 10:27 AM

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.



#11 Lagg

Lagg

    Newbie

  • Member
  • Pip
  • 8 posts

Posted 27 October 2018 - 12:29 PM

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.



#12 KaMilml

KaMilml

    Newbie

  • Member
  • Pip
  • 8 posts

Posted 27 October 2018 - 05:07 PM

Same problem here :'(
Any idea?



#13 TradeMan

TradeMan

    Newbie

  • Member
  • Pip
  • 1 posts

Posted 31 October 2018 - 05:37 PM

The same problem, the session crashes in 30 minutes and the Weblogon, LogOn does not help.


Edited by TradeMan, 01 November 2018 - 04:24 AM.


#14 byteframe

byteframe

    Newbie

  • Member
  • Pip
  • 8 posts

Posted 31 October 2018 - 08:15 PM

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.



#15 byteframe

byteframe

    Newbie

  • Member
  • Pip
  • 8 posts

Posted 31 October 2018 - 08:22 PM

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.



#16 KaMilml

KaMilml

    Newbie

  • Member
  • Pip
  • 8 posts

Posted 06 November 2018 - 11:30 PM

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? :(






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users