Jump to content


Photo
Discussion

TradeOfferManager v2

node.js node-steam-tradeoffer-manager

  • Please log in to reply
31 replies to this topic

#1 Dr. McKay

Dr. McKay

    Developer

  • Administrator
  • 1,998 posts

Posted 02 March 2016 - 02:31 PM

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, 02 March 2016 - 04:07 PM.


#2 PEPZ

PEPZ

    Newbie

  • Member
  • Pip
  • 8 posts

Posted 02 March 2016 - 06:35 PM

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



#3 seaN

seaN

    Newbie

  • Member
  • Pip
  • 2 posts

Posted 02 March 2016 - 07:30 PM

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.



#4 Dr. McKay

Dr. McKay

    Developer

  • Administrator
  • 1,998 posts

Posted 03 March 2016 - 02:48 AM

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)



#5 PEPZ

PEPZ

    Newbie

  • Member
  • Pip
  • 8 posts

Posted 03 March 2016 - 10:03 AM

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.



#6 Dr. McKay

Dr. McKay

    Developer

  • Administrator
  • 1,998 posts

Posted 03 March 2016 - 10:26 AM

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.



#7 seaN

seaN

    Newbie

  • Member
  • Pip
  • 2 posts

Posted 03 March 2016 - 12:01 PM

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



#8 Dr. McKay

Dr. McKay

    Developer

  • Administrator
  • 1,998 posts

Posted 03 March 2016 - 02:10 PM

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

  • Mole and PEPZ like this

#9 PEPZ

PEPZ

    Newbie

  • Member
  • Pip
  • 8 posts

Posted 03 March 2016 - 02:34 PM

How about support for multiple accounts?



#10 Dr. McKay

Dr. McKay

    Developer

  • Administrator
  • 1,998 posts

Posted 03 March 2016 - 02:38 PM

How about support for multiple accounts?

 

I don't understand.



#11 PEPZ

PEPZ

    Newbie

  • Member
  • Pip
  • 8 posts

Posted 03 March 2016 - 02:49 PM

I don't understand.

 

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



#12 Dr. McKay

Dr. McKay

    Developer

  • Administrator
  • 1,998 posts

Posted 03 March 2016 - 02:54 PM

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



#13 Andrew

Andrew

    Newbie

  • Member
  • Pip
  • 6 posts

Posted 04 March 2016 - 03:18 PM

 

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.



#14 Dr. McKay

Dr. McKay

    Developer

  • Administrator
  • 1,998 posts

Posted 04 March 2016 - 08:18 PM

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.

#15 jensej

jensej

    Member

  • Member
  • PipPip
  • 20 posts

Posted 08 March 2016 - 11:49 AM

Maybe checking prices?



#16 Dr. McKay

Dr. McKay

    Developer

  • Administrator
  • 1,998 posts

Posted 08 March 2016 - 02:09 PM

Maybe checking prices?

 

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



#17 Dr. McKay

Dr. McKay

    Developer

  • Administrator
  • 1,998 posts

Posted 08 March 2016 - 10:33 PM

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.



#18 Mole

Mole

    Member

  • Member
  • PipPip
  • 14 posts
  • LocationPoland

Posted 09 March 2016 - 01:57 PM

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.



#19 Dr. McKay

Dr. McKay

    Developer

  • Administrator
  • 1,998 posts

Posted 17 March 2016 - 12:26 AM

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.



#20 kryo

kryo

    Member

  • Member
  • PipPip
  • 17 posts

Posted 19 March 2016 - 11:40 PM

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.







Also tagged with one or more of these keywords: Discussion, node.js, node-steam-tradeoffer-manager

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users