Discussion TradeOfferManager v2

[Dr. McKay]

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 setAccessToken
• Hard 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

[PEPZ]

Would it be possible to not have to worry about sessions expiring?

[seaN]

My wish list:

 

1. Promise-based API

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

[Dr. McKay]

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 API

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

[PEPZ]

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.

[Dr. McKay]

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.

[seaN]

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

[Dr. McKay]

Here's an idea. Three options for createOffer():

1. manager.createOffer(steamID); // create an offer without a token. you can set it later
2. manager.createOffer(steamID, token); // create an offer with a token
3. manager.createOffer(tradeURL); // automatically extract the SteamID and token from the trade URL

[PEPZ]

How about support for multiple accounts?

[Dr. McKay]

How about support for multiple accounts?

 

I don't understand.

[PEPZ]

I don't understand.

 

So it would be possible to handle trade offers for multiple Steam accounts. 

[Dr. McKay]

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

[Andrew]

 

Here's an idea. Three options for createOffer():

1. manager.createOffer(steamID); // create an offer without a token. you can set it later
2. manager.createOffer(steamID, token); // create an offer with a token
3. 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.

[Dr. McKay]

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.

[jensej]

Maybe checking prices?

[Dr. McKay]

Maybe checking prices?

 

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

[Dr. McKay]

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.

[Mole]

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.

[Dr. McKay]

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.

[kryo]

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.

[Dr. McKay]

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.

[cookie]

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

[Dr. McKay]

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.

[kryo]

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.

[Dr. McKay]

Fair enough. How about an offerList event that's emitted every time we do a full-update poll?