Dr. McKay Posted March 2, 2016 Report Share Posted March 2, 2016 (edited) 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! Edited March 2, 2016 by Dr. McKay Quote Link to comment Share on other sites More sharing options...
PEPZ Posted March 2, 2016 Report Share Posted March 2, 2016 Would it be possible to not have to worry about sessions expiring? Quote Link to comment Share on other sites More sharing options...
seaN Posted March 3, 2016 Report Share Posted March 3, 2016 My wish list: 1. Promise-based API2. If you're moving token and message into setters, it'd be nice to be able to specify them when the trade offer is created instead of having to make more method calls.3. The ability to determine if an item already exists in a pending trade (not sure if this is possible) That's all I have right this second, but I may have more later. Quote Link to comment Share on other sites More sharing options...
Dr. McKay Posted March 3, 2016 Author Report Share Posted March 3, 2016 Would it be possible to not have to worry about sessions expiring? That's rather difficult, as Steam just kills sessions whenever it feels like it. My wish list: 1. Promise-based API2. If you're moving token and message into setters, it'd be nice to be able to specify them when the trade offer is created instead of having to make more method calls.3. The ability to determine if an item already exists in a pending trade (not sure if this is possible) That's all I have right this second, but I may have more later. #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) Quote Link to comment Share on other sites More sharing options...
PEPZ Posted March 3, 2016 Report Share Posted March 3, 2016 About the sessions, how about an internal refresher? By default it would refresh cookies for example every hour but an option for the user to set it to whatever. Quote Link to comment Share on other sites More sharing options...
Dr. McKay Posted March 3, 2016 Author Report Share Posted March 3, 2016 About the sessions, how about an internal refresher? By default it would refresh cookies for example every hour but an option for the user to set it to whatever. 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. Quote Link to comment Share on other sites More sharing options...
seaN Posted March 3, 2016 Report Share Posted March 3, 2016 #2 is doable, although I'm not incredibly happy with just cramming a bunch of stuff into createOffer() Token, at least, seems to fit with the createOffer call. Message is kind of a weird one. Quote Link to comment Share on other sites More sharing options...
Dr. McKay Posted March 3, 2016 Author Report Share Posted March 3, 2016 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 PEPZ and Mole 2 Quote Link to comment Share on other sites More sharing options...
PEPZ Posted March 3, 2016 Report Share Posted March 3, 2016 How about support for multiple accounts? Quote Link to comment Share on other sites More sharing options...
Dr. McKay Posted March 3, 2016 Author Report Share Posted March 3, 2016 How about support for multiple accounts? I don't understand. Quote Link to comment Share on other sites More sharing options...
PEPZ Posted March 3, 2016 Report Share Posted March 3, 2016 I don't understand. So it would be possible to handle trade offers for multiple Steam accounts. Quote Link to comment Share on other sites More sharing options...
Dr. McKay Posted March 3, 2016 Author Report Share Posted March 3, 2016 You can already create a TradeOfferManager for separate accounts within the same application. Quote Link to comment Share on other sites More sharing options...
Andrew Posted March 4, 2016 Report Share Posted March 4, 2016 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 I really like this idea. Having the option to use your trade URL would mean less parsing and cleaner code on the server/bot side. Quote Link to comment Share on other sites More sharing options...
Dr. McKay Posted March 5, 2016 Author Report Share Posted March 5, 2016 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. Quote Link to comment Share on other sites More sharing options...
jensej Posted March 8, 2016 Report Share Posted March 8, 2016 Maybe checking prices? Quote Link to comment Share on other sites More sharing options...
Dr. McKay Posted March 8, 2016 Author Report Share Posted March 8, 2016 Maybe checking prices? That really doesn't have any place in this module. Quote Link to comment Share on other sites More sharing options...
Dr. McKay Posted March 9, 2016 Author Report Share Posted March 9, 2016 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. 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. Quote Link to comment Share on other sites More sharing options...
Mole Posted March 9, 2016 Report Share Posted March 9, 2016 I have nothing against the feature itself, just can't think of any valid use case.Storing trade URL in any kind of database is pointless. Of course - getting it directly from the user every trade is fine, but it's rather unusual, and in most cases script owners would convert the URL to get the id anyway (eg. for logging). Also, covering this potential security issue is (imo) what the script owner should do, not the module itself. Quote Link to comment Share on other sites More sharing options...
Dr. McKay Posted March 17, 2016 Author Report Share Posted March 17, 2016 I think I'm also going to change how poll data saving/restoration works, making it a string instead of an object, removing the need to JSON.stringify and JSON.parse. Quote Link to comment Share on other sites More sharing options...
kryo Posted March 20, 2016 Report Share Posted March 20, 2016 It would be great to have custom hooks for the polling, to handle offers that haven't changed since the last poll. I would use this for declining any incoming offers that get too old.If the pollData event sent the offer's time_updated along with the ID and status I could do this very easily. Quote Link to comment Share on other sites More sharing options...
Dr. McKay Posted March 20, 2016 Author Report Share Posted March 20, 2016 Hooks for polling is kind of weird in my opinion. What's your use case for declining old incoming offers? There's no limit there and I don't see any reason why you wouldn't be able to act on an offer immediately when newOffer is emitted. Quote Link to comment Share on other sites More sharing options...
cookie Posted March 20, 2016 Report Share Posted March 20, 2016 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. Extracting the token from a trade url isn't a big issue, however I would stick to tokens since it's straight forward. if the token isn't validated means the token doesn't belong to the SteamID provided or is invalid. extracting a token can be as simple as it sounds, but i believe the act of sending an offer via a trade url is more of a hassle than sending an offer via tokens (as it needs more functions). Quote Link to comment Share on other sites More sharing options...
Dr. McKay Posted March 21, 2016 Author Report Share Posted March 21, 2016 Extracting the token from a trade url isn't a big issue, however I would stick to tokens since it's straight forward. if the token isn't validated means the token doesn't belong to the SteamID provided or is invalid. extracting a token can be as simple as it sounds, but i believe the act of sending an offer via a trade url is more of a hassle than sending an offer via tokens (as it needs more functions). I'm not sure we're on the same page. Allowing the usage of a trade URL wouldn't remove the ability to use a SteamID and token separately. Quote Link to comment Share on other sites More sharing options...
kryo Posted March 22, 2016 Report Share Posted March 22, 2016 Hooks for polling is kind of weird in my opinion. What's your use case for declining old incoming offers? There's no limit there and I don't see any reason why you wouldn't be able to act on an offer immediately when newOffer is emitted. If you offered a custom pollData format that would fix it for me.It's just kinda an edge case where if we receive an offer, add to poll data, and put a setTimeout(offer.decline, 30000) the offer might not get declined, for example if the bot goes down. Quote Link to comment Share on other sites More sharing options...
Dr. McKay Posted March 22, 2016 Author Report Share Posted March 22, 2016 Fair enough. How about an offerList event that's emitted every time we do a full-update poll? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.