[twitter-dev] Re: oauth_callback
Hi Tim, I'm pretty sure the oauth_verifier is documented in their oAuth articles.. I'm speeking from memory here, but I'm sure I saw last week when we were investigating our own oAuth issues.. But, nonetheless, you are correct, oauth_verifier should be passed back every time. Dave Twiends On Dec 8, 2:27 am, Tim Bull wrote: > There is a required OAuth parameter step which is unclearly documented > by Twitter. When Twitter returns from your /oauth/authorize It returns > an oauth_verifier token. Make sure that you pass this oauth_verifier > token (along with the other parameters) along to > your /oauth/access_token call. > > Make sure you are passing this oauth_verifier in and see how you go. > I've found that if you DON'T set a callback, it doesn't enforce the > verifier, but if you do, then the verifier is essential (just be aware > Twitter are planning to change to always require this in the future, so > it's more compliant with the spec; worth making this change regardless, > a lot of Twitter libraries don't implement it). > > Hope this helps... > > Tim -- 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 p
[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 > >>
[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
[twitter-dev] oAuth still working for everyone.?
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-dev] Hat’s off to you and your colleagues
To the twitter team, I just wanted to drop you guys a quick note to say, great job..! I follow these groups and it seems that you guys don’t get enough thank you’s, so thank you..! I’ve been using the API for over a year now and I can’t tell you how impressed I am with it. You’ve steadily improved the reliability and uptime of it, while still adding new functionality. And I know you have to do this for a system that must have to scale well over 100bn records now. I’ve recently been doing some integration work with another large social networking site, and I can tell you it’s a nightmare. That made me realized that I’ve been taking for granted what you guys have achieved with this api. Well done guys Hat’s off to you and your colleagues. Dave Twiends -- 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: Certificate Twitter Apps
I totally agree. It would be difficult for twitter to do this... Give your users confidence by proactively anticipating their fears and addressing them. Figure out what would stop them from signing in with OAuth and answer those questions upfron. The favstar.fm example is very good as it demonstrates this process, and shows specific answers to specific fears. Perhaps also show some "social proof". tell them how many other user are successfully using your app. Have you got 100,000 users..? Well if you do then tell them that 100,000 users are using your app safely already, and have all signed in with OAuth. 100,000 is just an example.. Address the topic in your support forums with specific articles, questions and answers too. And finally, honor their confidence. If you say you'll never tweet to their account, NEVER tweet to their account. If you betray this unspoken trust then all will be lost.. If you can get this right then you'll really see your conversions climb..! Good luck Dave On Oct 26, 4:53 pm, Nik Fletcher wrote: > I'm not sure what sort of "Verification" you're looking for - however, > you might want to take steps on your own end to reassure users why > they're being sent to Twitter. See, for example, Favstar. > > http://favstar.fm/authorization/new > > It's the your job as an application developer to instil confidence in > the user to feel happy entering their credentials. > > -N > > On Oct 24, 12:56 am, loretoparisi wrote: > > > > > Hi, > > I'm cto for stickphone.me and lyricsmood.me, oauth based twitter apps. > > > Many users told us that they just don't use our oauth sign in service, > > since it seems to them to be unsafe with this kind of sign in (single > > sign-on from oauth client site) > > > This is not a design problem I guess, but a people misunderstanding > > problem, about the authorization protocol (going away from people like > > developers, engineers, etc, who really knows what oAuth is about?), > > even if we tried to explain this process as well in our sites tos. > > > I was wondering if you @twitter have any idea in the future to > > certificate an app in order this app to be "verified" by twitter (in > > the same way some accounts are). > > > In this ways app users would not be scared when clickin on "Sign in to > > Twitter" buttons. > > > Of course using Twitter's button styles would be a better experience > > for the user in order to trust the thirdy-party service, but this is > > not possibile in all cases. > > > Thanks, > > Loreto Parisi > > CTO at stickphone, lyricsmood > > lor...@stickphone.me > > lor...@lyricsmood.me -- 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: WHAT THE HELL ARE YOU THINKING
As I fellow developer I'll say I fully support the drive to OAuth. It's a lot more secure and although it might mean that you actually have to write a few lines of code it will help stamp out a lot issues with straight usernames and passwords.. OAuth took me total of about 2 hours to implement, what's the big deal...? Good luck Keiya, can I recommend the following book "How to win friends and influence people".. It's a good read... On Oct 25, 8:28 pm, Keiya Bachhuber wrote: > Is the next version of twitter going to be written in C++ and use GTK+ > for rendering? Because that's what you're asking desktop developers to > do by forcing OAuth. I have to include a web server in my app to work > with twitter? What the hell! It's probably simpler just to pretend to > be Chrome or Firefox. Seriously. Working through the mess that is HTML > (any HTML, not just yours) is easier than getting the nice clean > feeds. > > Good job. You made me hate you. > Keiya. -- 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: Provide a spam score (or rather a “good citizen” flag)
I think one solution is if twitter could use their hidden karma score to provide "good citizen" flag for us. So, they shouldn't provide any kind of score to the outside world via the web or API, but they could use it to provide an "indicator" for a clean account. In other words, we would assume all accounts to be potential spammers until we see the "good citizen" flag on the account, then we can be a little more trusting of that account. Not completely trusting, but just use it as an indicator.. On Oct 17, 6:43 am, "M. Edward (Ed) Borasky" wrote: > I don't know about a "karma" score, but Twitalyzer does have an API > and so does Klout. For that matter, Viralheat has an API and they can > get both Twitalyzer and Klout scores. > > That said, I don't know that there's ever really going to be a "one > size fits all" Twitter user metric. But there are quite a few > "crowdsourcing" and "curation" tools starting to show up, some of them > open source. But personally, I think it's more fun to just collect raw > data via the API and roll your own. ;-) > -- > M. Edward (Ed) Boraskyhttp://borasky-research.nethttp://twitter.com/znmeb > > "A mathematician is a device for turning coffee into theorems." - Paul Erdos > > Quoting Justin : > > > > > Rating/scoring users is something I'm working on as well and I agree. > > I've found sorting out bots and pure spammers to be very difficult. > > Some folks tweet so much they resemble bots/spam. > > > Feels like a pipe dream but if they can I'd love a karma scoring > > system directly from the API. > > > On Oct 16, 4:28 am, Dave-twiends wrote: > >> I really like the option of reporting spam via the api. I’ve been > >> blocking spam on my site for a long time but this gives me an option > >> to report it now, and hopefully get these account suspended quicker so > >> that they don’t come back. > > >> It would be really great if we could have a proactive api function as > >> well, where we could get the likelihood of a user being a spammer. I > >> know this is really difficult to do, and wrought with pitfalls, but > >> perhaps it could be structured in some way? Maybe you could provide a > >> “good citizen” flag for a user (i.e a user that hasn’t had any > >> complaints, and has a certain account age). That way you don’t > >> negatively impact any users, but we can then at least treat these > >> users differently when they sign up with our site. > > >> I’m seeing more and more the need to provide different limits to users > >> based on private trust/karma score we develop for each user. This > >> would be a very valuable input for us to detect potential problem > >> users before they can cause damage. > > >> Thanks > >> Dave > > > -- > > 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] Follow-back should always be private
I’m looking to implement this feature on my site as I can really see the value in it. But as you have pointed out I can also see the danger in it. If spammers knew who had follow-back turned on they would seek out these users and follow them, knowing they would get followed back. They could then potentially do this at a very accelerated rate, not hitting follow limits. I think the only way this feature can be kept safe is if it is completely private. Users can turn it on but neither they nor the application should tell other others that its enabled. There should be no way for spammers to figure this out either. I’m not sure if this has been spelled out in the twitter rules but if it hasn’t it probably should. Users mustn’t be allowed to put it in their bio, etc. as this could be easily be parsed by a crawler.. Would be interested to hear how others are keeping this feature “safe”..? Thanks Dave -- 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] Provide a spam score (or rather a “g ood citizen” flag)
I really like the option of reporting spam via the api. I’ve been blocking spam on my site for a long time but this gives me an option to report it now, and hopefully get these account suspended quicker so that they don’t come back. It would be really great if we could have a proactive api function as well, where we could get the likelihood of a user being a spammer. I know this is really difficult to do, and wrought with pitfalls, but perhaps it could be structured in some way? Maybe you could provide a “good citizen” flag for a user (i.e a user that hasn’t had any complaints, and has a certain account age). That way you don’t negatively impact any users, but we can then at least treat these users differently when they sign up with our site. I’m seeing more and more the need to provide different limits to users based on private trust/karma score we develop for each user. This would be a very valuable input for us to detect potential problem users before they can cause damage. Thanks Dave -- 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
