[twitter-dev] Re: How do I find all replies to a status?
Jason, It is authenticated because the statuses/mentions timeline potentially includes protected updates. Making it unauthenticated is therefore not an option. Thanks, Doug Williams Twitter API Support http://twitter.com/dougw On Wed, Apr 22, 2009 at 1:02 PM, Doug Williams d...@twitter.com wrote: Jason, statuses/mentions would contain this data, and it is available via search. Let me bring this up with Alex, because you make a good point. Doug Williams Twitter API Support http://twitter.com/dougw On Wed, Apr 22, 2009 at 11:57 AM, Jason Wong ja...@kratedesign.comwrote: As I see it, replies also contain @screen_name in them. There's already an API structure to find these items, via statuses/mentions. Is there a reason why it's restricted to only the authenticating user and not open to access a screen_name / user_id parameter? I can easily implement this if I keep everyone's authentication tokens and doing statuses/mentions and checking the in_reply_to_status_id. But it's not efficient and will have way too many hits against the twitter server. What do you guys think? Jason. Doug Williams wrote: It requires a non trivial change to our architecture which means that until the product at large (twitter.com) adopts the idea of conversation threads, the API will be unable to offer this feature. Doug Williams Twitter API Support http://twitter.com/dougw On Wed, Apr 22, 2009 at 11:01 AM, Zac Bowling zbowl...@gmail.com wrote: I see the bug was closed as WONTFIX. Would it not be possible for search to get a param for in_reply_to_status_id? I'm not working on any twitter projects anymore but it could lead to some very interesting clients. Zac On Wed, Apr 22, 2009 at 10:11 AM, Doug Williams d...@twitter.com wrote: Please see http://code.google.com/p/twitter-api/issues/detail?id=142 Doug Williams Twitter API Support http://twitter.com/dougw On Wed, Apr 22, 2009 at 10:04 AM, Jason Wong ja...@kratedesign.com wrote: I'm trying to find a way to get all replies to a certain status. I was looking at the statuses/mentions function, but according to the documentation it only works with the authenticated user's screen_name. If I use statuses/user_timeline and get a status id that I know has replies, is there a way for me to get it without searching the public_timeline and checking the in_reply_to_status_id field for that status? It doesn't seem very efficient. Thanks, Jason.
[twitter-dev] Re: How do I find all replies to a status?
Protected updates really complicate the API. I really wish that twitter could phase that feature out to make things easier all around, but I'm sure the privacy worry warts would have a hissy fit. Zac Bowling On Wed, Apr 22, 2009 at 11:03 PM, Doug Williams d...@twitter.com wrote: Jason, It is authenticated because the statuses/mentions timeline potentially includes protected updates. Making it unauthenticated is therefore not an option. Thanks, Doug Williams Twitter API Support http://twitter.com/dougw On Wed, Apr 22, 2009 at 1:02 PM, Doug Williams d...@twitter.com wrote: Jason, statuses/mentions would contain this data, and it is available via search. Let me bring this up with Alex, because you make a good point. Doug Williams Twitter API Support http://twitter.com/dougw On Wed, Apr 22, 2009 at 11:57 AM, Jason Wong ja...@kratedesign.com wrote: As I see it, replies also contain @screen_name in them. There's already an API structure to find these items, via statuses/mentions. Is there a reason why it's restricted to only the authenticating user and not open to access a screen_name / user_id parameter? I can easily implement this if I keep everyone's authentication tokens and doing statuses/mentions and checking the in_reply_to_status_id. But it's not efficient and will have way too many hits against the twitter server. What do you guys think? Jason. Doug Williams wrote: It requires a non trivial change to our architecture which means that until the product at large (twitter.com) adopts the idea of conversation threads, the API will be unable to offer this feature. Doug Williams Twitter API Support http://twitter.com/dougw On Wed, Apr 22, 2009 at 11:01 AM, Zac Bowling zbowl...@gmail.com wrote: I see the bug was closed as WONTFIX. Would it not be possible for search to get a param for in_reply_to_status_id? I'm not working on any twitter projects anymore but it could lead to some very interesting clients. Zac On Wed, Apr 22, 2009 at 10:11 AM, Doug Williams d...@twitter.com wrote: Please see http://code.google.com/p/twitter-api/issues/detail?id=142 Doug Williams Twitter API Support http://twitter.com/dougw On Wed, Apr 22, 2009 at 10:04 AM, Jason Wong ja...@kratedesign.com wrote: I'm trying to find a way to get all replies to a certain status. I was looking at the statuses/mentions function, but according to the documentation it only works with the authenticated user's screen_name. If I use statuses/user_timeline and get a status id that I know has replies, is there a way for me to get it without searching the public_timeline and checking the in_reply_to_status_id field for that status? It doesn't seem very efficient. Thanks, Jason.
[twitter-dev] 2nd Event for Twitter Developers
Hi Everyone, Next Thursday 30th April will see the second Twitter Developer Nest, an event bringing loads of us together in the real world to discuss our challenges and celebrate our achievements. The event, taking place at Sun Microsystems London HQ, starts at 6pm BST with sessions starting from 7pm BST including: - Zolty (@aszolty), Poke London - http://BakerTweet.com - Ollie Parsley (@ollieparsley), Freelance - http://FootyTweets.com - Doug Williams (@dougw), Twitter Inc. - Twitter API QA (via video link from Twitter HQ) - Paul Johnston (@PaulDJohnston), Vida - Transient v. Persistent Data on Twitter - Show Tweet - 8 x 140 second demos reserved on the night Food and beer will be provided by our sponsor - Sun Startup Essentials Tickets are available here: http://twitterdevelopernest.eventbrite.com/ If you can't make it to London please tune in to our UStream cast. We'll provide a link on our blog (http://twitterdevelopernest.com) and via http://twitter.com/devnest on the night. We're working to try and avoid the sound quality problems people experienced last time around. Hope to see many of you there again, bringing some exciting projects and a few though questions for Doug ;) Jon. http://twitter.com/devnest / http://twitter.com/JonMarkwell -- Jonathan Markwell Engineer | Founder | Connector Inuda Innovations Ltd, Brighton, UK Web application development support Twitter Facebook integration specialists http://inuda.com Organising the world's first events for the Twitter developer community http://TwitterDeveloperNest.com Providing a nice little place to work in the heart of Brighton - http://theskiff.org Measuring your brand's visibility on the social web - http://HowSociable.com mob: 07766 021 485 | tel: 01273 704 549 | fax: 01273 376 953 skype: jlmarkwell | twitter: http://twitter.com/JonMarkwell
[twitter-dev] OAuth API
When is authentication going to be restored? Also, after reading The Consumer will need this new extra parameter to exchange the Request Token for an Access Token, ensuring that the real user has to return to the application to complete the flow. what details can you provide about how Twitter is going to implement that? Instead of waiting around for you guys to patch it, the rest of us could be getting ready for when you turn it back on. Thanks in advance for your response.
[twitter-dev] Re: Freelance Twitter API Dev directory?
Hello, I'd like to be added to this list please. Real Name: Rob Banagale Twitter Username: @neutrinosllc email: r...@neutrinosllc.com Social media consulting, development and design specializing in Ruby on Rails. Our strength is in creating integrations between services, including Facebook and iPhone applciations. We have five applications in iTunes and can help you achieve your vision for a Twitter application. Thank you. Rob
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
Hi guys, is there an ETA for it to be restored ? It seems Oauth's recommended approach is to simply add a warning notice on authorization until this is fixed (this is what Google did). Anyways, even with this security flow, oauth is safer than providing twitter credentials to third parties... Thanks! Pierre On Apr 23, 7:30 am, Doug Williams d...@twitter.com wrote: Bill, The majority of our developers find OAuth sufficient because they are writing a Web applications. We are pleased that the deprecation of the source parameter lowered our support load and continues to drive adoption of our preferred authentication scheme. There are of course other cases where developers find the current implementation's beta status or browser requirement concerning. I have yet to reject a source parameter request that provides a valid argument explaining why OAuth does not meet the application's needs. Thanks, Doug Williams Twitter API Supporthttp://twitter.com/dougw On Wed, Apr 22, 2009 at 6:50 PM, Bill Robertson billrobertso...@gmail.comwrote: I respectfully disagree. (I would colorfully disagree, but you seem pretty beat up right now and you don't deserve any guff) I think developers of smaller apps see that little tag-line as a good source of advertising, and it seems inaccessible now if you're new (right? wrong?). You can only get it if you use OAuth, but OAuth is now disabled? Anyway, just my $0.02. Prioritize it like everything else you need to do (i.e. it's the 37th #1 thing on your list.) Good luck. On Apr 22, 7:58 pm, Alex Payne a...@twitter.com wrote: We don't consider source registration a key feature. It's an incentive we provide to our developers. We wanted to encourage new developers to look into OAuth. It won't be in beta forever, after all. We have to balance the reality of testing a new technology in our stack with encouraging that technology's adoption. OAuth will provide the Twitter developer community with a number of benefits, and that's the direction in which we want to move, even while there are kinks to work out. On Wed, Apr 22, 2009 at 15:37, bwannon bwan...@gmail.com wrote: If beta for you guys means still in testing, not suitable for production use, then why depreciate key features from basic auth like source registration before you have a production ready release? On Apr 22, 3:27 pm, Alex Payne a...@twitter.com wrote: http://blog.twitter.com/2009/04/whats-deal-with-oauth.html In short: there's a security issue with OAuth, and the major OAuth providers are working together to patch the vulnerability before information about the issue is publicly released. That information will be available athttp://oauth.net/atmidnight, PST. In cooperation with this consortium of other OAuth providers (including Yahoo!, Google, Netflix, etc.), we agreed not to disclose the nature of the vulnerability, nor even that a vulnerability existed, until all members of the group agreed to do so. I apologize for what must have seemed unnecessarily tight-lipped communication around this issue, but please understand that we and the other companies involved are trying to mitigate the impact of this vulnerability as much as possible. Please also note that our OAuth support is in beta, albeit public beta. We have not suggested to developers that they rely solely on OAuth until our support of the standard leaves beta. I know that some companies practice a policy of perpetual beta, but at Twitter, we do not. For us, beta really means still in testing, not suitable for production use. Thanks for your patience and understanding. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x- Hide quoted text - - Show quoted text -
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
Here is the official OAuth statement: http://oauth.net/advisories/2009-1 On Thu, Apr 23, 2009 at 03:44, twitscoop lollic...@gmail.com wrote: Hi guys, is there an ETA for it to be restored ? It seems Oauth's recommended approach is to simply add a warning notice on authorization until this is fixed (this is what Google did). Anyways, even with this security flow, oauth is safer than providing twitter credentials to third parties... Thanks! Pierre On Apr 23, 7:30 am, Doug Williams d...@twitter.com wrote: Bill, The majority of our developers find OAuth sufficient because they are writing a Web applications. We are pleased that the deprecation of the source parameter lowered our support load and continues to drive adoption of our preferred authentication scheme. There are of course other cases where developers find the current implementation's beta status or browser requirement concerning. I have yet to reject a source parameter request that provides a valid argument explaining why OAuth does not meet the application's needs. Thanks, Doug Williams Twitter API Supporthttp://twitter.com/dougw On Wed, Apr 22, 2009 at 6:50 PM, Bill Robertson billrobertso...@gmail.comwrote: I respectfully disagree. (I would colorfully disagree, but you seem pretty beat up right now and you don't deserve any guff) I think developers of smaller apps see that little tag-line as a good source of advertising, and it seems inaccessible now if you're new (right? wrong?). You can only get it if you use OAuth, but OAuth is now disabled? Anyway, just my $0.02. Prioritize it like everything else you need to do (i.e. it's the 37th #1 thing on your list.) Good luck. On Apr 22, 7:58 pm, Alex Payne a...@twitter.com wrote: We don't consider source registration a key feature. It's an incentive we provide to our developers. We wanted to encourage new developers to look into OAuth. It won't be in beta forever, after all. We have to balance the reality of testing a new technology in our stack with encouraging that technology's adoption. OAuth will provide the Twitter developer community with a number of benefits, and that's the direction in which we want to move, even while there are kinks to work out. On Wed, Apr 22, 2009 at 15:37, bwannon bwan...@gmail.com wrote: If beta for you guys means still in testing, not suitable for production use, then why depreciate key features from basic auth like source registration before you have a production ready release? On Apr 22, 3:27 pm, Alex Payne a...@twitter.com wrote: http://blog.twitter.com/2009/04/whats-deal-with-oauth.html In short: there's a security issue with OAuth, and the major OAuth providers are working together to patch the vulnerability before information about the issue is publicly released. That information will be available athttp://oauth.net/atmidnight, PST. In cooperation with this consortium of other OAuth providers (including Yahoo!, Google, Netflix, etc.), we agreed not to disclose the nature of the vulnerability, nor even that a vulnerability existed, until all members of the group agreed to do so. I apologize for what must have seemed unnecessarily tight-lipped communication around this issue, but please understand that we and the other companies involved are trying to mitigate the impact of this vulnerability as much as possible. Please also note that our OAuth support is in beta, albeit public beta. We have not suggested to developers that they rely solely on OAuth until our support of the standard leaves beta. I know that some companies practice a policy of perpetual beta, but at Twitter, we do not. For us, beta really means still in testing, not suitable for production use. Thanks for your patience and understanding. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x- Hide quoted text - - Show quoted text - -- Abraham Williams | http://the.hackerconundrum.com Hacker | http://abrah.am | http://twitter.com/abraham Web608 | Community Evangelist | http://web608.org This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: authenticating
i am using twitter4j now. it works perfectly
On Apr 20, 2:16 am, ytbryan ytbr...@gmail.com wrote:
Hello everyone..
I am using commons httpclient to authenticate twitter through REST.
however, i haven't successfully authenticate using the below code: can
someone advise me what to fill in under AuthScope? and is my
GetMethod parameter correct?
HttpClient client = new HttpClient();
client.getState().setCredentials(
new AuthScope(www.twitter.com, 443, null),
new UsernamePasswordCredentials(userid, password)
);
GetMethod get = new GetMethod(https://www.twitter.com;);
get.setDoAuthentication( true );
try {
int status = client.executeMethod( get );
System.out.println(status + \n +
get.getResponseBodyAsString());
} catch (HttpException e1) {
e1.printStackTrace();
} catch (IOException e1) {
e1.printStackTrace();
} finally {
get.releaseConnection();
}
thanks and regards
Bryan
[twitter-dev] weird things on twitter
hi all, i notice that a few people appeared under my friends pages. when i click in to investigate further, i realised that i am not following them. did anybody notice this ?
[twitter-dev] Re: How do I find all replies to a status?
On Wed, Apr 22, 2009 at 2:10 PM, Doug Williams d...@twitter.com wrote: It requires a non trivial change to our architecture which means that until the product at large (twitter.com) adopts the idea of conversation threads, the API will be unable to offer this feature. I call slight shenanigans here, as search.twitter.com provides a Show Conversation option in the results page. I know this is an artifact of the Summize site, but there is a part of the twitter.com umbrella that recognizes conversation threads. -Chad
[twitter-dev] How can I retrieve follower information
Hi I need to retrieve the entire ids of followers of a particular user, it works for me fine, in the case of small number of follwers. when its is a huge one its not working coming say Twitter is over capacity. Too many tweets! Please wait a moment and try again. http://twitter.com/followers/ids.xml?user_id=6449282 in this case there are 40 followes. How can we get all these Id's thanks j0ban http://phpqa.blogspot.com
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
Totally agree with Pierre. I think we all understand the security issue. Why was twitter's approach so much more severe than other services? Why not just a warning on login? Can Doug or Alex shed some light on this? wrt the ETA, can we get an update? One blog post said yesterday, the posting on this site says today. Also, I'm a little taken aback by the it's beta rationalization for the massive disruption in service. It's one thing to mark it as public beta, it's another thing entirely to define 'beta' belatedly as not suitable for production use. Does that mean we get an SLA on the non- beta APIs? On Apr 23, 1:44 am, twitscoop lollic...@gmail.com wrote: Hi guys, is there an ETA for it to be restored ? It seems Oauth's recommended approach is to simply add a warning notice on authorization until this is fixed (this is what Google did). Anyways, even with this security flow, oauth is safer than providing twitter credentials to third parties... Thanks! Pierre On Apr 23, 7:30 am, Doug Williams d...@twitter.com wrote: Bill, The majority of our developers find OAuth sufficient because they are writing a Web applications. We are pleased that the deprecation of the source parameter lowered our support load and continues to drive adoption of our preferred authentication scheme. There are of course other cases where developers find the current implementation's beta status or browser requirement concerning. I have yet to reject a source parameter request that provides a valid argument explaining why OAuth does not meet the application's needs. Thanks, Doug Williams Twitter API Supporthttp://twitter.com/dougw On Wed, Apr 22, 2009 at 6:50 PM, Bill Robertson billrobertso...@gmail.comwrote: I respectfully disagree. (I would colorfully disagree, but you seem pretty beat up right now and you don't deserve any guff) I think developers of smaller apps see that little tag-line as a good source of advertising, and it seems inaccessible now if you're new (right? wrong?). You can only get it if you use OAuth, but OAuth is now disabled? Anyway, just my $0.02. Prioritize it like everything else you need to do (i.e. it's the 37th #1 thing on your list.) Good luck. On Apr 22, 7:58 pm, Alex Payne a...@twitter.com wrote: We don't consider source registration a key feature. It's an incentive we provide to our developers. We wanted to encourage new developers to look into OAuth. It won't be in beta forever, after all. We have to balance the reality of testing a new technology in our stack with encouraging that technology's adoption. OAuth will provide the Twitter developer community with a number of benefits, and that's the direction in which we want to move, even while there are kinks to work out. On Wed, Apr 22, 2009 at 15:37, bwannon bwan...@gmail.com wrote: If beta for you guys means still in testing, not suitable for production use, then why depreciate key features from basic auth like source registration before you have a production ready release? On Apr 22, 3:27 pm, Alex Payne a...@twitter.com wrote: http://blog.twitter.com/2009/04/whats-deal-with-oauth.html In short: there's a security issue with OAuth, and the major OAuth providers are working together to patch the vulnerability before information about the issue is publicly released. That information will be available athttp://oauth.net/atmidnight, PST. In cooperation with this consortium of other OAuth providers (including Yahoo!, Google, Netflix, etc.), we agreed not to disclose the nature of the vulnerability, nor even that a vulnerability existed, until all members of the group agreed to do so. I apologize for what must have seemed unnecessarily tight-lipped communication around this issue, but please understand that we and the other companies involved are trying to mitigate the impact of this vulnerability as much as possible. Please also note that our OAuth support is in beta, albeit public beta. We have not suggested to developers that they rely solely on OAuth until our support of the standard leaves beta. I know that some companies practice a policy of perpetual beta, but at Twitter, we do not. For us, beta really means still in testing, not suitable for production use. Thanks for your patience and understanding. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x-Hide quoted text - - Show quoted text -
[twitter-dev] Get Twitter users list(by screenname)
Hi, I am new to this group(Twitter API). we have a requiremnt like ... we need to get the Twitter users list (to follow). After getting the list,user can select the user from the list and follow the twitter user. we are able to get the twitter users who are followed and whom i am following.But i am unable to get the twitter users list to follow. How can we get the twitter users list?. Any help can be appriciated. Regards kkp
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
That is, in fact, what Beta typically means: not suitable for production use. Overuse of the term by a few popular web apps notwithstanding. -- Ed Finkler http://funkatron.com Twitter:@funkatron AIM: funka7ron ICQ: 3922133 XMPP:funkat...@gmail.com On Apr 23, 9:25 am, mikehar m...@picnik.com wrote: Also, I'm a little taken aback by the it's beta rationalization for the massive disruption in service. It's one thing to mark it as public beta, it's another thing entirely to define 'beta' belatedly as not suitable for production use. Does that mean we get an SLA on the non- beta APIs? On Apr 23, 1:44 am, twitscoop lollic...@gmail.com wrote: Hi guys, is there an ETA for it to be restored ? It seems Oauth's recommended approach is to simply add a warning notice on authorization until this is fixed (this is what Google did). Anyways, even with this security flow, oauth is safer than providing twitter credentials to third parties... Thanks! Pierre On Apr 23, 7:30 am, Doug Williams d...@twitter.com wrote: Bill, The majority of our developers find OAuth sufficient because they are writing a Web applications. We are pleased that the deprecation of the source parameter lowered our support load and continues to drive adoption of our preferred authentication scheme. There are of course other cases where developers find the current implementation's beta status or browser requirement concerning. I have yet to reject a source parameter request that provides a valid argument explaining why OAuth does not meet the application's needs. Thanks, Doug Williams Twitter API Supporthttp://twitter.com/dougw On Wed, Apr 22, 2009 at 6:50 PM, Bill Robertson billrobertso...@gmail.comwrote: I respectfully disagree. (I would colorfully disagree, but you seem pretty beat up right now and you don't deserve any guff) I think developers of smaller apps see that little tag-line as a good source of advertising, and it seems inaccessible now if you're new (right? wrong?). You can only get it if you use OAuth, but OAuth is now disabled? Anyway, just my $0.02. Prioritize it like everything else you need to do (i.e. it's the 37th #1 thing on your list.) Good luck. On Apr 22, 7:58 pm, Alex Payne a...@twitter.com wrote: We don't consider source registration a key feature. It's an incentive we provide to our developers. We wanted to encourage new developers to look into OAuth. It won't be in beta forever, after all. We have to balance the reality of testing a new technology in our stack with encouraging that technology's adoption. OAuth will provide the Twitter developer community with a number of benefits, and that's the direction in which we want to move, even while there are kinks to work out. On Wed, Apr 22, 2009 at 15:37, bwannon bwan...@gmail.com wrote: If beta for you guys means still in testing, not suitable for production use, then why depreciate key features from basic auth like source registration before you have a production ready release? On Apr 22, 3:27 pm, Alex Payne a...@twitter.com wrote: http://blog.twitter.com/2009/04/whats-deal-with-oauth.html In short: there's a security issue with OAuth, and the major OAuth providers are working together to patch the vulnerability before information about the issue is publicly released. That information will be available athttp://oauth.net/atmidnight, PST. In cooperation with this consortium of other OAuth providers (including Yahoo!, Google, Netflix, etc.), we agreed not to disclose the nature of the vulnerability, nor even that a vulnerability existed, until all members of the group agreed to do so. I apologize for what must have seemed unnecessarily tight-lipped communication around this issue, but please understand that we and the other companies involved are trying to mitigate the impact of this vulnerability as much as possible. Please also note that our OAuth support is in beta, albeit public beta. We have not suggested to developers that they rely solely on OAuth until our support of the standard leaves beta. I know that some companies practice a policy of perpetual beta, but at Twitter, we do not. For us, beta really means still in testing, not suitable for production use. Thanks for your patience and understanding. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x-Hidequoted text - - Show quoted text -
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
Corrected: Overuse of the term by almost every web app since 2002, including GMail, notwithstanding. On Thu, Apr 23, 2009 at 10:01 AM, Ed Finkler funkat...@gmail.com wrote: That is, in fact, what Beta typically means: not suitable for production use. Overuse of the term by a few popular web apps notwithstanding. -- Ed Finkler http://funkatron.com Twitter:@funkatron AIM: funka7ron ICQ: 3922133 XMPP:funkat...@gmail.com xmpp%3afunkat...@gmail.com On Apr 23, 9:25 am, mikehar m...@picnik.com wrote: Also, I'm a little taken aback by the it's beta rationalization for the massive disruption in service. It's one thing to mark it as public beta, it's another thing entirely to define 'beta' belatedly as not suitable for production use. Does that mean we get an SLA on the non- beta APIs? On Apr 23, 1:44 am, twitscoop lollic...@gmail.com wrote: Hi guys, is there an ETA for it to be restored ? It seems Oauth's recommended approach is to simply add a warning notice on authorization until this is fixed (this is what Google did). Anyways, even with this security flow, oauth is safer than providing twitter credentials to third parties... Thanks! Pierre On Apr 23, 7:30 am, Doug Williams d...@twitter.com wrote: Bill, The majority of our developers find OAuth sufficient because they are writing a Web applications. We are pleased that the deprecation of the source parameter lowered our support load and continues to drive adoption of our preferred authentication scheme. There are of course other cases where developers find the current implementation's beta status or browser requirement concerning. I have yet to reject a source parameter request that provides a valid argument explaining why OAuth does not meet the application's needs. Thanks, Doug Williams Twitter API Supporthttp://twitter.com/dougw On Wed, Apr 22, 2009 at 6:50 PM, Bill Robertson billrobertso...@gmail.comwrote: I respectfully disagree. (I would colorfully disagree, but you seem pretty beat up right now and you don't deserve any guff) I think developers of smaller apps see that little tag-line as a good source of advertising, and it seems inaccessible now if you're new (right? wrong?). You can only get it if you use OAuth, but OAuth is now disabled? Anyway, just my $0.02. Prioritize it like everything else you need to do (i.e. it's the 37th #1 thing on your list.) Good luck. On Apr 22, 7:58 pm, Alex Payne a...@twitter.com wrote: We don't consider source registration a key feature. It's an incentive we provide to our developers. We wanted to encourage new developers to look into OAuth. It won't be in beta forever, after all. We have to balance the reality of testing a new technology in our stack with encouraging that technology's adoption. OAuth will provide the Twitter developer community with a number of benefits, and that's the direction in which we want to move, even while there are kinks to work out. On Wed, Apr 22, 2009 at 15:37, bwannon bwan...@gmail.com wrote: If beta for you guys means still in testing, not suitable for production use, then why depreciate key features from basic auth like source registration before you have a production ready release? On Apr 22, 3:27 pm, Alex Payne a...@twitter.com wrote: http://blog.twitter.com/2009/04/whats-deal-with-oauth.html In short: there's a security issue with OAuth, and the major OAuth providers are working together to patch the vulnerability before information about the issue is publicly released. That information will be available athttp://oauth.net/atmidnight, PST. In cooperation with this consortium of other OAuth providers (including Yahoo!, Google, Netflix, etc.), we agreed not to disclose the nature of the vulnerability, nor even that a vulnerability existed, until all members of the group agreed to do so. I apologize for what must have seemed unnecessarily tight-lipped communication around this issue, but please understand that we and the other companies involved are trying to mitigate the impact of this vulnerability as much as possible. Please also note that our OAuth support is in beta, albeit public beta. We have not suggested to developers that they rely solely on OAuth until our support of the standard leaves beta. I know that some companies practice a policy of perpetual beta, but at Twitter, we do not. For us, beta really means still in testing, not suitable for production use. Thanks for your patience and understanding. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc.
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
What does this really mean these days? Clearly your desktop app is connected to the internet in some way at some point, otherwise you wouldn't need Twitter. So are you just saying that you never want to have to display an HTML page? What about a web based activation stage that yielded some custom mime-type that securely downloaded the keys into your desktop app? On Apr 22, 9:40 pm, Julio Biason julio.bia...@gmail.com wrote: On Thu, Apr 23, 2009 at 10:23 AM, Chris Latko ch...@latko.org wrote: I'm going to have to side with Alex on this one. The APIs should be protected by OAuth and that is what should be pushed out and the basic auth deprecated. What I don't really understand is why it has taken until now to promote OAuth. I understand OAuth is an evolving standard, but it has been around for quite a while. Still waiting for a good explanation of how to use OAuth in a console-only, no-browser environment. Until then, I see that Basic Auth should remain active. -- Julio Biason julio.bia...@gmail.com Twitter:http://twitter.com/juliobiason
[twitter-dev] Re: How do I find all replies to a status?
Doug, Isn't it possible to restrict protected updates when calling a specific user? This functionality would be similar to the statuses/user_timeline. And maybe a parameter to filter out replies only, not just all mentions. This would be similar to the Search API using t...@screen_name in the query. Jason. Doug Williams wrote: Jason, It is authenticated because the statuses/mentions timeline potentially includes protected updates. Making it unauthenticated is therefore not an option. Thanks, Doug Williams Twitter API Support http://twitter.com/dougw On Wed, Apr 22, 2009 at 1:02 PM, Doug Williams d...@twitter.com mailto:d...@twitter.com wrote: Jason, statuses/mentions would contain this data, and it is available via search. Let me bring this up with Alex, because you make a good point. Doug Williams Twitter API Support http://twitter.com/dougw On Wed, Apr 22, 2009 at 11:57 AM, Jason Wong ja...@kratedesign.com mailto:ja...@kratedesign.com wrote: As I see it, replies also contain @screen_name in them. There's already an API structure to find these items, via statuses/mentions. Is there a reason why it's restricted to only the authenticating user and not open to access a screen_name / user_id parameter? I can easily implement this if I keep everyone's authentication tokens and doing statuses/mentions and checking the in_reply_to_status_id. But it's not efficient and will have way too many hits against the twitter server. What do you guys think? Jason. Doug Williams wrote: It requires a non trivial change to our architecture which means that until the product at large (twitter.com http://twitter.com) adopts the idea of conversation threads, the API will be unable to offer this feature. Doug Williams Twitter API Support http://twitter.com/dougw On Wed, Apr 22, 2009 at 11:01 AM, Zac Bowling zbowl...@gmail.com mailto:zbowl...@gmail.com wrote: I see the bug was closed as WONTFIX. Would it not be possible for search to get a param for in_reply_to_status_id? I'm not working on any twitter projects anymore but it could lead to some very interesting clients. Zac On Wed, Apr 22, 2009 at 10:11 AM, Doug Williams d...@twitter.com mailto:d...@twitter.com wrote: Please see http://code.google.com/p/twitter-api/issues/detail?id=142 Doug Williams Twitter API Support http://twitter.com/dougw On Wed, Apr 22, 2009 at 10:04 AM, Jason Wong ja...@kratedesign.com mailto:ja...@kratedesign.com wrote: I'm trying to find a way to get all replies to a certain status. I was looking at the statuses/mentions function, but according to the documentation it only works with the authenticated user's screen_name. If I use statuses/user_timeline and get a status id that I know has replies, is there a way for me to get it without searching the public_timeline and checking the in_reply_to_status_id field for that status? It doesn't seem very efficient. Thanks, Jason.
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
Corrected: Overuse of the term by almost every web app since 2002, including GMail, notwithstanding. s/GMail/*.google.com/ -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- The whippings shall continue until morale improves.
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
haha, agreed. On Thu, Apr 23, 2009 at 10:43 AM, Cameron Kaiser spec...@floodgap.comwrote: Corrected: Overuse of the term by almost every web app since 2002, including GMail, notwithstanding. s/GMail/*.google.com/ -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- The whippings shall continue until morale improves.
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
Hi all, We had to wait for the midnight deadline before giving too many details because we're taking a slightly more active approach. The code for these changes was scheduled to go out yesterday but there was a problem with some unrelated changes and the whole thing was rolled back. I'm hoping to get it out early today as an emergency deploy. If anyone has missed it, Eran posted a good explanation [1] for people not digging the security advisory wording. While I'm still working to get the changes out here is what you can expect: 1. The lifetime of a Request Token is now much, much shorter. This new time limit should be long enough for a person to complete the flow, but short enough that it cuts off attacks. » Note this is for request tokens, not access tokens. 2. For the time being the oauth_callback parameter will be disabled for both authentication and authorization. The user will be sent to the application callback in both cases. » I'm working with the other OAuth implementers on a way to bring it back, and Eran mentions it a bit at the end of his post [1]. We want to make sure it works correctly before launching it so you don't end up spending time to implement something we then have to turn off. As for questions about the severity of Twitter's initial response I think you'll find Yahoo! [2] has done the same. From the OAuth response mails I can assure you there were others as well but since they have no public mention of it I'll let them go unmolested. It wasn't just Twitter, that was just the only place you were looking :) Thanks; — Matt Sanford, of Alex and Doug fame [1] - http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-session-fixation-attack.html [2] - http://developer.yahoo.net/blog/archives/2009/04/oauth_update.html On Apr 23, 2009, at 06:25 AM, mikehar wrote: Totally agree with Pierre. I think we all understand the security issue. Why was twitter's approach so much more severe than other services? Why not just a warning on login? Can Doug or Alex shed some light on this? wrt the ETA, can we get an update? One blog post said yesterday, the posting on this site says today. Also, I'm a little taken aback by the it's beta rationalization for the massive disruption in service. It's one thing to mark it as public beta, it's another thing entirely to define 'beta' belatedly as not suitable for production use. Does that mean we get an SLA on the non- beta APIs? On Apr 23, 1:44 am, twitscoop lollic...@gmail.com wrote: Hi guys, is there an ETA for it to be restored ? It seems Oauth's recommended approach is to simply add a warning notice on authorization until this is fixed (this is what Google did). Anyways, even with this security flow, oauth is safer than providing twitter credentials to third parties... Thanks! Pierre On Apr 23, 7:30 am, Doug Williams d...@twitter.com wrote: Bill, The majority of our developers find OAuth sufficient because they are writing a Web applications. We are pleased that the deprecation of the source parameter lowered our support load and continues to drive adoption of our preferred authentication scheme. There are of course other cases where developers find the current implementation's beta status or browser requirement concerning. I have yet to reject a source parameter request that provides a valid argument explaining why OAuth does not meet the application's needs. Thanks, Doug Williams Twitter API Supporthttp://twitter.com/dougw On Wed, Apr 22, 2009 at 6:50 PM, Bill Robertson billrobertso...@gmail.comwrote: I respectfully disagree. (I would colorfully disagree, but you seem pretty beat up right now and you don't deserve any guff) I think developers of smaller apps see that little tag-line as a good source of advertising, and it seems inaccessible now if you're new (right? wrong?). You can only get it if you use OAuth, but OAuth is now disabled? Anyway, just my $0.02. Prioritize it like everything else you need to do (i.e. it's the 37th #1 thing on your list.) Good luck. On Apr 22, 7:58 pm, Alex Payne a...@twitter.com wrote: We don't consider source registration a key feature. It's an incentive we provide to our developers. We wanted to encourage new developers to look into OAuth. It won't be in beta forever, after all. We have to balance the reality of testing a new technology in our stack with encouraging that technology's adoption. OAuth will provide the Twitter developer community with a number of benefits, and that's the direction in which we want to move, even while there are kinks to work out. On Wed, Apr 22, 2009 at 15:37, bwannon bwan...@gmail.com wrote: If beta for you guys means still in testing, not suitable for production use, then why depreciate key features from basic auth like source registration before you have a production ready release? On Apr 22, 3:27 pm, Alex Payne a...@twitter.com
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
On 4/23/09 4:44 AM, twitscoop wrote: Anyways, even with this security flow, oauth is safer than providing twitter credentials to third parties... This is _absolutely_ NOT true! An attacker can't get in the middle of an application communicating to Twitter using HTTP Basic Auth. but they can in an OAuth flow. It's only safer in that you're not handing credentials to an otherwise questionable third-party application. However, if you do trust a third-party application and it uses OAuth, there is a non-zero chance that an attacker can gain access to your Twitter account, without needing your username or password, through the OAuth flow of your use of the trusted application. -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
On 4/23/09 11:21 AM, Dossy Shiobara wrote: On 4/23/09 10:04 AM, Andrew Badera wrote: Corrected: Overuse of the term by almost every web app since 2002, including GMail, notwithstanding. Web 2.0: It's Beta. (Forgive the pun, it's still early in the day ...) -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
On Thu, Apr 23, 2009 at 11:19 AM, Dossy Shiobara do...@panoptic.com wrote: An attacker can't get in the middle of an application communicating to Twitter using HTTP Basic Auth. WRONG. Anyone doing any sort of packet sniffing could easily get user/pass combos at will. Wireless promiscuous mode + WireShark = instant account hacking. This, of course, holds true only for http transactions (and not https transactions), but there are a good number of clients/apps that don't use the https endpoints. Man in the middle attacks are certainly possible with Basic Auth as well. They just eat the original request, steal the user/pass combo, and do whatever they want with it. -Chad
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
Good news, the oauth_callback parameter should /always/ be set in the application imho. Looking forward to your flip the switch celebrations today. On Apr 23, 9:59 am, Matt Sanford m...@twitter.com wrote: Hi all, We had to wait for the midnight deadline before giving too many details because we're taking a slightly more active approach. The code for these changes was scheduled to go out yesterday but there was a problem with some unrelated changes and the whole thing was rolled back. I'm hoping to get it out early today as an emergency deploy. If anyone has missed it, Eran posted a good explanation [1] for people not digging the security advisory wording. While I'm still working to get the changes out here is what you can expect: 1. The lifetime of a Request Token is now much, much shorter. This new time limit should be long enough for a person to complete the flow, but short enough that it cuts off attacks. » Note this is for request tokens, not access tokens. 2. For the time being the oauth_callback parameter will be disabled for both authentication and authorization. The user will be sent to the application callback in both cases. » I'm working with the other OAuth implementers on a way to bring it back, and Eran mentions it a bit at the end of his post [1]. We want to make sure it works correctly before launching it so you don't end up spending time to implement something we then have to turn off. As for questions about the severity of Twitter's initial response I think you'll find Yahoo! [2] has done the same. From the OAuth response mails I can assure you there were others as well but since they have no public mention of it I'll let them go unmolested. It wasn't just Twitter, that was just the only place you were looking :) Thanks; — Matt Sanford, of Alex and Doug fame [1] -http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-ses... [2] -http://developer.yahoo.net/blog/archives/2009/04/oauth_update.html On Apr 23, 2009, at 06:25 AM, mikehar wrote: Totally agree with Pierre. I think we all understand the security issue. Why was twitter's approach so much more severe than other services? Why not just a warning on login? Can Doug or Alex shed some light on this? wrt the ETA, can we get an update? One blog post said yesterday, the posting on this site says today. Also, I'm a little taken aback by the it's beta rationalization for the massive disruption in service. It's one thing to mark it as public beta, it's another thing entirely to define 'beta' belatedly as not suitable for production use. Does that mean we get an SLA on the non- beta APIs? On Apr 23, 1:44 am, twitscoop lollic...@gmail.com wrote: Hi guys, is there an ETA for it to be restored ? It seems Oauth's recommended approach is to simply add a warning notice on authorization until this is fixed (this is what Google did). Anyways, even with this security flow, oauth is safer than providing twitter credentials to third parties... Thanks! Pierre On Apr 23, 7:30 am, Doug Williams d...@twitter.com wrote: Bill, The majority of our developers find OAuth sufficient because they are writing a Web applications. We are pleased that the deprecation of the source parameter lowered our support load and continues to drive adoption of our preferred authentication scheme. There are of course other cases where developers find the current implementation's beta status or browser requirement concerning. I have yet to reject a source parameter request that provides a valid argument explaining why OAuth does not meet the application's needs. Thanks, Doug Williams Twitter API Supporthttp://twitter.com/dougw On Wed, Apr 22, 2009 at 6:50 PM, Bill Robertson billrobertso...@gmail.comwrote: I respectfully disagree. (I would colorfully disagree, but you seem pretty beat up right now and you don't deserve any guff) I think developers of smaller apps see that little tag-line as a good source of advertising, and it seems inaccessible now if you're new (right? wrong?). You can only get it if you use OAuth, but OAuth is now disabled? Anyway, just my $0.02. Prioritize it like everything else you need to do (i.e. it's the 37th #1 thing on your list.) Good luck. On Apr 22, 7:58 pm, Alex Payne a...@twitter.com wrote: We don't consider source registration a key feature. It's an incentive we provide to our developers. We wanted to encourage new developers to look into OAuth. It won't be in beta forever, after all. We have to balance the reality of testing a new technology in our stack with encouraging that technology's adoption. OAuth will provide the Twitter developer community with a number of benefits, and that's the direction in which we want to move, even while there are kinks to work out. On
[twitter-dev] Re: weird things on twitter
Please see the post on http://status.twitter.com explaining this behavior. On 4/23/09, ytbryan ytbr...@gmail.com wrote: hi all, i notice that a few people appeared under my friends pages. when i click in to investigate further, i realised that i am not following them. did anybody notice this ? -- Sent from my mobile device Doug Williams Twitter API Support http://twitter.com/dougw
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
It would be nice to be able to set multiple allowed callbacks, if this is the case, and specify which one to use in the request. I use the callback on my dev environment so I don't have to maintain two applications. (Also, the URL verification on callbacks doesn't support port numbers, but that's a secondary issue) -- ivey On Thu, Apr 23, 2009 at 10:37 AM, Mobasoft mobat...@gmail.com wrote: Good news, the oauth_callback parameter should /always/ be set in the application imho. Looking forward to your flip the switch celebrations today. On Apr 23, 9:59 am, Matt Sanford m...@twitter.com wrote: Hi all, We had to wait for the midnight deadline before giving too many details because we're taking a slightly more active approach. The code for these changes was scheduled to go out yesterday but there was a problem with some unrelated changes and the whole thing was rolled back. I'm hoping to get it out early today as an emergency deploy. If anyone has missed it, Eran posted a good explanation [1] for people not digging the security advisory wording. While I'm still working to get the changes out here is what you can expect: 1. The lifetime of a Request Token is now much, much shorter. This new time limit should be long enough for a person to complete the flow, but short enough that it cuts off attacks. » Note this is for request tokens, not access tokens. 2. For the time being the oauth_callback parameter will be disabled for both authentication and authorization. The user will be sent to the application callback in both cases. » I'm working with the other OAuth implementers on a way to bring it back, and Eran mentions it a bit at the end of his post [1]. We want to make sure it works correctly before launching it so you don't end up spending time to implement something we then have to turn off. As for questions about the severity of Twitter's initial response I think you'll find Yahoo! [2] has done the same. From the OAuth response mails I can assure you there were others as well but since they have no public mention of it I'll let them go unmolested. It wasn't just Twitter, that was just the only place you were looking :) Thanks; — Matt Sanford, of Alex and Doug fame [1] - http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-ses... [2] -http://developer.yahoo.net/blog/archives/2009/04/oauth_update.html On Apr 23, 2009, at 06:25 AM, mikehar wrote: Totally agree with Pierre. I think we all understand the security issue. Why was twitter's approach so much more severe than other services? Why not just a warning on login? Can Doug or Alex shed some light on this? wrt the ETA, can we get an update? One blog post said yesterday, the posting on this site says today. Also, I'm a little taken aback by the it's beta rationalization for the massive disruption in service. It's one thing to mark it as public beta, it's another thing entirely to define 'beta' belatedly as not suitable for production use. Does that mean we get an SLA on the non- beta APIs? On Apr 23, 1:44 am, twitscoop lollic...@gmail.com wrote: Hi guys, is there an ETA for it to be restored ? It seems Oauth's recommended approach is to simply add a warning notice on authorization until this is fixed (this is what Google did). Anyways, even with this security flow, oauth is safer than providing twitter credentials to third parties... Thanks! Pierre On Apr 23, 7:30 am, Doug Williams d...@twitter.com wrote: Bill, The majority of our developers find OAuth sufficient because they are writing a Web applications. We are pleased that the deprecation of the source parameter lowered our support load and continues to drive adoption of our preferred authentication scheme. There are of course other cases where developers find the current implementation's beta status or browser requirement concerning. I have yet to reject a source parameter request that provides a valid argument explaining why OAuth does not meet the application's needs. Thanks, Doug Williams Twitter API Supporthttp://twitter.com/dougw On Wed, Apr 22, 2009 at 6:50 PM, Bill Robertson billrobertso...@gmail.comwrote: I respectfully disagree. (I would colorfully disagree, but you seem pretty beat up right now and you don't deserve any guff) I think developers of smaller apps see that little tag-line as a good source of advertising, and it seems inaccessible now if you're new (right? wrong?). You can only get it if you use OAuth, but OAuth is now disabled? Anyway, just my $0.02. Prioritize it like everything else you need to do (i.e. it's the 37th #1 thing on your list.) Good luck. On Apr 22, 7:58 pm, Alex Payne a...@twitter.com wrote: We don't consider source registration a key feature. It's an
[twitter-dev] replies url gone?
I've just noticed some @reply functionality is not working in my app I was aware of the change to mentions but not that this involved a change in url to http://twitter.com/statuses/mentions.format is the old http://twitter.com/statuses/replies.format dead? Any chance of reinstating if so? http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-mentions Rhys
[twitter-dev] search API issue : source: doesn't work in some case
Hi, Today I noticed that my Twitter4J automated testcase for the search API started to fail. query: thisisarondomstringforatestcase returns 1 tweet. http://search.twitter.com/search?q=thisisarondomstringforatestcase But query: source:web thisisarondomstringforatestcase returns 0 tweet despite that the above tweet was posted via web. http://search.twitter.com/search?q=source%3Aweb+thisisarondomstringforatestcase It used to be returning one single tweet. Is there any problem with the search API? Best regards, Yusuke
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
Hi Michael, We've been discussing that in the group of people dealing with the security issue. It seems like AuthSub tried that route and found it to be very problematic. More often than not people went with open redirectors to make it easy, and therefor bypassed all security. We're working on a way to allow it to be dynamic, but make sure it is signed so we don't have to keep it this way. This involves sending it when you get the request token, and then making sure you know what you sent when you get the access token. Once we have a working version in the wild for people to try I'll give a more detailed description. Thanks; – Matt Sanford / @mzsanford Twitter API Developer On Apr 23, 2009, at 08:47 AM, Michael Ivey wrote: It would be nice to be able to set multiple allowed callbacks, if this is the case, and specify which one to use in the request. I use the callback on my dev environment so I don't have to maintain two applications. (Also, the URL verification on callbacks doesn't support port numbers, but that's a secondary issue) -- ivey On Thu, Apr 23, 2009 at 10:37 AM, Mobasoft mobat...@gmail.com wrote: Good news, the oauth_callback parameter should /always/ be set in the application imho. Looking forward to your flip the switch celebrations today. On Apr 23, 9:59 am, Matt Sanford m...@twitter.com wrote: Hi all, We had to wait for the midnight deadline before giving too many details because we're taking a slightly more active approach. The code for these changes was scheduled to go out yesterday but there was a problem with some unrelated changes and the whole thing was rolled back. I'm hoping to get it out early today as an emergency deploy. If anyone has missed it, Eran posted a good explanation [1] for people not digging the security advisory wording. While I'm still working to get the changes out here is what you can expect: 1. The lifetime of a Request Token is now much, much shorter. This new time limit should be long enough for a person to complete the flow, but short enough that it cuts off attacks. » Note this is for request tokens, not access tokens. 2. For the time being the oauth_callback parameter will be disabled for both authentication and authorization. The user will be sent to the application callback in both cases. » I'm working with the other OAuth implementers on a way to bring it back, and Eran mentions it a bit at the end of his post [1]. We want to make sure it works correctly before launching it so you don't end up spending time to implement something we then have to turn off. As for questions about the severity of Twitter's initial response I think you'll find Yahoo! [2] has done the same. From the OAuth response mails I can assure you there were others as well but since they have no public mention of it I'll let them go unmolested. It wasn't just Twitter, that was just the only place you were looking :) Thanks; — Matt Sanford, of Alex and Doug fame [1] -http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-ses ... [2] -http://developer.yahoo.net/blog/archives/2009/04/oauth_update.html On Apr 23, 2009, at 06:25 AM, mikehar wrote: Totally agree with Pierre. I think we all understand the security issue. Why was twitter's approach so much more severe than other services? Why not just a warning on login? Can Doug or Alex shed some light on this? wrt the ETA, can we get an update? One blog post said yesterday, the posting on this site says today. Also, I'm a little taken aback by the it's beta rationalization for the massive disruption in service. It's one thing to mark it as public beta, it's another thing entirely to define 'beta' belatedly as not suitable for production use. Does that mean we get an SLA on the non- beta APIs? On Apr 23, 1:44 am, twitscoop lollic...@gmail.com wrote: Hi guys, is there an ETA for it to be restored ? It seems Oauth's recommended approach is to simply add a warning notice on authorization until this is fixed (this is what Google did). Anyways, even with this security flow, oauth is safer than providing twitter credentials to third parties... Thanks! Pierre On Apr 23, 7:30 am, Doug Williams d...@twitter.com wrote: Bill, The majority of our developers find OAuth sufficient because they are writing a Web applications. We are pleased that the deprecation of the source parameter lowered our support load and continues to drive adoption of our preferred authentication scheme. There are of course other cases where developers find the current implementation's beta status or browser requirement concerning. I have yet to reject a source parameter request that provides a valid argument explaining why OAuth does not meet the application's needs. Thanks, Doug Williams Twitter API
[twitter-dev] Re: replies url gone?
Hi Rhys, Both should work at the moment. We still have both configured and I just did some curl requests with my test account and verified it. Are you getting any specific error? curl requests with headers (curl - v, but be sure to obscure the Authorization header) always help in times like these. Thanks; – Matt Sanford / @mzsanford Twitter API Developer On Apr 23, 2009, at 08:51 AM, rhysmeister wrote: I've just noticed some @reply functionality is not working in my app I was aware of the change to mentions but not that this involved a change in url to http://twitter.com/statuses/mentions.format is the old http://twitter.com/statuses/replies.format dead? Any chance of reinstating if so? http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses- mentions Rhys
[twitter-dev] Re: search API issue : source: doesn't work in some case
Hi Yusuke, Unfortunately the source: operator as it is currently implemented has a few shortcomings. One is that it requires a query, and the second is that it can only search the last 7 days. This is a known performance issue and we're still looking for a way we can remove the restriction. I'll talk to Doug about updating the docs. Thanks; – Matt Sanford / @mzsanford Twitter API Developer On Apr 23, 2009, at 08:55 AM, Yusuke wrote: Hi, Today I noticed that my Twitter4J automated testcase for the search API started to fail. query: thisisarondomstringforatestcase returns 1 tweet. http://search.twitter.com/search?q=thisisarondomstringforatestcase But query: source:web thisisarondomstringforatestcase returns 0 tweet despite that the above tweet was posted via web. http://search.twitter.com/search?q=source%3Aweb+thisisarondomstringforatestcase It used to be returning one single tweet. Is there any problem with the search API? Best regards, Yusuke
[twitter-dev] befriending with non-existing account started to return status code 404, it used to be 403
Hi, I noticed that now the API returns 404 status code when a client called /friendships/create/[non-existing-user].xml. The API used to be returning 403 status code. Will it be a permanent behavior? Or is it subject to change? I'll be nice if the status codes in exceptional cases are explicitly documented so that client developers can confidently implement error handling codes. Cheers, Yusuke
[twitter-dev] Re: replies url gone?
Hi Rhys, Bas request is generally something like unescaped characters in the URL. Can you try with curl and send the URL causing the problem? Thanks; – Matt Sanford / @mzsanford Twitter API Developer On Apr 23, 2009, at 09:08 AM, rhysmeister wrote: Hi Matt, I'm getting Error: The remote server returned an error: (400) Bad Request. Definatly not rate limiting here. Rhys On Apr 23, 4:59 pm, Matt Sanford m...@twitter.com wrote: Hi Rhys, Both should work at the moment. We still have both configured and I just did some curl requests with my test account and verified it. Are you getting any specific error? curl requests with headers (curl - v, but be sure to obscure the Authorization header) always help in times like these. Thanks; – Matt Sanford / @mzsanford Twitter API Developer On Apr 23, 2009, at 08:51 AM, rhysmeister wrote: I've just noticed some @reply functionality is not working in my app I was aware of the change to mentions but not that this involved a change in url tohttp://twitter.com/statuses/mentions.formatis the oldhttp://twitter.com/statuses/replies.formatdead? Any chance of reinstating if so? http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses- mentions Rhys
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
What, could you hear me groaning from all the way up in Albany? ;) On Thu, Apr 23, 2009 at 11:24 AM, Dossy Shiobara do...@panoptic.com wrote: On 4/23/09 11:21 AM, Dossy Shiobara wrote: On 4/23/09 10:04 AM, Andrew Badera wrote: Corrected: Overuse of the term by almost every web app since 2002, including GMail, notwithstanding. Web 2.0: It's Beta. (Forgive the pun, it's still early in the day ...) -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
Please don't let this slow down Twitter's turning it back on. Just let everyone set it in the application and be done with it. If they want a different callback url, then simply create a MyApp_Test app and put in a different application return url. 100% working sure in the hell beats 0% implemented while we try to make it dynamic for a small percentage of applications/people. Thanks for taking my $0.02 On Apr 23, 10:57 am, Matt Sanford m...@twitter.com wrote: Hi Michael, We've been discussing that in the group of people dealing with the security issue. It seems like AuthSub tried that route and found it to be very problematic. More often than not people went with open redirectors to make it easy, and therefor bypassed all security. We're working on a way to allow it to be dynamic, but make sure it is signed so we don't have to keep it this way. This involves sending it when you get the request token, and then making sure you know what you sent when you get the access token. Once we have a working version in the wild for people to try I'll give a more detailed description. Thanks; – Matt Sanford / @mzsanford Twitter API Developer On Apr 23, 2009, at 08:47 AM, Michael Ivey wrote: It would be nice to be able to set multiple allowed callbacks, if this is the case, and specify which one to use in the request. I use the callback on my dev environment so I don't have to maintain two applications. (Also, the URL verification on callbacks doesn't support port numbers, but that's a secondary issue) -- ivey On Thu, Apr 23, 2009 at 10:37 AM, Mobasoft mobat...@gmail.com wrote: Good news, the oauth_callback parameter should /always/ be set in the application imho. Looking forward to your flip the switch celebrations today. On Apr 23, 9:59 am, Matt Sanford m...@twitter.com wrote: Hi all, We had to wait for the midnight deadline before giving too many details because we're taking a slightly more active approach. The code for these changes was scheduled to go out yesterday but there was a problem with some unrelated changes and the whole thing was rolled back. I'm hoping to get it out early today as an emergency deploy. If anyone has missed it, Eran posted a good explanation [1] for people not digging the security advisory wording. While I'm still working to get the changes out here is what you can expect: 1. The lifetime of a Request Token is now much, much shorter. This new time limit should be long enough for a person to complete the flow, but short enough that it cuts off attacks. » Note this is for request tokens, not access tokens. 2. For the time being the oauth_callback parameter will be disabled for both authentication and authorization. The user will be sent to the application callback in both cases. » I'm working with the other OAuth implementers on a way to bring it back, and Eran mentions it a bit at the end of his post [1]. We want to make sure it works correctly before launching it so you don't end up spending time to implement something we then have to turn off. As for questions about the severity of Twitter's initial response I think you'll find Yahoo! [2] has done the same. From the OAuth response mails I can assure you there were others as well but since they have no public mention of it I'll let them go unmolested. It wasn't just Twitter, that was just the only place you were looking :) Thanks; — Matt Sanford, of Alex and Doug fame [1] -http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-ses ... [2] -http://developer.yahoo.net/blog/archives/2009/04/oauth_update.html On Apr 23, 2009, at 06:25 AM, mikehar wrote: Totally agree with Pierre. I think we all understand the security issue. Why was twitter's approach so much more severe than other services? Why not just a warning on login? Can Doug or Alex shed some light on this? wrt the ETA, can we get an update? One blog post said yesterday, the posting on this site says today. Also, I'm a little taken aback by the it's beta rationalization for the massive disruption in service. It's one thing to mark it as public beta, it's another thing entirely to define 'beta' belatedly as not suitable for production use. Does that mean we get an SLA on the non- beta APIs? On Apr 23, 1:44 am, twitscoop lollic...@gmail.com wrote: Hi guys, is there an ETA for it to be restored ? It seems Oauth's recommended approach is to simply add a warning notice on authorization until this is fixed (this is what Google did). Anyways, even with this security flow, oauth is safer than providing twitter credentials to third parties... Thanks! Pierre On Apr 23, 7:30 am, Doug Williams d...@twitter.com wrote:
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
Thanks, Matt! Even though it kills my latest project, I'm still in agreement that turning oAuth back on without oauth_callback is preferable to leaving it off. oauth_callback is very important to me, though, so I would lobby for bringing it back in some form as quickly as possible. Apr 23, 9:37 am, Matt Sanford m...@twitter.com wrote: Hi there, It isn't slowing anything. My first change was just to disable oauth_callback, this other method is considered gravy. I'm in total agreement (as the OAuth implementer at Twitter) that it beats the hell out of 0% available. I'm pushing with all my might to get this deployed despite anyone else's priorities. I take this all far too seriously. Thanks; – Matt Sanford / @mzsanford Twitter API Developer On Apr 23, 2009, at 09:32 AM, Mobasoft wrote: Please don't let this slow down Twitter's turning it back on. Just let everyone set it in the application and be done with it. If they want a different callback url, then simply create a MyApp_Test app and put in a different application return url. 100% working sure in the hell beats 0% implemented while we try to make it dynamic for a small percentage of applications/people. Thanks for taking my $0.02 On Apr 23, 10:57 am, Matt Sanford m...@twitter.com wrote: Hi Michael, We've been discussing that in the group of people dealing with the security issue. It seems like AuthSub tried that route and found it to be very problematic. More often than not people went with open redirectors to make it easy, and therefor bypassed all security. We're working on a way to allow it to be dynamic, but make sure it is signed so we don't have to keep it this way. This involves sending it when you get the request token, and then making sure you know what you sent when you get the access token. Once we have a working version in the wild for people to try I'll give a more detailed description. Thanks; – Matt Sanford / @mzsanford Twitter API Developer On Apr 23, 2009, at 08:47 AM, Michael Ivey wrote: It would be nice to be able to set multiple allowed callbacks, if this is the case, and specify which one to use in the request. I use the callback on my dev environment so I don't have to maintain two applications. (Also, the URL verification on callbacks doesn't support port numbers, but that's a secondary issue) -- ivey On Thu, Apr 23, 2009 at 10:37 AM, Mobasoft mobat...@gmail.com wrote: Good news, the oauth_callback parameter should /always/ be set in the application imho. Looking forward to your flip the switch celebrations today. On Apr 23, 9:59 am, Matt Sanford m...@twitter.com wrote: Hi all, We had to wait for the midnight deadline before giving too many details because we're taking a slightly more active approach. The code for these changes was scheduled to go out yesterday but there was a problem with some unrelated changes and the whole thing was rolled back. I'm hoping to get it out early today as an emergency deploy. If anyone has missed it, Eran posted a good explanation [1] for people not digging the security advisory wording. While I'm still working to get the changes out here is what you can expect: 1. The lifetime of a Request Token is now much, much shorter. This new time limit should be long enough for a person to complete the flow, but short enough that it cuts off attacks. » Note this is for request tokens, not access tokens. 2. For the time being the oauth_callback parameter will be disabled for both authentication and authorization. The user will be sent to the application callback in both cases. » I'm working with the other OAuth implementers on a way to bring it back, and Eran mentions it a bit at the end of his post [1]. We want to make sure it works correctly before launching it so you don't end up spending time to implement something we then have to turn off. As for questions about the severity of Twitter's initial response I think you'll find Yahoo! [2] has done the same. From the OAuth response mails I can assure you there were others as well but since they have no public mention of it I'll let them go unmolested. It wasn't just Twitter, that was just the only place you were looking :) Thanks; — Matt Sanford, of Alex and Doug fame [1] -http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-ses ... [2] -http://developer.yahoo.net/blog/archives/2009/04/oauth_update.html On Apr 23, 2009, at 06:25 AM, mikehar wrote: Totally agree with Pierre. I think we all understand the security issue. Why was twitter's approach so much more severe than other services? Why not just a warning on login? Can Doug or Alex shed some light on this? wrt the ETA, can we get an update? One blog post said yesterday, the posting on this
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
Glad you stepped in, Chad, because I felt really stupid for a second. And like I said, it's less harmful to have your oAuth session stolen (you can just unauthorize the application) than to have your plain twitter credentials exposed. Anyway this is not the subject of this thread, I'm just glad we are going to be able to play with oAuth again soon :o) On Apr 23, 5:33 pm, Chad Etzel jazzyc...@gmail.com wrote: On Thu, Apr 23, 2009 at 11:19 AM, Dossy Shiobara do...@panoptic.com wrote: An attacker can't get in the middle of an application communicating to Twitter using HTTP Basic Auth. WRONG. Anyone doing any sort of packet sniffing could easily get user/pass combos at will. Wireless promiscuous mode + WireShark = instant account hacking. This, of course, holds true only for http transactions (and not https transactions), but there are a good number of clients/apps that don't use the https endpoints. Man in the middle attacks are certainly possible with Basic Auth as well. They just eat the original request, steal the user/pass combo, and do whatever they want with it. -Chad
[twitter-dev] Re: Rate Limit Issue?
Oh and just to add on, I'm utilizing the REST API as I'm aware of the current limit of search. Also, I've queried my existing rate limit status and the xml data returned showed a current limit of 100. Thanks once again, DuBose
[twitter-dev] Re: Rate Limit Issue?
Hi Matt, Thanks for such a quick response, I really appreciate the help. I think the way I'm using vba (kicking myself for not actually starting the project explicitly in .net/visual studio), my method won't allow the last workaround used. If I can ask, in the URL that is submitted to the REST API, I'm currently quering using my login and password in the following format: Http://username:passw...@twitter., is there a way to include these as parameters later in the URL? After taking your suggestion and using Charles, I can see that the account details aren't being transferred wtih the rest of the URL to your API and thought if there is another place your API accepts it, I could use it as a workaround. Any help you could provide would be great as I've become slightly invested in the way I've created it so far and would hate to scrap parts and redo it. Thanks, DuBose On Apr 23, 4:14 pm, Matt Sanford m...@twitter.com wrote: Hi DuBose, The account looks whitelisted. The most common issue when using authenticated requests is that you're calling a method that does not require authentication and your HTTP library is not sending it. I have seen some reports of this with .NET languages. Take a look at this old discussion and see if it helps: http://groups.google.com/group/twitter-development-talk/browse_thread... If not you might want to try using a proxy like Charles [1] so you can verify the requests are being sent with an Authorization header. Thanks; — Matt Sanford [1] -http://www.charlesproxy.com/ On Apr 23, 2009, at 08:02 AM, DuBose Cole wrote: I was wondering if anyone else has encountered problems with the rate limit while whitelisted. I recieved whitelisting authorization for my app development, but my rate still shows up as 100 per hour. After running into this problem and reading about some database issues a while back, I applied again, got accepted and have encountered the same issue. I'm making authenticated calls in my code using my white listed id (@dubosecole). I'm using basic authorization and not OAuth, are there any other steps anyone can suggest? I'm using it for network visualization/message transmission analysis rates in a relatively simple vba package and this rate limit issue is seriously slowing down development. Any help anyone can provide would be appreciated. Thanks, DuBose
[twitter-dev] Re: Rate Limit Issue?
Hi there, The username:password in the URL is a shortcut but it sounds like the VBA library is ignoring it. Well, is stripping it and not creating and Authorization header. There is no way to specify these later in the URL. If the library lets you set headers you could try generating the Authorization header yourself, but outside of that I'm not aware of any work around. Thanks; – Matt Sanford / @mzsanford Twitter API Developer On Apr 23, 2009, at 09:57 AM, DuBose Cole wrote: Hi Matt, Thanks for such a quick response, I really appreciate the help. I think the way I'm using vba (kicking myself for not actually starting the project explicitly in .net/visual studio), my method won't allow the last workaround used. If I can ask, in the URL that is submitted to the REST API, I'm currently quering using my login and password in the following format: Http://username:passw...@twitter., is there a way to include these as parameters later in the URL? After taking your suggestion and using Charles, I can see that the account details aren't being transferred wtih the rest of the URL to your API and thought if there is another place your API accepts it, I could use it as a workaround. Any help you could provide would be great as I've become slightly invested in the way I've created it so far and would hate to scrap parts and redo it. Thanks, DuBose On Apr 23, 4:14 pm, Matt Sanford m...@twitter.com wrote: Hi DuBose, The account looks whitelisted. The most common issue when using authenticated requests is that you're calling a method that does not require authentication and your HTTP library is not sending it. I have seen some reports of this with .NET languages. Take a look at this old discussion and see if it helps: http://groups.google.com/group/twitter-development-talk/browse_thread ... If not you might want to try using a proxy like Charles [1] so you can verify the requests are being sent with an Authorization header. Thanks; — Matt Sanford [1] -http://www.charlesproxy.com/ On Apr 23, 2009, at 08:02 AM, DuBose Cole wrote: I was wondering if anyone else has encountered problems with the rate limit while whitelisted. I recieved whitelisting authorization for my app development, but my rate still shows up as 100 per hour. After running into this problem and reading about some database issues a while back, I applied again, got accepted and have encountered the same issue. I'm making authenticated calls in my code using my white listed id (@dubosecole). I'm using basic authorization and not OAuth, are there any other steps anyone can suggest? I'm using it for network visualization/message transmission analysis rates in a relatively simple vba package and this rate limit issue is seriously slowing down development. Any help anyone can provide would be appreciated. Thanks, DuBose
[twitter-dev] Re: befriending with non-existing account started to return status code 404, it used to be 403
An HTTP 404 is the correct response because you are attempting to access a nonexistent resource. This behavior is correctly documented here [1]. 1. http://apiwiki.twitter.com/HTTP-Response-Codes-and-Errors Doug Williams Twitter API Support http://twitter.com/dougw On Thu, Apr 23, 2009 at 9:03 AM, Yusuke yus...@mac.com wrote: Hi, I noticed that now the API returns 404 status code when a client called /friendships/create/[non-existing-user].xml. The API used to be returning 403 status code. Will it be a permanent behavior? Or is it subject to change? I'll be nice if the status codes in exceptional cases are explicitly documented so that client developers can confidently implement error handling codes. Cheers, Yusuke
[twitter-dev] Anyone updating email address from API?
Are there many apps using the email parameter for update_profile? being able to change the email associated with an account seems to defeat some of the purpose of using OAuth. http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-account%C2%A0update_profile Abraham -- Abraham Williams | http://the.hackerconundrum.com Hacker | http://abrah.am | http://twitter.com/abraham Web608 | Community Evangelist | http://web608.org This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: Get Twitter users list(by screenname)
If your app is not whitelisted, then it subjects to 100 API call/hour/ IP, which means you can only call users/show 2400 times a day On Apr 23, 6:34 am, kkp 33spa...@gmail.com wrote: Hi, I am new to this group(Twitter API). we have a requiremnt like ... we need to get the Twitter users list (to follow). After getting the list,user can select the user from the list and follow the twitter user. we are able to get the twitter users who are followed and whom i am following.But i am unable to get the twitter users list to follow. How can we get the twitter users list?. Any help can be appriciated. Regards kkp
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
I understand killing oauth_callback, but I would propose that you shouldn't kill the ability for the app to send info that will be returned to it upon redirecting. Is this possible? For example, you could simply pass oauth_callback back to the calling app even though you're not going to listen to it. On Apr 23, 12:37 pm, Matt Sanford m...@twitter.com wrote: Hi there, It isn't slowing anything. My first change was just to disable oauth_callback, this other method is considered gravy. I'm in total agreement (as the OAuth implementer at Twitter) that it beats the hell out of 0% available. I'm pushing with all my might to get this deployed despite anyone else's priorities. I take this all far too seriously. Thanks; – Matt Sanford / @mzsanford Twitter API Developer On Apr 23, 2009, at 09:32 AM, Mobasoft wrote: Please don't let this slow down Twitter's turning it back on. Just let everyone set it in the application and be done with it. If they want a different callback url, then simply create a MyApp_Test app and put in a different application return url. 100% working sure in the hell beats 0% implemented while we try to make it dynamic for a small percentage of applications/people. Thanks for taking my $0.02 On Apr 23, 10:57 am, Matt Sanford m...@twitter.com wrote: Hi Michael, We've been discussing that in the group of people dealing with the security issue. It seems like AuthSub tried that route and found it to be very problematic. More often than not people went with open redirectors to make it easy, and therefor bypassed all security. We're working on a way to allow it to be dynamic, but make sure it is signed so we don't have to keep it this way. This involves sending it when you get the request token, and then making sure you know what you sent when you get the access token. Once we have a working version in the wild for people to try I'll give a more detailed description. Thanks; – Matt Sanford / @mzsanford Twitter API Developer On Apr 23, 2009, at 08:47 AM, Michael Ivey wrote: It would be nice to be able to set multiple allowed callbacks, if this is the case, and specify which one to use in the request. I use the callback on my dev environment so I don't have to maintain two applications. (Also, the URL verification on callbacks doesn't support port numbers, but that's a secondary issue) -- ivey On Thu, Apr 23, 2009 at 10:37 AM, Mobasoft mobat...@gmail.com wrote: Good news, the oauth_callback parameter should /always/ be set in the application imho. Looking forward to your flip the switch celebrations today. On Apr 23, 9:59 am, Matt Sanford m...@twitter.com wrote: Hi all, We had to wait for the midnight deadline before giving too many details because we're taking a slightly more active approach. The code for these changes was scheduled to go out yesterday but there was a problem with some unrelated changes and the whole thing was rolled back. I'm hoping to get it out early today as an emergency deploy. If anyone has missed it, Eran posted a good explanation [1] for people not digging the security advisory wording. While I'm still working to get the changes out here is what you can expect: 1. The lifetime of a Request Token is now much, much shorter. This new time limit should be long enough for a person to complete the flow, but short enough that it cuts off attacks. » Note this is for request tokens, not access tokens. 2. For the time being the oauth_callback parameter will be disabled for both authentication and authorization. The user will be sent to the application callback in both cases. » I'm working with the other OAuth implementers on a way to bring it back, and Eran mentions it a bit at the end of his post [1]. We want to make sure it works correctly before launching it so you don't end up spending time to implement something we then have to turn off. As for questions about the severity of Twitter's initial response I think you'll find Yahoo! [2] has done the same. From the OAuth response mails I can assure you there were others as well but since they have no public mention of it I'll let them go unmolested. It wasn't just Twitter, that was just the only place you were looking :) Thanks; — Matt Sanford, of Alex and Doug fame [1] -http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-ses ... [2] -http://developer.yahoo.net/blog/archives/2009/04/oauth_update.html On Apr 23, 2009, at 06:25 AM, mikehar wrote: Totally agree with Pierre. I think we all understand the security issue. Why was twitter's approach so much more severe than other services? Why not just a warning on login? Can Doug or Alex shed some light on this? wrt the ETA, can we get an update? One blog post said yesterday, the
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
On 4/23/09 11:33 AM, Chad Etzel wrote: On Thu, Apr 23, 2009 at 11:19 AM, Dossy Shiobarado...@panoptic.com wrote: An attacker can't get in the middle of an application communicating to Twitter using HTTP Basic Auth. WRONG. Anyone doing any sort of packet sniffing could easily get user/pass combos at will. Wireless promiscuous mode + WireShark = instant account hacking. This, of course, holds true only for http transactions (and not https transactions), but there are a good number of clients/apps that don't use the https endpoints. Packet sniffing as an attack vector is significantly more difficult to achieve than the OAuth attack is. Defend against the more likely threats before worrying about the less likely ones. Man in the middle attacks are certainly possible with Basic Auth as well. They just eat the original request, steal the user/pass combo, and do whatever they want with it. This is a standard phishing attack, and standard advice for anti-phishing applies here. -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
On Thu, Apr 23, 2009 at 2:35 PM, Dossy Shiobara do...@panoptic.com wrote: On 4/23/09 11:33 AM, Chad Etzel wrote: On Thu, Apr 23, 2009 at 11:19 AM, Dossy Shiobarado...@panoptic.com wrote: An attacker can't get in the middle of an application communicating to Twitter using HTTP Basic Auth. WRONG. Anyone doing any sort of packet sniffing could easily get user/pass combos at will. Wireless promiscuous mode + WireShark = instant account hacking. This, of course, holds true only for http transactions (and not https transactions), but there are a good number of clients/apps that don't use the https endpoints. Packet sniffing as an attack vector is significantly more difficult to achieve than the OAuth attack is. Defend against the more likely threats before worrying about the less likely ones. I wholeheartedly disagree. Sit in a tech conference room with a laptop and sniff away at least a hundred accounts in under 5 minutes. I'm not saying I've done it, but I'm not saying I haven't, either Man in the middle attacks are certainly possible with Basic Auth as well. They just eat the original request, steal the user/pass combo, and do whatever they want with it. This is a standard phishing attack, and standard advice for anti-phishing applies here. No, phishing != man-in-the-middle. If I hack a router to intercept all traffic headed toward twitter.com and then grok out the credentials, this is has nothing to do with social engineering or phishing... I've just screwed your account, and you have no idea how. Obviously there are attack vectors with both methods, but I contend that Basic Auth is much much much easier to attack than OAuth (even in its current state, and even moreso when it is upgraded/patched to deal with this new vector). -Chad
[twitter-dev] 500s from http://search.twitter.com/trends/current.json
I was getting a number of itnermittend 500 errors from: http://search.twitter.com/trends/current.json Is there a box in rotation that's behaving badly?
[twitter-dev] Re: Anyone updating email address from API?
Well, the criteria for email should be looked at either way. email. Optional. Maximum of 40 characters. Must be a valid email address. alexander.h.wann...@mobility.domainisnothere.org (48 characters and could easily be valid) On Apr 23, 12:23 pm, Abraham Williams 4bra...@gmail.com wrote: Are there many apps using the email parameter for update_profile? being able to change the email associated with an account seems to defeat some of the purpose of using OAuth. http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-account%C2%A0up... Abraham -- Abraham Williams |http://the.hackerconundrum.com Hacker |http://abrah.am|http://twitter.com/abraham Web608 | Community Evangelist |http://web608.org This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
@mzsanford Thanks Matt, no matter what all these other Yahoo's are saying about you, it's appreciated! (j/k to all you Yahoo's) ;^) -Michael p.s. Is OAuth back on yet? I'd hate to see it start getting the nickname of NOAuth. On Apr 23, 1:43 pm, Chad Etzel jazzyc...@gmail.com wrote: On Thu, Apr 23, 2009 at 2:35 PM, Dossy Shiobara do...@panoptic.com wrote: On 4/23/09 11:33 AM, Chad Etzel wrote: On Thu, Apr 23, 2009 at 11:19 AM, Dossy Shiobarado...@panoptic.com wrote: An attacker can't get in the middle of an application communicating to Twitter using HTTP Basic Auth. WRONG. Anyone doing any sort of packet sniffing could easily get user/pass combos at will. Wireless promiscuous mode + WireShark = instant account hacking. This, of course, holds true only for http transactions (and not https transactions), but there are a good number of clients/apps that don't use the https endpoints. Packet sniffing as an attack vector is significantly more difficult to achieve than the OAuth attack is. Defend against the more likely threats before worrying about the less likely ones. I wholeheartedly disagree. Sit in a tech conference room with a laptop and sniff away at least a hundred accounts in under 5 minutes. I'm not saying I've done it, but I'm not saying I haven't, either Man in the middle attacks are certainly possible with Basic Auth as well. They just eat the original request, steal the user/pass combo, and do whatever they want with it. This is a standard phishing attack, and standard advice for anti-phishing applies here. No, phishing != man-in-the-middle. If I hack a router to intercept all traffic headed toward twitter.com and then grok out the credentials, this is has nothing to do with social engineering or phishing... I've just screwed your account, and you have no idea how. Obviously there are attack vectors with both methods, but I contend that Basic Auth is much much much easier to attack than OAuth (even in its current state, and even moreso when it is upgraded/patched to deal with this new vector). -Chad
[twitter-dev] Re: 500s from http://search.twitter.com/trends/current.json
Hi Dave, I just checked the last hours worth of logs and I don't see any 500s. The logs messages might be getting dropped somewhere, can you try accessing with 'curl -v' and send the output when you can reproduce it? Thanks; – Matt Sanford / @mzsanford Twitter API Developer On Apr 23, 2009, at 12:24 PM, Dave Dash wrote: I was getting a number of itnermittend 500 errors from: http://search.twitter.com/trends/current.json Is there a box in rotation that's behaving badly?
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
Mobasoft, Rest assured we will make an announcement when OAuth support is restored. Doug Williams Twitter API Support http://twitter.com/dougw On Thu, Apr 23, 2009 at 12:42 PM, Mobasoft mobat...@gmail.com wrote: @mzsanford Thanks Matt, no matter what all these other Yahoo's are saying about you, it's appreciated! (j/k to all you Yahoo's) ;^) -Michael p.s. Is OAuth back on yet? I'd hate to see it start getting the nickname of NOAuth. On Apr 23, 1:43 pm, Chad Etzel jazzyc...@gmail.com wrote: On Thu, Apr 23, 2009 at 2:35 PM, Dossy Shiobara do...@panoptic.com wrote: On 4/23/09 11:33 AM, Chad Etzel wrote: On Thu, Apr 23, 2009 at 11:19 AM, Dossy Shiobarado...@panoptic.com wrote: An attacker can't get in the middle of an application communicating to Twitter using HTTP Basic Auth. WRONG. Anyone doing any sort of packet sniffing could easily get user/pass combos at will. Wireless promiscuous mode + WireShark = instant account hacking. This, of course, holds true only for http transactions (and not https transactions), but there are a good number of clients/apps that don't use the https endpoints. Packet sniffing as an attack vector is significantly more difficult to achieve than the OAuth attack is. Defend against the more likely threats before worrying about the less likely ones. I wholeheartedly disagree. Sit in a tech conference room with a laptop and sniff away at least a hundred accounts in under 5 minutes. I'm not saying I've done it, but I'm not saying I haven't, either Man in the middle attacks are certainly possible with Basic Auth as well. They just eat the original request, steal the user/pass combo, and do whatever they want with it. This is a standard phishing attack, and standard advice for anti-phishing applies here. No, phishing != man-in-the-middle. If I hack a router to intercept all traffic headed toward twitter.com and then grok out the credentials, this is has nothing to do with social engineering or phishing... I've just screwed your account, and you have no idea how. Obviously there are attack vectors with both methods, but I contend that Basic Auth is much much much easier to attack than OAuth (even in its current state, and even moreso when it is upgraded/patched to deal with this new vector). -Chad
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
Hi Everybody! (Dr. Nick voice) OAuth is once again live, and as described below the oauth_callback has been disabled. I've begun testing the replacement options for oauth_callback and will hopefully get something out soon to replace it. In the mean time successful authorization or authentication will send the user to your pre-registered callback URL. Thanks; – Matt Sanford / @mzsanford Twitter API Developer On Apr 23, 2009, at 07:59 AM, Matt Sanford wrote: Hi all, We had to wait for the midnight deadline before giving too many details because we're taking a slightly more active approach. The code for these changes was scheduled to go out yesterday but there was a problem with some unrelated changes and the whole thing was rolled back. I'm hoping to get it out early today as an emergency deploy. If anyone has missed it, Eran posted a good explanation [1] for people not digging the security advisory wording. While I'm still working to get the changes out here is what you can expect: 1. The lifetime of a Request Token is now much, much shorter. This new time limit should be long enough for a person to complete the flow, but short enough that it cuts off attacks. » Note this is for request tokens, not access tokens. 2. For the time being the oauth_callback parameter will be disabled for both authentication and authorization. The user will be sent to the application callback in both cases. » I'm working with the other OAuth implementers on a way to bring it back, and Eran mentions it a bit at the end of his post [1]. We want to make sure it works correctly before launching it so you don't end up spending time to implement something we then have to turn off. As for questions about the severity of Twitter's initial response I think you'll find Yahoo! [2] has done the same. From the OAuth response mails I can assure you there were others as well but since they have no public mention of it I'll let them go unmolested. It wasn't just Twitter, that was just the only place you were looking :) Thanks; Matt Sanford, of Alex and Doug fame [1] - http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-session-fixation-attack.html [2] - http://developer.yahoo.net/blog/archives/2009/04/oauth_update.html On Apr 23, 2009, at 06:25 AM, mikehar wrote: Totally agree with Pierre. I think we all understand the security issue. Why was twitter's approach so much more severe than other services? Why not just a warning on login? Can Doug or Alex shed some light on this? wrt the ETA, can we get an update? One blog post said yesterday, the posting on this site says today. Also, I'm a little taken aback by the it's beta rationalization for the massive disruption in service. It's one thing to mark it as public beta, it's another thing entirely to define 'beta' belatedly as not suitable for production use. Does that mean we get an SLA on the non- beta APIs? On Apr 23, 1:44 am, twitscoop lollic...@gmail.com wrote: Hi guys, is there an ETA for it to be restored ? It seems Oauth's recommended approach is to simply add a warning notice on authorization until this is fixed (this is what Google did). Anyways, even with this security flow, oauth is safer than providing twitter credentials to third parties... Thanks! Pierre On Apr 23, 7:30 am, Doug Williams d...@twitter.com wrote: Bill, The majority of our developers find OAuth sufficient because they are writing a Web applications. We are pleased that the deprecation of the source parameter lowered our support load and continues to drive adoption of our preferred authentication scheme. There are of course other cases where developers find the current implementation's beta status or browser requirement concerning. I have yet to reject a source parameter request that provides a valid argument explaining why OAuth does not meet the application's needs. Thanks, Doug Williams Twitter API Supporthttp://twitter.com/dougw On Wed, Apr 22, 2009 at 6:50 PM, Bill Robertson billrobertso...@gmail.comwrote: I respectfully disagree. (I would colorfully disagree, but you seem pretty beat up right now and you don't deserve any guff) I think developers of smaller apps see that little tag-line as a good source of advertising, and it seems inaccessible now if you're new (right? wrong?). You can only get it if you use OAuth, but OAuth is now disabled? Anyway, just my $0.02. Prioritize it like everything else you need to do (i.e. it's the 37th #1 thing on your list.) Good luck. On Apr 22, 7:58 pm, Alex Payne a...@twitter.com wrote: We don't consider source registration a key feature. It's an incentive we provide to our developers. We wanted to encourage new developers to look into OAuth. It won't be in beta forever, after all. We have to balance the reality of testing a new technology in our stack with encouraging that technology's
[twitter-dev] Changes for April 23, 2009
Along with partial OAuth support restoration, the following API changes were shipped: - Fixed (REST): Basic authentication now works with passwords containing a colon. (http://code.google.com/p/twitter-api/issues/detail?id=496) - Fixed (REST): Error message during downtime now matches documented response. (http://code.google.com/p/twitter-api/issues/detail?id=300) - Deprecated (REST): Support for the oauth_callback parameter has been removed due to security vulnerability. (http://bit.ly/18gF5a) - Fixed (OAuth): OAuth images are properly served from through HTTPS. ( http://code.google.com/p/twitter-api/issues/detail?id=476) Thanks, Doug Williams Twitter API Support http://twitter.com/dougw
[twitter-dev] OAuth whitelisting?
I was just looking at the form use to apply for whitelisting, which says you must fill it out while logged in as the account you want the rate limit raised for. In my case, my app will be used by arbitrary Twitter account holders, who will not be using my credentials, so whitelisting my Twitter login will do nothing for my app. I saw Alex mention in another thread that whitelisting by OAuth will become the preferred method for whitelisting apps running in clouds (mine will be in EC2). I am assuming that OAuth whitelisting means I'll be able to whitelist my app, and the raised limit would apply for requests having OAuth access tokens obtained by my application, regardless of the Twitter user they belong to? Thanks, -Bill
[twitter-dev] oAuth is BACK!
Great work @al3x and the rest of the Twitter crew! My oAuth seems to be working once again: http://fast140.com/oauth/authorize
[twitter-dev] Re: oAuth is BACK!
However, the callback no longer contains the user info. Why did this change? You can get the user info by calling account/ verify_credentials.format. On Apr 23, 2:20 pm, @pud pkap...@gmail.com wrote: Great work @al3x and the rest of the Twitter crew! My oAuth seems to be working once again:http://fast140.com/oauth/authorize
[twitter-dev] Re: oAuth is BACK!
Hi there, I totally forgot about that change. Since the oauth callback is unsigned it was too easy to forge that data. I'm trying to find a good way to include it but right now calling verify_credentials is the best work around. Thanks; – Matt Sanford / @mzsanford Twitter API Developer On Apr 23, 2009, at 02:31 PM, mikehar wrote: However, the callback no longer contains the user info. Why did this change? You can get the user info by calling account/ verify_credentials.format. On Apr 23, 2:20 pm, @pud pkap...@gmail.com wrote: Great work @al3x and the rest of the Twitter crew! My oAuth seems to be working once again:http://fast140.com/oauth/authorize
[twitter-dev] Re: Callback url during development
Am 22.04.2009 um 15:37 schrieb Abraham Williams:
Also when you are building the authorize url to send users to
twitter.com you can add oauth_callback=http://localhost/callback;
and that will override your applications registered callback.
OAuth::Consumer.new(xx, xx,
{
:site=http://twitter.com/oauth/authorize?oauth_callback=http://localhost:3000/callback
})
I can see the site where I have to Deny or Allow access.
When I click Allow I will be redirected to the Domain which I
entered in the
OAUTH Clients Registration Form (http://www.twitter.com/oauth_cleints)
Seems that the oauth_callback parameter does not work!
Is it in the wrong place?
Any hints!?
Thanx
[twitter-dev] Re: Callback url during development
The oauth_callback parameter was just disabled do to security issues.
Currently only the registered callback works. If you need a different
callback location for development set up a second application.
On Thu, Apr 23, 2009 at 17:12, Jochen Kaechelin giss...@gissmog.de wrote:
Am 22.04.2009 um 15:37 schrieb Abraham Williams:
Also when you are building the authorize url to send users to
twitter.com you can add oauth_callback=http://localhost/callback;
and that will override your applications registered callback.
OAuth::Consumer.new(xx, xx,
{ :site=
http://twitter.com/oauth/authorize?oauth_callback=http://localhost:3000/callback
})
I can see the site where I have to Deny or Allow access.
When I click Allow I will be redirected to the Domain which I
entered in the
OAUTH Clients Registration Form (http://www.twitter.com/oauth_cleints)
Seems that the oauth_callback parameter does not work!
Is it in the wrong place?
Any hints!?
Thanx
--
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States
[twitter-dev] Re: Callback url during development
Am 24.04.2009 um 00:16 schrieb Abraham Williams:
The oauth_callback parameter was just disabled do to security
issues. Currently only the registered callback works. If you need a
different callback location for development set up a second
application.
Ok, then I have to use my dnydns address - I'am not allowed to
register a application
with http://localhost:3000/callback; as Callback url.
Thanx
On Thu, Apr 23, 2009 at 17:12, Jochen Kaechelin giss...@gissmog.de
wrote:
Am 22.04.2009 um 15:37 schrieb Abraham Williams:
Also when you are building the authorize url to send users to
twitter.com you can add oauth_callback=http://localhost/callback;
and that will override your applications registered callback.
OAuth::Consumer.new(xx, xx,
{
:site=http://twitter.com/oauth/authorize?oauth_callback=http://localhost:3000/callback
})
I can see the site where I have to Deny or Allow access.
When I click Allow I will be redirected to the Domain which I
entered in the
OAUTH Clients Registration Form (http://www.twitter.com/oauth_cleints)
Seems that the oauth_callback parameter does not work!
Is it in the wrong place?
Any hints!?
Thanx
--
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States
[twitter-dev] Re: Callback url during development
Hi,
During development I tend to modify my hosts file to point the
callback URL domain to my box for instance. This is quite good because
all it affects is my box.
Paul
On 23 Apr 2009, at 23:16, Abraham Williams 4bra...@gmail.com wrote:
The oauth_callback parameter was just disabled do to security
issues. Currently only the registered callback works. If you need a
different callback location for development set up a second
application.
On Thu, Apr 23, 2009 at 17:12, Jochen Kaechelin giss...@gissmog.de
wrote:
Am 22.04.2009 um 15:37 schrieb Abraham Williams:
Also when you are building the authorize url to send users to
twitter.com you can add oauth_callback=http://localhost/callback;
and that will override your applications registered callback.
OAuth::Consumer.new(xx, xx,
{
:site=http://twitter.com/oauth/authorize?oauth_callback=http://localhost:3000/callback
})
I can see the site where I have to Deny or Allow access.
When I click Allow I will be redirected to the Domain which I
entered in the
OAUTH Clients Registration Form (http://www.twitter.com/oauth_cleints)
Seems that the oauth_callback parameter does not work!
Is it in the wrong place?
Any hints!?
Thanx
--
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States
[twitter-dev] Re: oAuth is BACK!
Hi Nic, For the time being, yes. As I stated in the announcement I'm working on a method to allow oauth_callback's again. Thanks; – Matt Sanford / @mzsanford Twitter API Developer On Apr 23, 2009, at 03:19 PM, Dr Nic wrote: If we cannot run-time configure the callback URI then we'll need multiple application registrations for development + production? (assuming the need for absolute URIs) Cheers Nic On Apr 24, 7:38 am, Matt Sanford m...@twitter.com wrote: Hi there, I totally forgot about that change. Since the oauth callback is unsigned it was too easy to forge that data. I'm trying to find a good way to include it but right now calling verify_credentials is the best work around. Thanks; – Matt Sanford / @mzsanford Twitter API Developer On Apr 23, 2009, at 02:31 PM, mikehar wrote: However, the callback no longer contains the user info. Why did this change? You can get the user info by calling account/ verify_credentials.format. On Apr 23, 2:20 pm, @pud pkap...@gmail.com wrote: Great work @al3x and the rest of the Twitter crew! My oAuth seems to be working once again:http://fast140.com/oauth/authorize
[twitter-dev] Re: oAuth is BACK!
Nic, We are aware that the current lack of dynamic callback is limiting for development. In the meantime, we wanted to get OAuth support restored while we (and the OAuth consortium) develop a fix for this vulnerability. We intend to address this constraint in the near future. Thanks, Doug Williams Twitter API Support http://twitter.com/dougw On Thu, Apr 23, 2009 at 3:19 PM, Dr Nic dr...@mocra.com wrote: If we cannot run-time configure the callback URI then we'll need multiple application registrations for development + production? (assuming the need for absolute URIs) Cheers Nic On Apr 24, 7:38 am, Matt Sanford m...@twitter.com wrote: Hi there, I totally forgot about that change. Since the oauth callback is unsigned it was too easy to forge that data. I'm trying to find a good way to include it but right now calling verify_credentials is the best work around. Thanks; – Matt Sanford / @mzsanford Twitter API Developer On Apr 23, 2009, at 02:31 PM, mikehar wrote: However, the callback no longer contains the user info. Why did this change? You can get the user info by calling account/ verify_credentials.format. On Apr 23, 2:20 pm, @pud pkap...@gmail.com wrote: Great work @al3x and the rest of the Twitter crew! My oAuth seems to be working once again: http://fast140.com/oauth/authorize
[twitter-dev] Re: Twitter's official comment on our disabling of OAuth
On Fri, Apr 24, 2009 at 12:14 AM, djMax djm...@gmail.com wrote: What does this really mean these days? Clearly your desktop app is connected to the internet in some way at some point, Well, my *console*, *non-graphical* application is connected to the internet, yes. Also, if that makes it clear, think about a headless install. So are you just saying that you never want to have to display an HTML page? If Lynx can display, so can I. But remember that there is no copy'n'paste or anything of sorts in there. -- Julio Biason julio.bia...@gmail.com Twitter: http://twitter.com/juliobiason
[twitter-dev] Re: Callback url during development
Am 24.04.2009 um 00:29 schrieb Paul Kinlan:
Hi,
During development I tend to modify my hosts file to point the
callback URL domain to my box for instance. This is quite good
because all it affects is my box.
I just had the same idea ... ;-)
Works as expected now!!!
Thanx
Paul
On 23 Apr 2009, at 23:16, Abraham Williams 4bra...@gmail.com wrote:
The oauth_callback parameter was just disabled do to security
issues. Currently only the registered callback works. If you need a
different callback location for development set up a second
application.
On Thu, Apr 23, 2009 at 17:12, Jochen Kaechelin
giss...@gissmog.de wrote:
Am 22.04.2009 um 15:37 schrieb Abraham Williams:
Also when you are building the authorize url to send users to
twitter.com you can add oauth_callback=http://localhost/callback;
and that will override your applications registered callback.
OAuth::Consumer.new(xx, xx,
{
:site=http://twitter.com/oauth/authorize?oauth_callback=http://localhost:3000/callback
})
I can see the site where I have to Deny or Allow access.
When I click Allow I will be redirected to the Domain which I
entered in the
OAUTH Clients Registration Form (http://www.twitter.com/
oauth_cleints)
Seems that the oauth_callback parameter does not work!
Is it in the wrong place?
Any hints!?
Thanx
--
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States
[twitter-dev] Re: Callback url during development
This is something else that would be good for a development best practice
page on the apiwiki.
On Thu, Apr 23, 2009 at 17:47, Phil Nash philn...@gmail.com wrote:
That's a great idea, thanks for sharing! I was just wondering what to do
now that oauth_callback won't work.
Thanks!
Phil
--
Phil Nash
Web development: http://www.unintentionallyblank.co.uk
Musical stylings: http://www.hammervsthesnake.co.uk
Twitter: http://twitter.com/philnash
On Thu, Apr 23, 2009 at 11:29 PM, Paul Kinlan paul.kin...@gmail.comwrote:
Hi,
During development I tend to modify my hosts file to point the callback
URL domain to my box for instance. This is quite good because all it affects
is my box.
Paul
On 23 Apr 2009, at 23:16, Abraham Williams 4bra...@gmail.com wrote:
The oauth_callback parameter was just disabled do to security issues.
Currently only the registered callback works. If you need a different
callback location for development set up a second application.
On Thu, Apr 23, 2009 at 17:12, Jochen Kaechelin giss...@gissmog.de
giss...@gissmog.de wrote:
Am 22.04.2009 um 15:37 schrieb Abraham Williams:
Also when you are building the authorize url to send users to
twitter.com you can add oauth_callback= http://localhost/callback
http://localhost/callback;
and that will override your applications registered callback.
OAuth::Consumer.new(xx, xx,
{
:site=http://twitter.com/oauth/authorize?oauth_callback=http://localhost:3000/callback
http://twitter.com/oauth/authorize?oauth_callback=http://localhost:3000/callback
})
I can see the site where I have to Deny or Allow access.
When I click Allow I will be redirected to the Domain which I
entered in the
OAUTH Clients Registration Form ( http://www.twitter.com/oauth_cleints
http://www.twitter.com/oauth_cleints)
Seems that the oauth_callback parameter does not work!
Is it in the wrong place?
Any hints!?
Thanx
--
Abraham Williams | http://the.hackerconundrum.com
http://the.hackerconundrum.com
Hacker | http://abrah.amhttp://abrah.am | http://twitter.com/abraham
http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.orghttp://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States
--
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States
[twitter-dev] Re: oAuth is BACK!
I posted this yesterday, but the post appeared to vanish into the ether, during the OAuth 'outage' my dev version of Hahlo 4 (which uses OAuth) continued to work fine, is this because I was already logged in and the token was still valid? I'm guessing if I'd logged out/ unauthorized then I wouldn't have been able to log back in. Not that it matters now though, good work in getting things back up again so quickly :) Personally the missing user info in the callback is no big deal for me, as I'm calling verify_credentials to get the full profile anyway. (Took me quite a while to even notice it was being returned...) On Apr 24, 8:31 am, Doug Williams d...@twitter.com wrote: Nic, We are aware that the current lack of dynamic callback is limiting for development. In the meantime, we wanted to get OAuth support restored while we (and the OAuth consortium) develop a fix for this vulnerability. We intend to address this constraint in the near future. Thanks, Doug Williams Twitter API Supporthttp://twitter.com/dougw On Thu, Apr 23, 2009 at 3:19 PM, Dr Nic dr...@mocra.com wrote: If we cannot run-time configure the callback URI then we'll need multiple application registrations for development + production? (assuming the need for absolute URIs) Cheers Nic On Apr 24, 7:38 am, Matt Sanford m...@twitter.com wrote: Hi there, I totally forgot about that change. Since the oauth callback is unsigned it was too easy to forge that data. I'm trying to find a good way to include it but right now calling verify_credentials is the best work around. Thanks; – Matt Sanford / @mzsanford Twitter API Developer On Apr 23, 2009, at 02:31 PM, mikehar wrote: However, the callback no longer contains the user info. Why did this change? You can get the user info by calling account/ verify_credentials.format. On Apr 23, 2:20 pm, @pud pkap...@gmail.com wrote: Great work @al3x and the rest of the Twitter crew! My oAuth seems to be working once again: http://fast140.com/oauth/authorize
[twitter-dev] help with oauth status update utf8 issue
hello,
i've successfully managed to login to my webapp using twitter oauth
and updated my status on twitter.
problem is that it only works fine with english. when i tried updating
my twit with hebrew utf8 it posted the utf8 char as is on the profile
page.
http://twitter.com/Laylathedog/status/1599431655
for example.
$consumer_key = 'XXX';
$consumer_secret = 'XXX';
$twitterObj = new EpiTwitter($consumer_key, $consumer_secret, 'XXX',
'');
$userInfo = $twitterObj-get_accountVerify_credentials();
$followers = $twitterObj-post_statusesUpdate(array('status' =
$status));
return $followers-response;
this works fine. but updates the utf8 chars.
how can i fix that?
[twitter-dev] Follow Limit Issues today?
I'm seeing a lot of people that aren't even following 1,000 people run into limits where they can't follow any more today out of the blue. Is Twitter having issues with this right now? Thanks, @Jesse
[twitter-dev] Re: Follow Limit Issues today?
Just as additional info, I got it to happen to me, after not following anyone for the day, unfollowed and re-followed my wife's account from our socialtoo account a couple times to test some of our code, and now I'm getting the you are unable to follow more people at this time message. I know @ariherzog has also been having issues today without having followed many people. I've heard from several others as well, all using it legitimately. On Thu, Apr 23, 2009 at 7:31 PM, Jesse Stay jesses...@gmail.com wrote: I'm seeing a lot of people that aren't even following 1,000 people run into limits where they can't follow any more today out of the blue. Is Twitter having issues with this right now? Thanks, @Jesse
[twitter-dev] Re: Follow Limit Issues today?
Okay, you can ignore this - I know the problem now. Nothing like a thread talking to yourself. :-) (my ratio was off) On Thu, Apr 23, 2009 at 7:38 PM, Jesse Stay jesses...@gmail.com wrote: Just as additional info, I got it to happen to me, after not following anyone for the day, unfollowed and re-followed my wife's account from our socialtoo account a couple times to test some of our code, and now I'm getting the you are unable to follow more people at this time message. I know @ariherzog has also been having issues today without having followed many people. I've heard from several others as well, all using it legitimately. On Thu, Apr 23, 2009 at 7:31 PM, Jesse Stay jesses...@gmail.com wrote: I'm seeing a lot of people that aren't even following 1,000 people run into limits where they can't follow any more today out of the blue. Is Twitter having issues with this right now? Thanks, @Jesse
[twitter-dev] Re: Freelance Twitter API Dev directory?
Please add me to the list. Twitter ID: autodrool Name: Waitman Gobble Location: Los Altos, California Site: www.maximumheaddistortion.com Email: wait...@waitman.net Developing: www.tangytweets.com Pet projects and experimentation with possibly no commercial potential.
[twitter-dev] Re: What does following in user information do?
Still not working from the results I'm seeing. Has this issue been re- opened? On Apr 19, 9:07 pm, Dossy Shiobara do...@panoptic.com wrote: On 4/19/09 11:34 AM, Arnaud wrote: And thank you for the update. Unfortunately, it still doesn't seem to be fixed. I still receive a lot of incorrect followingvalues(INT and NULL instead of BOOL) using the statuses/followers method. +1 ... users/show method returning empty following/ node instead of boolean true/false. Can Matt re-open issue #157, or should we create a new issue to track this? -- Dossy Shiobara | do...@panoptic.com |http://dossy.org/ Panoptic Computer Network |http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
[twitter-dev] Re: What does following in user information do?
Please star Issue 419 [1] so you will be notified when the fix is shipped. 1. http://code.google.com/p/twitter-api/issues/detail?id=419 Doug Williams Twitter API Support http://twitter.com/dougw On Thu, Apr 23, 2009 at 8:11 PM, Carlos carlosju...@gmail.com wrote: Still not working from the results I'm seeing. Has this issue been re- opened? On Apr 19, 9:07 pm, Dossy Shiobara do...@panoptic.com wrote: On 4/19/09 11:34 AM, Arnaud wrote: And thank you for the update. Unfortunately, it still doesn't seem to be fixed. I still receive a lot of incorrect followingvalues(INT and NULL instead of BOOL) using the statuses/followers method. +1 ... users/show method returning empty following/ node instead of boolean true/false. Can Matt re-open issue #157, or should we create a new issue to track this? -- Dossy Shiobara | do...@panoptic.com |http://dossy.org/ Panoptic Computer Network |http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
[twitter-dev] Re: OAuth whitelisting?
Hi Bill, Whitelisting is done per IP, related to the number of requests by your server. -Peter On Thu, Apr 23, 2009 at 1:58 PM, Bill Kocik bko...@gmail.com wrote: I was just looking at the form use to apply for whitelisting, which says you must fill it out while logged in as the account you want the rate limit raised for. In my case, my app will be used by arbitrary Twitter account holders, who will not be using my credentials, so whitelisting my Twitter login will do nothing for my app. I saw Alex mention in another thread that whitelisting by OAuth will become the preferred method for whitelisting apps running in clouds (mine will be in EC2). I am assuming that OAuth whitelisting means I'll be able to whitelist my app, and the raised limit would apply for requests having OAuth access tokens obtained by my application, regardless of the Twitter user they belong to? Thanks, -Bill -- Peter M. Denton www.twibs.com i...@twibs.com Twibs makes Top 20 apps on Twitter - http://tinyurl.com/bopu6c
[twitter-dev] Re: OAuth whitelisting?
Whitelisting by OAuth is currently not available. You will need a static IP address if you are running an EC2 applicaiton. Doug Williams Twitter API Support http://twitter.com/dougw On Thu, Apr 23, 2009 at 8:35 PM, Peter Denton petermden...@gmail.comwrote: Hi Bill, Whitelisting is done per IP, related to the number of requests by your server. -Peter On Thu, Apr 23, 2009 at 1:58 PM, Bill Kocik bko...@gmail.com wrote: I was just looking at the form use to apply for whitelisting, which says you must fill it out while logged in as the account you want the rate limit raised for. In my case, my app will be used by arbitrary Twitter account holders, who will not be using my credentials, so whitelisting my Twitter login will do nothing for my app. I saw Alex mention in another thread that whitelisting by OAuth will become the preferred method for whitelisting apps running in clouds (mine will be in EC2). I am assuming that OAuth whitelisting means I'll be able to whitelist my app, and the raised limit would apply for requests having OAuth access tokens obtained by my application, regardless of the Twitter user they belong to? Thanks, -Bill -- Peter M. Denton www.twibs.com i...@twibs.com Twibs makes Top 20 apps on Twitter - http://tinyurl.com/bopu6c
[twitter-dev] Re: friends_timeline and following
I don't think this is fixed, at least based on responses I am seeing. If it was fixed then cache/cluster issues are delaying the results I am expecting. As to the value type, I am seeing following value of 0 instead of true/false.
[twitter-dev] Re: friends_timeline and following
This is still being worked on. Follow issue 419 for status updates. @dougw On 4/23/09, Don Park super...@gmail.com wrote: I don't think this is fixed, at least based on responses I am seeing. If it was fixed then cache/cluster issues are delaying the results I am expecting. As to the value type, I am seeing following value of 0 instead of true/false. -- Sent from my mobile device Doug Williams Twitter API Support http://twitter.com/dougw
[twitter-dev] Problems with Followers data
http://twitter.com/statuses/followers.json http://twitter.com/statuses/followers.xml The data in these two calls are drastically different. The json version seems to be missing quite a bit of information. Also I am developing in php for a site twitterworth.net . I grab the data in json format and use json_decode to get the information easily. Is there something that will output the xml data in the same format so I can just call that and not have to change my code?
