Waiting doesn't help solve the issue. The spec hasn't changed, the API is just a bit more watching for the mistakes which some developers tend to make.

I'd recommend diving into the code and fixing the errors, instead of asking the Twitter API team to accept your "broken" OAuth implementations. :-)

Tom


On 12/2/10 11:42 PM, LeeS - @semel wrote:
I am using this library on all my sites: 
https://github.com/jmathai/twitter-async,
all of which are now broken and fail to let anyone log in.

Any way this can be rolled back until all the various oAuth libraries
people are using are brought up to date?

Lee

On Dec 2, 5:35 pm, Dave-twiends<i...@davesumter.com>  wrote:
Thanks Taylor, yip unfortunately I wrote my oauth code about 18 months
ago, before most of the libraries were out, so there could be anything
wrong. It's probably not 100% spec compliant, which is probably why it
broke.

I've tracked down the issue to the access_token exchange part of the
process. The access token's that I have from before are still working,
just can't get new ones. I've noticed I'm not passing oauth_verifier
back in the request, which could be causing the issue..

Will let you guys know how I get on...

Thanks for the pointers
Dave

On Dec 2, 9:57 pm, Taylor Singletary<taylorsinglet...@twitter.com>
wrote:

We've corrected a number of long-standing OAuth-related bug fixes -- mainly
in areas where we more liberal than we should have been when verifying
signatures.

Here are a few things to verify:

* Verify that you are using your consumer key where the consumer key is
supposed to go. Compare this to what you see for you app on dev.twitter.com
* Likewise, verify that you are using your consumer secret where it is
supposed to go. Compare this to what you see for you app on dev.twitter.com
* Laugh at the obviousness and absurdity of a check like that. Cry a little
because we already know some people were doing the wrong thing here,
especially on end points that didn't require authentication.
* Verify that your timestamps are in range
* If you're sending a request to a resource that doesn't require
authentication but you're including OAuth credentials:
    - we used to just give you a free pass even if the credentials were
incorrect. Hey, it doesn't require auth, so why bother checking?
    - now we check this. if you pass us an OAuth header or anything that
looks like an OAuth-based request, we will check it for validity, even if
it's a resource that doesn't require auth.

We haven't changed anything about our actual core signature validation code
-- what was a valid signature before should be a valid one now. We're just
checking the validity in more use cases than we were previously, and
checking other validity points we were flexible with previously.

Taylor

On Thu, Dec 2, 2010 at 1:32 PM, Twitlonger<stu...@abovetheinternet.org>wrote:

I'm seeing a lot of invalid/expired token errors.

On Dec 2, 9:21 pm, Dave-twiends<i...@davesumter.com>  wrote:
I noticed I've just started getting 401's for all my oAuth requests.
Seems to be happening on more than one site for me.. My application
keys and status still look good..

Just wondering if anyone else is having an issue..?

--
Twitter developer documentation and resources:http://dev.twitter.com/doc
API updates via Twitter:http://twitter.com/twitterapi
Issues/Enhancements Tracker:
http://code.google.com/p/twitter-api/issues/list
Change your membership to this group:
http://groups.google.com/group/twitter-development-talk


--
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk

Reply via email to