I thought my reset_consumer fix would be sufficient for this . . . but it only works in the happy land of a single user/single access test environment. As soon as any user authorizes (in particular, with Foursquare), that network's OauthToken's consumer will be corrupted, so any future API calls will be directed to the wrong address. It works in the single user/access case simply because there aren't API calls being made concurrently to the auth process.
Any thoughts on the best way to fix this? Is there anything wrong with just building a new consumer every time instead of caching it? (or maybe, every time for auth . . . and only caching for API or something?)
Hey Lance,
I thought my reset_consumer fix would be sufficient for this . . . but it only works in the happy land of a single user/single access test environment. As soon as any user authorizes (in particular, with Foursquare), that network's OauthToken's consumer will be corrupted, so any future API calls will be directed to the wrong address. It works in the single user/access case simply because there aren't API calls being made concurrently to the auth process.
Any thoughts on the best way to fix this? Is there anything wrong with just building a new consumer every time instead of caching it? (or maybe, every time for auth . . . and only caching for API or something?)
-Andrew