Thanks, I'm up again, looks like it was just oauth_verifier that I was missing... Phew..
I'll take some time this week to read the spec in detail and make sure I'm not missing anything else.. Thanks Dave On Dec 2, 10:59 pm, Taylor Singletary <taylorsinglet...@twitter.com> wrote: > Hi Folks, > > We're going to rollback a subset of these changes for now. Before we give > this another try, we'll let everyone know the specific pain points and give > some time to adjust to them. In the meantime, those who experienced trouble > today will want to verify that their libraries are doing the right thing in > regard to the bullet points I posted above. > > Also useful is making sure that you don't send additional headers related to > basic auth in an OAuth request, that you're using the proper, versioned > api-subdomain end points, etc. > > Dave: It's pretty crucial that you send an oauth_verifier on the access > token step. It's not valid OAuth 1.0a without it. > > Sorry about the mess folks. We should never have let these bugs persist for > so long. > > Taylor > > On Thu, Dec 2, 2010 at 2:45 PM, Tom van der Woerdt <i...@tvdw.eu> wrote: > > > > > > > > > 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 -- 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
