Jump to content
McKay Development

Recommended Posts

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 by Dr. McKay
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

 

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...