OAuth not generating new request tokens!

[micahbrich]

Hey there!

I've been playing around with the gem quite a bit the last few days, and I've been having trouble getting it working in production for really only one reason – new request tokens weren't being issued. I'm realizing now it may not be just in production.

Person A would have no problem generating a request token, hitting allow & being taken to the callback, where I could save the access token, just like in the readme. But then Person B would come along, and it would be the exact some request token as Person A, so Etsy would say "sorry, that's been used already."

I thought at first it was because it was getting hung up on the fact that @request_token already existed, but I'm not sure.

class VerificationRequest # :nodoc:all
  def request_token
    @request_token ||= client.request_token
  end
end

I tested out what would happen with manually setting @request_token as false right before (and as a different test, right after), to force it to request a new token, but found that that just ended up with each person being connected to the last person's OAuth credentials. Not so good.

I'll keep trying stuff and seeing what I can find, do you guys have any ideas?

[kytrinyx]

I ran into something similar recently, and didn't have time to dig into it. I'm stuck in a cabin on a mountain right now, but on monday I'll be back in civilization, and would be happy to help debug and fix. If you want to do some remote pair programming on it let me know, and we can share a screen session or something.

[micahbrich]

That sounds cool. If you want to switch places, a cabin in the mountain sounds incredible. Send me a message whenever, I'd be happy to help if I can. In the meantime, I've just done the OAuth verification using the regular ol' oauth gem, which so far seems to be working.

[kytrinyx]

I've committed a fix for this. Let me know if you run into any issues with it.

[micahbrich]

Hey awesome! I'll check it out and see how it goes, thanks for working on it! :-)

[kytrinyx]

I just wanted to mention that I'm still seeing some issues with the etsy gem holding on to oauth tokens too long and giving them to the wrong person, so I'm going to be going through this with a fine-tooth comb in the next couple of days.

[reagent]

Katrina, do you have steps to reproduce this? I could take a stab at it this weekend as well.

[kytrinyx]

Yepp, using this gist: https://gist.github.com/791872

This is what I did:

1. From localhost:4567 click 'authorize', and log in to etsy as PaisleyAnnHome
2. Click to view profile, and see 'logged in as PaisleyAnnHome'
3. Go back to localhost:4567, click 'authorize'
4. At etsy, switch to different user (circuit) and authorize
5. Click to view profile
   => Expected to see 'logged in as circuit', but saw 'logged in as PaisleyAnnHome'.

[kytrinyx]

This is what I found: on line 124 of lib/etsy.rb we memoize the access token, thus giving the calling code back the previous client, regardless of the request token/secret that is being passed in.

We could probably check an existing client against the request token and generate a new client if the tokens don't match, but this time around I'm simply clearing out the @access_token at the same time as the @verification_request when someone starts a new verification against etsy.

[kytrinyx]

After thinking about this a little longer, I decided to always ask for a new client if asking for an access token, so that it generates the access tokens based on the request tokens passed in, rather than any memory of what has gone before.