Dr. McKay

Nobody can really help without seeing your code.

newOffer isn't emitted for sent offers. Also, please update to the latest version.

Read the documentation. Specifically you need to save the steamguard value from the callback of login and provide it to subsequent calls to login.

Reposting this as I would like some feedback if anyone has it. At this point I like the trade URL idea enough that I'm potentially willing to just accept the risks and put a big bold warning in the docs.

Good catch, that's indeed a bug. Fixed in v1.20.2. Were you on the beta version when you first made this thread?

You have no options with steam-tradeoffer-manager. There might be some modules that scrape the HTML instead, but you're in for a really bad time if you try that. I don't know what it's called or if it's maintained.

You use node-steam-totp to generate a login code from your shared_secret, and pass it to node-steamcommunity's login method as twoFactorCode.

That really doesn't have any place in this module.

Yes, that's the best (and only) way to do it. You need an API key if you want to use the WebAPI. Based on your error message I assume that you're using steam-tradeoffer-manager, which does need an API key and consequently won't work with limited accounts. So yes, you'll need to spend $5 per bot.

Your own account? Or someone else's account? If you want games someone else owns, there's a WebAPI method for that.

I don't know an awful lot about CS:GO, but I know that you can't inspect any tools. I don't know if there are any skins that can't be inspected.

https://httpstatuses.com/500 500 just means Steam is broken and you'll have to try again later. There isn't anything you can do.

1. Calling login() again with your username and password is guaranteed to renew your session (unless Steam is having problems). The oAuthLogin method is supposed to do this, but I believe it doesn't work 100% as expected. 2. There isn't any event. Currently you just have to check loggedIn every so often. The next update will most likely add such an event.

You can't inspect stickers.

Just pass true for that argument, and in the callback the items will have an actions array defined and populated with the inspect link (and any other applicable actions).

I just thought of a potential issue with using just the trade URL. Presently you have to construct an offer using a SteamID explicitly. Getting the ID from the URL opens sloppy implementations to the potential for users to send offers to other users. For example, a typical implementation currently has a user sign in through Steam's OpenID, then prompts the user for their trade URL. Both of these are sent to the bot. The offer is created using the authenticated SteamID, and the token is extracted from the URL. If the trade URL isn't for that user's account, the offer just fails. With the proposed new API, a user could enter someone else's trade URL. If the implementation doesn't check offer.partner, then unrelated users could receive unsolicited offers. Of course, we could add a note to the documentation to check offer.partner when you use a trade URL, but I don't really like the loss of the built-in safeguard.

The way I generally do it is set up a bot in node.js using steam-tradeoffer-manager, and create a Web server in that bot which accepts commands to send trade offers. Then use curl in php to command the bot to send an offer. I believe there are php libraries for interacting with Steam, but I don't personally think php is well suited for that task.

Yes, that will work fine. Note that on Windows, the sentry (ssfn) file that the client uses is hidden. The visible one is a decoy. The sentry file used by the client is named in config/config.vdf (if I remember correctly).

You can already create a TradeOfferManager for separate accounts within the same application.

I don't understand.

Here's an idea. Three options for createOffer(): manager.createOffer(steamID); // create an offer without a token. you can set it later manager.createOffer(steamID, token); // create an offer with a token manager.createOffer(tradeURL); // automatically extract the SteamID and token from the trade URL

Moved to general. I'm not sure what the limit is, to be honest. I believe that if you keep it to around 0.5 req/sec you should be good.

I've thought of that, but cookies can come from any source. For example, node-steam-user or node-steamcommunity, but there are also third-party sources. Really the refreshing should be done by your app.

That's rather difficult, as Steam just kills sessions whenever it feels like it. #1 is possible, although not likely to happen for v2. #2 is doable, although I'm not incredibly happy with just cramming a bunch of stuff into createOffer() #3 is doable without any breaking changes, although it's already relatively easy to implement yourself (just call getOffers() and check each one)

I'm planning on releasing a new major version of steam-tradeoffer-manager of v2.0.0. So far, what I'm planning to do is: Move token and message out of the TradeOffer#send() method and into methods like setMessage and setAccessTokenHard requirement for node.js v4.0.0 or later (currently package.json suggests that you need v4 or later, but v2 would make this an absolute requirement)This should be addressed.Since this is a major change and they're meant to be few and far between, there's no point in wasting it! If you have any suggestions of stuff that could be added, or things that have just annoyed you, I'd love to hear them!