Dr. McKay

This is expected behavior. You can only use a token generated with EAuthTokenPlatformType.SteamClient with steam-user. This is expected behavior. renewRefreshToken() does not work for EAuthTokenPlatformType.WebBrowser.

This is a known issue, see: https://github.com/DoctorMcKay/node-steamcommunity/issues/321 community.login isn't going to work until I can finish the v4 rewrite. Until then, you can either use steam-session or steam-user to get login cookies for use with steamcommunity.

The solution is to stop using unsupported, deprecated libraries and migrate to things that are supported. For logging into web, steam-session is what you're looking for.

Update steam-user to v4.29.0 or later using npm.

Update to v4.29.0 or later.

client.setPersona(SteamUser.Steam.EPersonaState.Online, Config.access.setNickname) This line tells me that you're using steam-user v3.x.x or earlier, as SteamUser.Steam was removed in v4.0.0.

Version?

You can't log on with SteamUser using cookies; they're only for web sessions, which SteamUser isn't using. SteamUser will automatically save your machine authorization as long as local storage is available (which it should be in most cases), but if you need to manually handle machine auths, check out this section in the docs. You can also use a refresh token to log on, which is sort of like SteamUser's version of a cookie. That's documented here.

Technically only the owner of the asset is supposed to see the tradable after time, but you can use the ISteamEconomy/GetAssetClassInfo WebAPI method to retrieve those owner descriptions.

No, this isn't possible at the moment, but it could be possible to add support for doing that.

Assuming from your post context that you want to cancel counter offers that weren't sent by your bot, use the unknownOfferSent event. Unfortunately, there's no way using the data provided by Steam to link an offer to the original offer that was countered to create it.

When you counter an offer, a new trade offer is created with a new ID, and the original's state is set to Countered. You need to cancel the new offer.

Every website out there (that doesn't use HTTP authentication) uses cookies to identify user sessions. Cookies usually contain session IDs, which are looked up on the server in order to determine who the session belongs to. Steam is no different. All Steam websites (the store, community, the help site) use the same cookies to identify user sessions. In order to identify a Steam session, only a single steamLoginSecure cookie is required. You may also see a sessionid cookie. Despite its name, this cookie is merely a CSRF token (this is verified on Steam's cookie preferences page). Its value can be anything, as long as it matches the sessionid parameter in your state-mutating requests (which should ordinarily only be POST requests, but Valve is Valve and they use GET for some mutation requests). Steam will randomly assign you one the first time you hit one of the websites without already having one, even if you aren't logged in. They are not tied to accounts or to sessions. steamLoginSecure is the actual session cookie. It begins with your 64-bit SteamID, followed by two pipe characters percent-encoded as %7C, and then a JWT. If you want to know when your cookie expires, you can decode the JWT and check the exp field. Your IP address is also encoded into the JWT, and it appears that your session may be invalidated if you make a request from a differing IP address. Steam Guard auths are handled by the new auth server, and aren't described here. They don't appear to be used if you're using TOTP as your authenticator. How to Get Cookies The auth server launched in August 2022, alongside the beta of the new Steam Mobile App. The auth server provides a unified authentication interface that is consistent between the three Steam platforms (desktop client, website, mobile app). As of time of writing (2023-10-01), all of the old auth schemes still work, but this can't be expected to remain the case forever. Upon successful authentication, the auth server issues an access token and a refresh token. Access tokens are used for the steamLoginSecure cookie. Refresh tokens are used to get new access tokens, and also are used to log into the Steam client. If you want to maintain a session for an extended duration without re-entering your password (or putting it into a config file), refresh tokens are the way to do it. The steam-session npm package was created to interface with the auth server. If you need login cookies, this is the best way to get them. If you're already using steam-user or steamcommunity, they are using steam-session internally to generate cookies. Outside of special cases, there's no reason for you to use steam-session directly if you're already using steam-user or steamcommunity. steam-user steam-user uses steam-session for authentication as of v4.28.0, and cookies are generated using the new auth scheme as of v4.29.0. Use the webSession event to acquire your cookies. Cookies generated this way will be invalidated when your SteamUser client disconnects. steamcommunity steamcommunity uses steam-session for authentication as of v4.0.0. Cookies are returned to you when the login() method promise resolves. Cookie Usage I'll briefly explain how cookies and sessions work in my libraries. A quick overview on statefulness: HTTP is stateless. Each request is distinct from every other request, and thus there is no way to link two requests together, except by using cookies. steam-user connects to CMs (connection managers, i.e. Steam servers) using long-lived TCP connections. This is a stateful connection, and there's no need to use cookies here. steam-user is capable of producing cookies, but it does not save them and doesn't use them in any way except to make them available to the end-user for use elsewhere. steamcommunity interacts with Steam over HTTP, which does require cookies to authenticate requests. steamcommunity can either accept cookies using the setCookies() method (which can accept cookies obtained by any means, including steam-user), or it can produce cookies by using the login method (which internally uses steam-session). Either method will save the cookies internally in the SteamCommunity object, and those cookies will be used to authenticate every HTTP request. steamstore is identical to steamcommunity, although it cannot create cookies and can only accept them using setCookies(). steam-tradeoffer-manager is identical to steamstore, except it uses steamcommunity internally for HTTP communication. Thus, if you instantiate TradeOfferManager and pass a community instance to the constructor, then calling setCookies() on the TradeOfferManager instance will also call setCookies() on the SteamCommunity instance. Therefore, you don't need to call setCookies() on the SteamCommunity instance in this case (although it doesn't hurt anything, either). steam-session is what every producer module uses internally to authenticate with Steam and to produce cookies. If you only need session cookies and don't need to make use of any other modules' features, then you can use steam-session directly. Here's a summary table, where a producer can create cookies and a consumer can use cookies. Producer Consumer steam-user ✅ steamcommunity ✅ ✅ steamstore ✅ steam-tradeoffer-manager ✅ steam-session ✅

In that example, put it where it says "sharedSecret".

The "move authenticator" feature hasn't been implemented in node, to my knowledge.

Yeah, that does seem like the identity secret is wrong. It's possible that it's being corrupted when fed into your env var, since secrets can contain special characters that might break in terminal input.

You could certainly use it to do that, yes.

Make sure your clock is right.

That's not presently a supported feature, but 1.4.0 was just published which adds the ability for you to pass in a custom https.Agent, which would allow you to bind to a particular local address.

No reason I'd expect it not to work. It's the same game.

I've never seen Revoked come through the error event, it should be LogonSessionReplaced for this issue. That said, logonID might not be working for you because it's supposed to be an integer, but Math.random() * 100000000 will instead return a float. You should round it with Math.floor().

steam-user 4.29.0 is what fixed your problem. Prior to that version, steam-user used the old sentryfile system, which Steam doesn't use anymore.

Are you on 5.0.1? There was a bug in 5.0.0 that prevented those files from being read properly.

Cannot reproduce. I set up my inventory with 333 untradable gems and 1,097 tradable gems, then tried to create a 1,200 gem booster pack and I got the expected error 78 ValueOutOfRange.