[twitter-dev] Re: oAuth still working for everyone.?
On Dec 2, 10:59 pm, Taylor Singletary wrote: > 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. In case anyone else was baffled by the lack of an oauth_verifier token, currently you only get that token back if you include an oauth_callback in your initial request for a request token. There's a thread about this (including how to get it working with python-oauth2) on Quora here: http://qr.ae/ppxW -- 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-dev] Re: oAuth still working for everyone.?
Twitter4J is ok See this: http://www.springone2gx.com/blog/andrew_glover/2010/09/oauth_ing_twitter_with_twitter4j It's the parameters you pass to twitter.getOAuthAccessToken() On Dec 3, 12:13 am, Yusuke wrote: > Hi, > > I had confirmed the error message several hours ago and was looking > into it. > And somehow I don't see the error now. > > Please give it a try once again. > If the problem persists, please post the exception stacktrace to > twitte...@googlegroups.com.http://twitter4j.org/en/index.html#mailingList > > Thanks, > Yusuke > > On Dec 3, 10:09 am, Hector wrote: > > > Does anyone using twitter4j solve the oauth_verifier issue? > > > Thanks! -- 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-dev] Re: oAuth still working for everyone.?
Yeah, I second that.. A sandbox authorize/request_token/access_token set of pages will be great... We could use these to check our implementations are up to spec with the revision.. Thanks On Dec 4, 5:19 pm, gumbah wrote: > Thanks for the roll back Taylor, > > both my Twitter apps were broken because of this... Since the roll > back they're working again. > > We want to fix our code, but is there any way to check if the fixes we > made to our code fix the (future)problem? > > cheers, > G > > On Dec 2, 11:59 pm, Taylor Singletary > 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 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 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 > > >>> 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 > >wrote: > > > >>> I'm seeing a lot of invalid/expired token errors. > > > >>> On Dec 2, 9:21 pm, Dave-twiends 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.
[twitter-dev] Re: oAuth still working for everyone.?
Thanks for the roll back Taylor, both my Twitter apps were broken because of this... Since the roll back they're working again. We want to fix our code, but is there any way to check if the fixes we made to our code fix the (future)problem? cheers, G On Dec 2, 11:59 pm, Taylor Singletary 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 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 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 > >>> 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 >wrote: > > >>> I'm seeing a lot of invalid/expired token errors. > > >>> On Dec 2, 9:21 pm, Dave-twiends 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: > >>>
[twitter-dev] Re: oAuth still working for everyone.?
I _think_ I've patched my oauth_verifier in my implementation, however Taylor it's going to take us a good two weeks to get it through Apple's approval process. Not to mention the Mac App Store where we can't submit updates until they launch it! Strange I know, so that one is in limbo right now. However just a quick request, not to turn that on again for a little bit please :) Until at least we've all got our implementations through the relevant approval processes, for those of us that rely on a third party, such as Apple for our deployment process. Many thanks Richard On Dec 3, 6:20 am, Hector wrote: > Seems that Twitter rolled back some of the changes a few hours ago, > right now is working. > > On Dec 3, 12:13 am, Yusuke wrote: > > > > > Hi, > > > I had confirmed the error message several hours ago and was looking > > into it. > > And somehow I don't see the error now. > > > Please give it a try once again. > > If the problem persists, please post the exception stacktrace to > > twitte...@googlegroups.com.http://twitter4j.org/en/index.html#mailingList > > > Thanks, > > Yusuke > > > On Dec 3, 10:09 am, Hector wrote: > > > > Does anyone using twitter4j solve the oauth_verifier issue? > > > > Thanks! -- 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-dev] Re: oAuth still working for everyone.?
Seems that Twitter rolled back some of the changes a few hours ago, right now is working. On Dec 3, 12:13 am, Yusuke wrote: > Hi, > > I had confirmed the error message several hours ago and was looking > into it. > And somehow I don't see the error now. > > Please give it a try once again. > If the problem persists, please post the exception stacktrace to > twitte...@googlegroups.com.http://twitter4j.org/en/index.html#mailingList > > Thanks, > Yusuke > > On Dec 3, 10:09 am, Hector wrote: > > > Does anyone using twitter4j solve the oauth_verifier issue? > > > Thanks! -- 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-dev] Re: oAuth still working for everyone.?
Hi, I had confirmed the error message several hours ago and was looking into it. And somehow I don't see the error now. Please give it a try once again. If the problem persists, please post the exception stacktrace to twitte...@googlegroups.com. http://twitter4j.org/en/index.html#mailingList Thanks, Yusuke On Dec 3, 10:09 am, Hector wrote: > Does anyone using twitter4j solve the oauth_verifier issue? > > Thanks! -- 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-dev] Re: oAuth still working for everyone.?
Update to the latest version. oauth_verifier was added earlier this month. On Dec 2, 3:41 pm, "LeeS - @semel" wrote: > The open source library I was using omitted oauth_verifier, which > apparently was not required for oauth to work previously. > > Thanks to Dave & Taylor for pointing this out. > > Lee > > On Dec 2, 6:09 pm, Dave-twiends wrote: > > > 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 > > 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 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 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 > > > >>> 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 previ
[twitter-dev] Re: oAuth still working for everyone.?
Does anyone using twitter4j solve the oauth_verifier issue? Thanks! -- 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
Re: [twitter-dev] Re: oAuth still working for everyone.?
My library is also OAuth 1.0a compliant: https://github.com/themattharris/tmhOAuth @themattharris Developer Advocate, Twitter http://twitter.com/themattharris On Thu, Dec 2, 2010 at 4:55 PM, Mike Davis (mcdavis) wrote: > Anyone using PHP can use https://github.com/abraham/twitteroauth . > It supports the oauth_verifier (as of its most recent update). > Earlier versions of twitteroauth didn't support it and had a different > parameter order for making requests, so if you're updating, be sure to > check those things out. > > This guide will help those looking to be walked through a bit too - > > http://blancer.com/tutorials/73877/how-to-authenticate-users-with-twitter-oauth/ > > On Dec 2, 7:19 pm, kprobe wrote: > > I am using TwitterEPI library. Mine was out of date. Uploaded the > > newest version and my app now works. > > Mark > > > > On Dec 2, 7:06 pm, Tim Haines wrote: > > > > > > > > > > > > > > > > > Hey Taylor, > > > > > Thanks for rolling this back. It seems odd that you'd push this out > without > > > notice when you know it will break apps. Or was there notice > somewhere? > > > > > Can you deploy your new code to a test endpoint so people (myself > included) > > > can test that their new code complies with your new requirements? > > > > > Cheers, > > > > > Tim. > > > > > On Fri, Dec 3, 2010 at 7:59 AM, 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 > 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 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 > > > > 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
[twitter-dev] Re: oAuth still working for everyone.?
Anyone using PHP can use https://github.com/abraham/twitteroauth . It supports the oauth_verifier (as of its most recent update). Earlier versions of twitteroauth didn't support it and had a different parameter order for making requests, so if you're updating, be sure to check those things out. This guide will help those looking to be walked through a bit too - http://blancer.com/tutorials/73877/how-to-authenticate-users-with-twitter-oauth/ On Dec 2, 7:19 pm, kprobe wrote: > I am using TwitterEPI library. Mine was out of date. Uploaded the > newest version and my app now works. > Mark > > On Dec 2, 7:06 pm, Tim Haines wrote: > > > > > > > > > Hey Taylor, > > > Thanks for rolling this back. It seems odd that you'd push this out without > > notice when you know it will break apps. Or was there notice somewhere? > > > Can you deploy your new code to a test endpoint so people (myself included) > > can test that their new code complies with your new requirements? > > > Cheers, > > > Tim. > > > On Fri, Dec 3, 2010 at 7:59 AM, 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 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 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 > > 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. > > >
[twitter-dev] Re: oAuth still working for everyone.?
Yep - oauth_verifier broke it here. Previously, if one was using the callback flow you had to make the verifier blank in order for it to work. Patched my custom Obj-C OAuth flow to put it back in place. - B. On Dec 2, 7:19 pm, kprobe wrote: > I am using TwitterEPI library. Mine was out of date. Uploaded the > newest version and my app now works. > Mark > > On Dec 2, 7:06 pm, Tim Haines wrote: > > > > > Hey Taylor, > > > Thanks for rolling this back. It seems odd that you'd push this out without > > notice when you know it will break apps. Or was there notice somewhere? > > > Can you deploy your new code to a test endpoint so people (myself included) > > can test that their new code complies with your new requirements? > > > Cheers, > > > Tim. > > > On Fri, Dec 3, 2010 at 7:59 AM, 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 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 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 > > 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
[twitter-dev] Re: oAuth still working for everyone.?
I am using TwitterEPI library. Mine was out of date. Uploaded the newest version and my app now works. Mark On Dec 2, 7:06 pm, Tim Haines wrote: > Hey Taylor, > > Thanks for rolling this back. It seems odd that you'd push this out without > notice when you know it will break apps. Or was there notice somewhere? > > Can you deploy your new code to a test endpoint so people (myself included) > can test that their new code complies with your new requirements? > > Cheers, > > Tim. > > On Fri, Dec 3, 2010 at 7:59 AM, 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 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 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 > 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 > >wrote: > > I'm seeing a lot of invalid/expired token errors. > > On Dec 2, 9:21 pm, Dave-twiends 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 sti
Re: [twitter-dev] Re: oAuth still working for everyone.?
Hey Taylor, Thanks for rolling this back. It seems odd that you'd push this out without notice when you know it will break apps. Or was there notice somewhere? Can you deploy your new code to a test endpoint so people (myself included) can test that their new code complies with your new requirements? Cheers, Tim. On Fri, Dec 3, 2010 at 7:59 AM, 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 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 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 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 >wrote: > I'm seeing a lot of invalid/expired token errors. >> > On Dec 2, 9:21 pm, Dave-twiends 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
[twitter-dev] Re: oAuth still working for everyone.?
The open source library I was using omitted oauth_verifier, which apparently was not required for oauth to work previously. Thanks to Dave & Taylor for pointing this out. Lee On Dec 2, 6:09 pm, Dave-twiends wrote: > 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 > 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 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 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 > > >>> 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 > >wrote: > > > >>> I'm seeing a lot of invalid/expired token errors. > > > >>> On Dec 2, 9:21 pm, Dave-twiends 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.. > > > >>>
[twitter-dev] Re: oAuth still working for everyone.?
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 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 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 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 > >>> 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 >wrote: > > >>> I'm seeing a lot of invalid/expired token errors. > > >>> On Dec 2, 9:21 pm, Dave-twiends 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/twi
[twitter-dev] Re: oAuth still working for everyone.?
That may be so but a little warning would have been nice. Obviously you knew people were using the wrong practice in mass scale. Educating people that they were doing so before you made the change would have been nice. -- 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
Re: [twitter-dev] Re: oAuth still working for everyone.?
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 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 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 >>> 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>>> >wrote: >>> >>> I'm seeing a lot of invalid/expired token errors. > >>> On Dec 2, 9:21 pm, Dave-twiends 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-ta
Re: [twitter-dev] Re: oAuth still working for everyone.?
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 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 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, Twitlongerwrote: I'm seeing a lot of invalid/expired token errors. On Dec 2, 9:21 pm, Dave-twiends 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-dev] Re: oAuth still working for everyone.?
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 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 > 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 > > wrote: > > > > I'm seeing a lot of invalid/expired token errors. > > > > On Dec 2, 9:21 pm, Dave-twiends 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-dev] Re: oAuth still working for everyone.?
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 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 wrote: > > > > > > > > > I'm seeing a lot of invalid/expired token errors. > > > On Dec 2, 9:21 pm, Dave-twiends 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
Re: [twitter-dev] Re: oAuth still working for everyone.?
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 wrote: > I'm seeing a lot of invalid/expired token errors. > > On Dec 2, 9:21 pm, Dave-twiends 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-dev] Re: oAuth still working for everyone.?
I'm seeing a lot of invalid/expired token errors. On Dec 2, 9:21 pm, Dave-twiends 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
