[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
BTW, I am using oauth Javascript client library( http://oauth.googlecode.com/svn/code/javascript/ ) to create signature. Wondering if it has a bug? On Jul 27, 10:53 pm, goodtest goodtest...@gmail.com wrote: btw, oauth_playground seems to be down as well. Also, I don't understand why create account which uses the same core method to create signature works but none of the other methods (friends_timeline, update statuses) dont work :( waiting for some hints On Jul 27, 9:40 pm, Doug Williams d...@twitter.com wrote: Please use the OAuth playground [1] to test your signatures against the expected result. I am working to gather specifics to help your debug process (i.e. what changed?) in the mean time. 1.http://googlecodesamples.com/oauth_playground/ Thanks, Doug On Mon, Jul 27, 2009 at 9:29 PM, winrich winric...@gmail.com wrote: ok guys. so my calls were failing on the verify_credentials call and not on the update or timeline calls. the only difference i saw was the the verify_credential call wasn't secured. i changed it to https and it worked. ??? lol On Jul 27, 9:19 pm, Chad Etzel jazzyc...@gmail.com wrote: On Mon, Jul 27, 2009 at 11:55 PM, Duane Roelandsduane.roela...@gmail.com wrote: RTFM is not a helpful answer, especially when many developers are relying on libraries that they did not write. That's a risk you run when using code you didn't write. I'm not saying that this situation doesn't suck for those affected. I'm sure that it does. But, for a technology so new as OAuth, the libraries may not be mature yet. Officially, Twitter OAuth is still in Public Beta and has never been officially recommended to integrate into production code. That being said, there could still be a problem on Twitter's end with their signature verification mechanism and the libraries could all be valid. I don't have a way of knowing. I do agree that at least a note that a security change was pushed today would be nice, though. -Chad
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
I dont think it has any bug (i have not verified this fix yet). I think the fix is actually for this problem http://groups.google.com/group/twitter-development-talk/browse_thread/thread/a195ea9b9952e297/9f4b9249f9ff96be?lnk=gstq=consumer+secret#9f4b9249f9ff96be Need to verify that the parameters are signed by both consumer secret and access secret. On Tue, Jul 28, 2009 at 11:44 AM, goodtest goodtest...@gmail.com wrote: BTW, I am using oauth Javascript client library( http://oauth.googlecode.com/svn/code/javascript/ ) to create signature. Wondering if it has a bug? On Jul 27, 10:53 pm, goodtest goodtest...@gmail.com wrote: btw, oauth_playground seems to be down as well. Also, I don't understand why create account which uses the same core method to create signature works but none of the other methods (friends_timeline, update statuses) dont work :( waiting for some hints On Jul 27, 9:40 pm, Doug Williams d...@twitter.com wrote: Please use the OAuth playground [1] to test your signatures against the expected result. I am working to gather specifics to help your debug process (i.e. what changed?) in the mean time. 1.http://googlecodesamples.com/oauth_playground/ Thanks, Doug On Mon, Jul 27, 2009 at 9:29 PM, winrich winric...@gmail.com wrote: ok guys. so my calls were failing on the verify_credentials call and not on the update or timeline calls. the only difference i saw was the the verify_credential call wasn't secured. i changed it to https and it worked. ??? lol On Jul 27, 9:19 pm, Chad Etzel jazzyc...@gmail.com wrote: On Mon, Jul 27, 2009 at 11:55 PM, Duane Roelandsduane.roela...@gmail.com wrote: RTFM is not a helpful answer, especially when many developers are relying on libraries that they did not write. That's a risk you run when using code you didn't write. I'm not saying that this situation doesn't suck for those affected. I'm sure that it does. But, for a technology so new as OAuth, the libraries may not be mature yet. Officially, Twitter OAuth is still in Public Beta and has never been officially recommended to integrate into production code. That being said, there could still be a problem on Twitter's end with their signature verification mechanism and the libraries could all be valid. I don't have a way of knowing. I do agree that at least a note that a security change was pushed today would be nice, though. -Chad
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
I have found the problem in the Perl library I am using.
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
I have found the problem in the library I am using: First, a Twitter request object is created. Second, a signature is generated. Third, params are then added to the request object. This addition of the params after the signing invalidates the signature. All params need to be added before signing. Unfortunately this appears to require quite a bit of rework.
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
Need to verify that the parameters are signed by both consumer secret and
access secret.
I am doing that already. For example, when I call
http://twitter.com/statuses/friends_timeline.json, I pass
consumerSecret, tokenSecret...
Using the JS library, it looks like this to get the signature:
var accessor = { consumerSecret: this.consumerSecret
, tokenSecret : token_secret};
var message = { method: GET
, action: http://twitter.com/statuses/friends_timeline.json;
, parameters: new Array()
};
message.parameters.push([oauth_consumer_key,this.consumerKey]);
message.parameters.push([oauth_version,1.0]);
message.parameters.push([oauth_timestamp, OAuth.timestamp()]);
message.parameters.push([oauth_nonce, OAuth.nonce(11)]);
message.parameters.push([oauth_signature_method, HMAC-SHA1]);
message.parameters.push([oauth_token, auth_token]);
OAuth.SignatureMethod.sign(message, accessor);
var signature = OAuth.getParameter(message.parameters,
oauth_signature);
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
@goodtest
Hi Post methods (that require auth) seem to be working fine.
I am stuck with GET (problem with parametrs). checking whether the problem
is incorrect usage of library or the problem with library.
will let u know
On Tue, Jul 28, 2009 at 12:25 PM, goodtest goodtest...@gmail.com wrote:
Need to verify that the parameters are signed by both consumer secret and
access secret.
I am doing that already. For example, when I call
http://twitter.com/statuses/friends_timeline.json, I pass
consumerSecret, tokenSecret...
Using the JS library, it looks like this to get the signature:
var accessor = { consumerSecret: this.consumerSecret
, tokenSecret : token_secret};
var message = { method: GET
, action:
http://twitter.com/statuses/friends_timeline.json;
, parameters: new Array()
};
message.parameters.push([oauth_consumer_key,this.consumerKey]);
message.parameters.push([oauth_version,1.0]);
message.parameters.push([oauth_timestamp, OAuth.timestamp()]);
message.parameters.push([oauth_nonce, OAuth.nonce(11)]);
message.parameters.push([oauth_signature_method, HMAC-SHA1]);
message.parameters.push([oauth_token, auth_token]);
OAuth.SignatureMethod.sign(message, accessor);
var signature = OAuth.getParameter(message.parameters,
oauth_signature);
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
Hi
After getting the access tokens i used the sample echo.html provided by JS
library
Both GET and POST (that require auth and with parameters) are working fine.
We just need to follow the same code
On Tue, Jul 28, 2009 at 12:54 PM, srikanth reddy srikanth.yara...@gmail.com
wrote:
@goodtest
Hi Post methods (that require auth) seem to be working fine.
I am stuck with GET (problem with parametrs). checking whether the problem
is incorrect usage of library or the problem with library.
will let u know
On Tue, Jul 28, 2009 at 12:25 PM, goodtest goodtest...@gmail.com wrote:
Need to verify that the parameters are signed by both consumer secret and
access secret.
I am doing that already. For example, when I call
http://twitter.com/statuses/friends_timeline.json, I pass
consumerSecret, tokenSecret...
Using the JS library, it looks like this to get the signature:
var accessor = { consumerSecret: this.consumerSecret
, tokenSecret : token_secret};
var message = { method: GET
, action:
http://twitter.com/statuses/friends_timeline.json;
, parameters: new Array()
};
message.parameters.push([oauth_consumer_key,this.consumerKey]);
message.parameters.push([oauth_version,1.0]);
message.parameters.push([oauth_timestamp, OAuth.timestamp()]);
message.parameters.push([oauth_nonce, OAuth.nonce(11)]);
message.parameters.push([oauth_signature_method, HMAC-SHA1]);
message.parameters.push([oauth_token, auth_token]);
OAuth.SignatureMethod.sign(message, accessor);
var signature = OAuth.getParameter(message.parameters,
oauth_signature);
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
my problems are opposite (using some php scripts) verification is ok, tweeting ok, but verified timelines (friends and mentions) not ok. On Jul 27, 9:29 pm, winrich winric...@gmail.com wrote: ok guys. so my calls were failing on the verify_credentials call and not on the update or timeline calls. the only difference i saw was the the verify_credential call wasn't secured. i changed it to https and it worked. ??? lol On Jul 27, 9:19 pm, Chad Etzel jazzyc...@gmail.com wrote: On Mon, Jul 27, 2009 at 11:55 PM, Duane Roelandsduane.roela...@gmail.com wrote: RTFM is not a helpful answer, especially when many developers are relying on libraries that they did not write. That's a risk you run when using code you didn't write. I'm not saying that this situation doesn't suck for those affected. I'm sure that it does. But, for a technology so new as OAuth, the libraries may not be mature yet. Officially, Twitter OAuth is still in Public Beta and has never been officially recommended to integrate into production code. That being said, there could still be a problem on Twitter's end with their signature verification mechanism and the libraries could all be valid. I don't have a way of knowing. I do agree that at least a note that a security change was pushed today would be nice, though. -Chad
[twitter-dev] Lesson of the day: Basic Auth is better than OAuth.
OAuth is just not ready for primetime on Twitter. I have used Google Optimizer to test user response to OAuth versus Basic Auth, and users are far more likely to give Basic Auth details rather than cumbersome and weird (from the user's perspective) OAuth. From the user's perspective, OAuth appears more invasive than Basic. Besides that, OAuth just has not worked well on Twitter... first the outage several weeks ago for several days of OAuth, and now this recent unannounced change! Ugh! Deprecating OAuth... going full-bore Basic Auth.
[twitter-dev] Lesson of the day: Basic Auth is more reliable/better received than OAuth.
Do you use Google Optimizer? If not, go there. Setup a test to compare sign-ups to your app between OAuth and Basic Auth. Give 50% the option to sign up with OAuth; 50% the option to sign up with Basic Auth. The results may surprise you. In my tests, I have found statistically significant more signups from Basic Auth than from OAuth. But maybe that's not so surprising. Users are accustomed to giving username/password information, even to foreign apps. They are far LESS accustomed to going to Twitter and hitting some bizarre approve button. To them, that's far more invasive and often more cumbersome (they may have to relogin to Twitter) than simply having to retype their Twitter username/password. The net result from using OAuth for third-party developers is fewer sign-ups than from using Basic Auth. Plus, as recent unannounced changes by Twitter have indicated, Basic Auth is far more reliable. (I am talking about the several day outage of OAuth a few weeks ago; and today's unannounced API change to OAuth which breaks multiple Twitter interface libraries.) SO... user response, Twitter unresponsiveness (when it comes to unannounced API changes), and other factors are prompting me into the weird position of deprecating OAuth and promoting Basic Authentication. Weird, eh!?
[twitter-dev] Re: Lesson of the day: Basic Auth is more reliable/better received than OAuth.
(I should mention that this post was made at 3am after handling errors due to surprise, surprise Twitter API changes to OAuth made at ~5pm (some kind of joke to checkin changes at end of workday??)... and that's after a 8am workday start. And that's after last week's limit to verify_credentials right before a holiday weekend. Totally fed-up with these Twitter unannounced changes!)
[twitter-dev] Re: streaming API for DM for multiple users ?
I'd support the creation of such a method. My latest focus is receiving orders/commands through DM and having a hose would give us a much snappier response than polling every 30 secs. On Jul 27, 8:55 pm, Doug Williams d...@twitter.com wrote: There is currently no Streaming API to receive DMs for a given user. If you have a great use case for this please share it here. We like to have justification for new streaming methods. If you have ideas to help augment a business case for engineering resources, we would love to know about them. Thanks, Doug On Mon, Jul 27, 2009 at 5:24 AM, Fabien Penso fabienpe...@gmail.com wrote: Hi. I wonder if there is a way to use the streaming API to receive DM for a list of specific users. As far as I understand there isn't, is anyone working on this? Basicly I want to offer the possibility to receive Apple Push Notifications and I'll get tons of user, so I want to go the efficient way. Thanks.
[twitter-dev] Re: streaming API for DM for multiple users ?
Random idea, but wouldn't a streaming API for DMs allow IM style clients to be implemented on top of the twitter platform? I know I use DMs instead of MSN now, the delay is a bit of a pain but being able to move the conversation from public to private is great, plus sometimes you do want delayed IM conversations (for example, when travelling) ;) Thanks, @Ben_Hall On Tue, Jul 28, 2009 at 2:55 AM, Doug Williamsd...@twitter.com wrote: There is currently no Streaming API to receive DMs for a given user. If you have a great use case for this please share it here. We like to have justification for new streaming methods. If you have ideas to help augment a business case for engineering resources, we would love to know about them. Thanks, Doug On Mon, Jul 27, 2009 at 5:24 AM, Fabien Penso fabienpe...@gmail.com wrote: Hi. I wonder if there is a way to use the streaming API to receive DM for a list of specific users. As far as I understand there isn't, is anyone working on this? Basicly I want to offer the possibility to receive Apple Push Notifications and I'll get tons of user, so I want to go the efficient way. Thanks.
[twitter-dev] Re: What's the difference between 'statuses/replies' and 'statuses/mentions' ?
Thank you Doug. :) On Tue, Jul 28, 2009 at 9:56 AM, Doug Williams d...@twitter.com wrote: statuses/replies is an alias for statues/mentions. It is completely due to history where mentions used to be called replies. Rather than break apps that relied on statuses/replies, we made an alias to ensure backward compatibility. Thanks, Doug On Sun, Jul 26, 2009 at 9:23 AM, Kuo Yang daras...@gmail.com wrote: I have read some code about twitter-api and I found the code for replies(or mentions?) as: http://twitter.com/statuses/replies.*format *but on apiwiki.twittwer.com it is: http://twitter.com/statuses/mentions.*format* So,what's the difference between them? Is that alais?
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
How about letting us know what the changes were...? Apparently I am one of the developers not correctly submitting signatures. I developed my code based on samples in your wiki, and have no clue what is broken with my authentication code (which has been working perfectly for some time.) On Jul 27, 7:59 pm, Doug Williams d...@twitter.com wrote: As stated above, some applications were sending invalid signatures which we were accepting as valid. This vulnerability was pointed out by a developer. Some libraries and code which may have previously worked may be broken by this security fix. Thanks, Doug On Mon, Jul 27, 2009 at 7:44 PM, Duane Roelands duane.roela...@gmail.comwrote: I am receiving 401 (Unauthorized) when calling http://twitter.com/statuses/update.xml and passing the following querystring: oauth_consumer_key=[removed] oauth_nonce=912352oauth_signature_method=HMAC- SHA1oauth_timestamp=1248748647oauth_token=19068738- hKO8qRlHPfJWqRHRkd62dGb4IiyXaXUy35Cqz58oauth_version=1.0status=This +is+a+testoauth_signature=Fl0kqJdHY5MkvxjUZQ%2bFn%2fxGORo%3d This code was working this afternoon and has not been changed. On Jul 27, 10:38 pm, goodtest goodtest...@gmail.com wrote: Are we sure there is no further regression bug in this new fix? On Jul 27, 7:14 pm, Doug Williams d...@twitter.com wrote: If you are still seeing errors you should check your code to ensure that you are sending the correct signature. Thanks, Doug On Mon, Jul 27, 2009 at 7:10 PM, winrich winric...@gmail.com wrote: mine broke too. i wonder though, i'm using the oauth python libraries On Jul 27, 6:35 pm, chinaski007 chinaski...@gmail.com wrote: Doug: Does this mean that Marcel made a fix for this? Or rather that we should examine our code to find the culprit? Thanks, Peter Bray On Jul 27, 6:24 pm, Doug Williams d...@twitter.com wrote: Updating you guys on this problem. A bug was reported off list that informed us we were not always verifying signatures. Today we shipped a fix for this problem which ensures that we are correctly verifying signatures. If you are still seeing invalid signature errors you should examine your code and ensure you are correctly signing requests as per the spec. Thanks, Doug On Mon, Jul 27, 2009 at 6:05 PM, Doug Williams d...@twitter.com wrote: Marcel is shipping a fix for this as I type. Thanks, Doug 2009/7/27 João Pereira joaomiguel.pere...@gmail.com Same here. On Tue, Jul 28, 2009 at 1:26 AM, goodtest goodtest...@gmail.com wrote: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
Inadequate notification of this issue has just wasted a full day of my time. I'm guessing you're not releasing details to protect the other OAuth service providers. Did you think that this is at the same time damaging consumers? At least give notification of fixes once you've 'fixed' them even if you decide not to release warning in advance. You have acted irresponsibly towards your developer community yet again, as the sentiments in the other comments make clear. Tim On Jul 28, 3:35 pm, Chad Etzel jazzyc...@gmail.com wrote: I would start by looking at the OAuth spec at Section 9 - Signing Process. http://oauth.net/core/1.0a#signing_process In fact, if you (meaning everyone) have never read the whole spec, you need to. -Chad On Mon, Jul 27, 2009 at 11:31 PM, goodtestgoodtest...@gmail.com wrote: Yeah, I agree, can you please point out what (in general) we might be doing wrong? I still think you probably have a further-regression bug.
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
No doubt. This is super frustrating. On Jul 27, 8:19 pm, kosso kos...@gmail.com wrote: agreed. please Twitter, tell us WHAT the fix required was. what should we look for. have you tested your 'fix' against all the code examples you link from the API pages? that would be nice. thx. I'm getting some posts through. some not. so something's still up/down On Jul 27, 8:04 pm, Duane Roelands duane.roela...@gmail.com wrote: You introduced a breaking change into the API with no warning and no help for developers as to the specifics of what we need to fix? Developers need better support than that. Is there some reason why posting updates to some accounts would work and posting to others would not? Using the same code, I'm able to post to my development test account but not to my personal account. On Jul 27, 10:59 pm, Doug Williams d...@twitter.com wrote: As stated above, some applications were sending invalid signatures which we were accepting as valid. This vulnerability was pointed out by a developer. Some libraries and code which may have previously worked may be broken by this security fix. Thanks, Doug On Mon, Jul 27, 2009 at 7:44 PM, Duane Roelands duane.roela...@gmail.comwrote: I am receiving 401 (Unauthorized) when calling http://twitter.com/statuses/update.xml and passing the following querystring: oauth_consumer_key=[removed] oauth_nonce=912352oauth_signature_method=HMAC- SHA1oauth_timestamp=1248748647oauth_token=19068738- hKO8qRlHPfJWqRHRkd62dGb4IiyXaXUy35Cqz58oauth_version=1.0status=This +is+a+testoauth_signature=Fl0kqJdHY5MkvxjUZQ%2bFn%2fxGORo%3d This code was working this afternoon and has not been changed. On Jul 27, 10:38 pm, goodtest goodtest...@gmail.com wrote: Are we sure there is no further regression bug in this new fix? On Jul 27, 7:14 pm, Doug Williams d...@twitter.com wrote: If you are still seeing errors you should check your code to ensure that you are sending the correct signature. Thanks, Doug On Mon, Jul 27, 2009 at 7:10 PM, winrich winric...@gmail.com wrote: mine broke too. i wonder though, i'm using the oauth python libraries On Jul 27, 6:35 pm, chinaski007 chinaski...@gmail.com wrote: Doug: Does this mean that Marcel made a fix for this? Or rather that we should examine our code to find the culprit? Thanks, Peter Bray On Jul 27, 6:24 pm, Doug Williams d...@twitter.com wrote: Updating you guys on this problem. A bug was reported off list that informed us we were not always verifying signatures. Today we shipped a fix for this problem which ensures that we are correctly verifying signatures. If you are still seeing invalid signature errors you should examine your code and ensure you are correctly signing requests as per the spec. Thanks, Doug On Mon, Jul 27, 2009 at 6:05 PM, Doug Williams d...@twitter.com wrote: Marcel is shipping a fix for this as I type. Thanks, Doug 2009/7/27 João Pereira joaomiguel.pere...@gmail.com Same here. On Tue, Jul 28, 2009 at 1:26 AM, goodtest goodtest...@gmail.com wrote: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
I can confirm that Perl's Net::OAuth 0.9-1 is working with this. I had other issues (was half way through implementing an interface when this changed - threw me way off track) but the library should work unchanged. I was having trouble with the inital request token retrieval. Users of this library should make sure to set the token and token secret to for this part of the process. Cheers, Tim On Tue, Jul 28, 2009 at 5:53 PM, goodtest goodtest...@gmail.com wrote: btw, oauth_playground seems to be down as well. Also, I don't understand why create account which uses the same core method to create signature works but none of the other methods (friends_timeline, update statuses) dont work :( waiting for some hints On Jul 27, 9:40 pm, Doug Williams d...@twitter.com wrote: Please use the OAuth playground [1] to test your signatures against the expected result. I am working to gather specifics to help your debug process (i.e. what changed?) in the mean time. 1.http://googlecodesamples.com/oauth_playground/ Thanks, Doug On Mon, Jul 27, 2009 at 9:29 PM, winrich winric...@gmail.com wrote: ok guys. so my calls were failing on the verify_credentials call and not on the update or timeline calls. the only difference i saw was the the verify_credential call wasn't secured. i changed it to https and it worked. ??? lol On Jul 27, 9:19 pm, Chad Etzel jazzyc...@gmail.com wrote: On Mon, Jul 27, 2009 at 11:55 PM, Duane Roelandsduane.roela...@gmail.com wrote: RTFM is not a helpful answer, especially when many developers are relying on libraries that they did not write. That's a risk you run when using code you didn't write. I'm not saying that this situation doesn't suck for those affected. I'm sure that it does. But, for a technology so new as OAuth, the libraries may not be mature yet. Officially, Twitter OAuth is still in Public Beta and has never been officially recommended to integrate into production code. That being said, there could still be a problem on Twitter's end with their signature verification mechanism and the libraries could all be valid. I don't have a way of knowing. I do agree that at least a note that a security change was pushed today would be nice, though. -Chad -- a href=http://www.spreadfirefox.com/?q=affiliatesamp;id=81126amp;t=82;img border=0 alt=Get Firefox! title=Get Firefox! src= http://sfx-images.mozilla.org/affiliates/Buttons/80x15/white_1.gif//a
[twitter-dev] Re: updating follow/shadow/birddog list of users
John, Thanks for the quick reply! The /shadow + /follow solution should work great! I was considering that, but was worried about opening two streams from the same IP + reconnecting every few minutes. If that indeed is acceptable usage of the streaming API, then I'm good. Thanks for your help! -nick On Jul 27, 8:03 pm, John Kalucki jkalu...@gmail.com wrote: The feature to update streaming api filter predicates has been put on hold for now. It is still desired, but not in the active development plan. You can backfill with the REST API, as you suggest. Or, you could reconnect every few minutes on the Streaming API. It might be best to have two streaming API accounts -- a /shadow stream that is long-lived and /follow stream that you reconnect with every few minutes when a new user is added. You can migrate accounts from the /follow stream to the /track stream once an hour or so. If the /follow stream runs afoul of a rate limit, at least the /shadow stream is still connected. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. On Jul 27, 7:18 pm, nickdella nick.dellamaggi...@gmail.com wrote: Hi, I'm working on a similar system in which members on my site dynamically subscribe to Twitter. Thus, my following list is constantly changing. To provide a reasonable user experience, I'd have to disconnect/reconnect every couple minutes to ensure their subscription is recognized in a timely manner :/ I understand that the constant disconnect/reconnect cycle is suboptimal for you guys. So, I have a fallback plan of concurrently using both the streaming API for existing subscribers while using the REST API to temporarily poll for status updates for all new subscribers. Every hour or so, I'd merge these new subscribers into the main followers list and reconnect the stream. This is possible, but would definitely be some extra work to build. Alex described the possible addition of a REST API to dynamically update the followers list. Is there any chance this is coming in the near future i.e. next 3 weeks? :) Or do you guys have any other ideas on how I'd go about solving this given the current set of APIs? Thanks! -nick On Jul 8, 4:28 pm, John Kalucki jkalu...@gmail.com wrote: Alexy, First, curl isn't the best approach for developing against theStreamingAPI. It's fine for prototyping, but it only goes so far. Yes, the comma separated list should be all on one line if you are using curl. If you want to change the user set, you should connect with the new set and then disconnect the old set immediately once the data starts to flow. This will be hard to coordinate using curl. In some cases, Twitter will throw the first user off once the second user connects. In other cases it will be more lenient. But, beware: if you want to avoid running into various abuse limits, you'd best be sure that your coordination between the first and second streams are quite solid and that the first stream is always terminated in a timely manner. You can also avoid data loss by using the count parameter, available on some, but not all, methods. Please email me with your use case and I'll forward it on to the Platform PM to help prioritize the better solution, as outlined by Alex. -John Kalucki twitter.com/jkalucki Services, Twitter Inc. On Jul 8, 12:17 pm, braver delivera...@gmail.com wrote: Uf you have thousands of users, do you really have to cook up a following file with comma-separated say 100,000 user IDs? Should it all be on one line? Now what happens if we want to drop some and add some IDs -- do we have to restart and re-upload all that list again? I see when the curl -d @following ... starts up, it does that. Restarting with huge lists sounds like data loss... Cheers, Alexy
[twitter-dev] API / oAuth Help Request for: statuses/update.xml
I'm learning oAuth and was finally able to get the Access Token Token Secret for a Twitter account. Now that I believe oAuth is working and I have a Access Token, I'm trying to use the API to update my status. but continue to get the following error: Could not authenticate you Can someone please tell me what is wrong with my request below? thanks request_url : http://twitter.com/statuses/update.xml?OAUTH_TOKEN=24247343%252DXOjRCmuLnknAVn7TwtRCHAbkU8tjjlpXSpQbDEVrUOAUTH_TOKEN_SECRET=Hy16kBAPnCJCAGavAUpUpTaLCbCsUal3avXo99ZcUMSTATUS=f%20o%20o%20b_a_roauth_consumer_key=LyPt1AOcF6BWULWW5CIM0goauth_nonce=558F8C8D259352990608DEF3DE3AAE9C51D58905oauth_signature=TSybsEtDIhEzQfgbO6KAA7HYmJE%3Doauth_signature_method=HMAC-SHA1oauth_timestamp=1248759687oauth_version=1.0oauth_version=1.0
[twitter-dev] API / oAuth Help Request for: statuses/update.xml
I'm learning oAuth and was finally able to get the Access Token Token Secret for a Twitter account. Now that I believe oAuth is working and I have a Access Token, I'm trying to use the API to update my status. but continue to get the following error: Could not authenticate you Can someone please tell me what is wrong with my request below? thanks request_url : http://twitter.com/statuses/update.xml?OAUTH_TOKEN=24247343%252DXOjRCmuLnknAVn7TwtRCHAbkU8tjjlpXSpQbDEVrUOAUTH_TOKEN_SECRET=Hy16kBAPnCJCAGavAUpUpTaLCbCsUal3avXo99ZcUMSTATUS=f%20o%20o%20b_a_roauth_consumer_key=LyPt1AOcF6BWULWW5CIM0goauth_nonce=558F8C8D259352990608DEF3DE3AAE9C51D58905oauth_signature=TSybsEtDIhEzQfgbO6KAA7HYmJE%3Doauth_signature_method=HMAC-SHA1oauth_timestamp=1248759687oauth_version=1.0oauth_version=1.0
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
Mine were all to do with urlencoding, and ensuring all post data is sent as post data, and none on the querystring for the URL; and thus ensuring I use the modified URLencoding method required for Oauth - which was previously being used, but not on the post data! Once I did that, that test updates with all sorts of characters now succeed every time... including spacesetc etc Seems good now... hope it stays that way! Good luck to you guys! On Jul 27, 10:46 pm, Duane Roelands duane.roela...@gmail.com wrote: From my experimenting, it appears that posting a tweet is successful if the text contains no spaces. Once you have a space in the tweet, it fails. Researching... On Jul 28, 12:29 am, winrich winric...@gmail.com wrote: ok guys. so my calls were failing on the verify_credentials call and not on the update or timeline calls. the only difference i saw was the the verify_credential call wasn't secured. i changed it to https and it worked. ??? lol On Jul 27, 9:19 pm, Chad Etzel jazzyc...@gmail.com wrote: On Mon, Jul 27, 2009 at 11:55 PM, Duane Roelandsduane.roela...@gmail.com wrote: RTFM is not a helpful answer, especially when many developers are relying on libraries that they did not write. That's a risk you run when using code you didn't write. I'm not saying that this situation doesn't suck for those affected. I'm sure that it does. But, for a technology so new as OAuth, the libraries may not be mature yet. Officially, Twitter OAuth is still in Public Beta and has never been officially recommended to integrate into production code. That being said, there could still be a problem on Twitter's end with their signature verification mechanism and the libraries could all be valid. I don't have a way of knowing. I do agree that at least a note that a security change was pushed today would be nice, though. -Chad
[twitter-dev] Re: Twitter: What did you change in OAuth?
I'm Using , Using http://oauth.googlecode.com/svn/code/csharp/ And it fails :( any thoughts on what might help? On Jul 28, 6:23 am, chinaski007 chinaski...@gmail.com wrote: Confirmed. Google Playground does not work.
[twitter-dev] Re: streaming API for DM for multiple users ?
On Tue, Jul 28, 2009 at 3:55 AM, Doug Williamsd...@twitter.com wrote: There is currently no Streaming API to receive DMs for a given user. If you have a great use case for this please share it here. We like to have justification for new streaming methods. If you have ideas to help augment a business case for engineering resources, we would love to know about them. Hi Doug, I want to be able to offer push notifications on iPhone for public replies (that is done with the streaming API, as you can see on http://www.twitvid.com/A4E43 ). I would also like to offer it for DM. You do send a mail but a push is way faster than emails. Basicly if you had push for DM you could really replace text messages with twitter. Is that a good justification? Can I help in any ways?
[twitter-dev] Re: Twitter: What did you change in OAuth?
It's quite funny I suppose, been using basic auth forever, last week change over to OAuth...today, concidering going back, give a couple of years to iron out the bugs and maybe try again. I'm using Abraham Williams' PHP twitter OAuth library, I don't suppose anyone has found a fix for this? getting simply 'Invalid signature' is about as helpful as an unknown error occurred Cheers. On Jul 28, 6:23 am, chinaski007 chinaski...@gmail.com wrote: Confirmed. Google Playground does not work.
[twitter-dev] Re: Lesson of the day: Basic Auth is more reliable/better received than OAuth.
(Then again, given that this was a Twitter security flaw, I guess I can kind of understand how they favored not to pre-announce this fix. That said, some consideration to developers would have been appreciated.)
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
Hi i think now both access secret and consumer secret are required. i verified this by giving blank consumer secret and valid access secret and i got invalid signature error. It works fine when i give correct values for both. Looks like there is no way you can protect your consumer secret On Tue, Jul 28, 2009 at 2:59 PM, thetago...@googlemail.com anto...@cloudangels.com wrote: @Doug - Can you confirm that it is now MANDATORY to supply both access token and access secret as well as the consumer key and consumer secret to generate a valid signature? OAuth spec states in #4 that consumer secret may be empty if no consumer verification is neeeded. --[excerpt from spec]-- Service Providers SHOULD NOT rely on the Consumer Secret as a method to verify the Consumer identity, unless the Consumer Secret is known to be inaccessible to anyone other than the Consumer and the Service Provider. The Consumer Secret MAY be an empty string (for example when no Consumer verification is needed, or when verification is achieved through other means such as RSA). --[end excerpt from spec]-- This would mean that you'd have to ship the customer secret to the client with each deliverable you publish, regardless of whether you want to do client verification or consumer (i.e. Server) verfication. best regards, Toni On 28 Jul., 10:56, kosso kos...@gmail.com wrote: my problems are opposite (using some php scripts) verification is ok, tweeting ok, but verified timelines (friends and mentions) not ok. On Jul 27, 9:29 pm, winrich winric...@gmail.com wrote: ok guys. so my calls were failing on the verify_credentials call and not on the update or timeline calls. the only difference i saw was the the verify_credential call wasn't secured. i changed it to https and it worked. ??? lol On Jul 27, 9:19 pm, Chad Etzel jazzyc...@gmail.com wrote: On Mon, Jul 27, 2009 at 11:55 PM, Duane Roelandsduane.roela...@gmail.com wrote: RTFM is not a helpful answer, especially when many developers are relying on libraries that they did not write. That's a risk you run when using code you didn't write. I'm not saying that this situation doesn't suck for those affected. I'm sure that it does. But, for a technology so new as OAuth, the libraries may not be mature yet. Officially, Twitter OAuth is still in Public Beta and has never been officially recommended to integrate into production code. That being said, there could still be a problem on Twitter's end with their signature verification mechanism and the libraries could all be valid. I don't have a way of knowing. I do agree that at least a note that a security change was pushed today would be nice, though. -Chad
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
I'm also frustrated. I can't have a consistent behaviour from twitter API. Now works fine then give invalid signature for all users, then works again, can't understand g Moreover, for the same user, using the same code for authentication, some call works and others don't. When will you guys at twitter get this back working? On Tue, Jul 28, 2009 at 11:53 AM, srikanth reddy srikanth.yara...@gmail.com wrote: Hi i think now both access secret and consumer secret are required. i verified this by giving blank consumer secret and valid access secret and i got invalid signature error. It works fine when i give correct values for both. Looks like there is no way you can protect your consumer secret On Tue, Jul 28, 2009 at 2:59 PM, thetago...@googlemail.com anto...@cloudangels.com wrote: @Doug - Can you confirm that it is now MANDATORY to supply both access token and access secret as well as the consumer key and consumer secret to generate a valid signature? OAuth spec states in #4 that consumer secret may be empty if no consumer verification is neeeded. --[excerpt from spec]-- Service Providers SHOULD NOT rely on the Consumer Secret as a method to verify the Consumer identity, unless the Consumer Secret is known to be inaccessible to anyone other than the Consumer and the Service Provider. The Consumer Secret MAY be an empty string (for example when no Consumer verification is needed, or when verification is achieved through other means such as RSA). --[end excerpt from spec]-- This would mean that you'd have to ship the customer secret to the client with each deliverable you publish, regardless of whether you want to do client verification or consumer (i.e. Server) verfication. best regards, Toni On 28 Jul., 10:56, kosso kos...@gmail.com wrote: my problems are opposite (using some php scripts) verification is ok, tweeting ok, but verified timelines (friends and mentions) not ok. On Jul 27, 9:29 pm, winrich winric...@gmail.com wrote: ok guys. so my calls were failing on the verify_credentials call and not on the update or timeline calls. the only difference i saw was the the verify_credential call wasn't secured. i changed it to https and it worked. ??? lol On Jul 27, 9:19 pm, Chad Etzel jazzyc...@gmail.com wrote: On Mon, Jul 27, 2009 at 11:55 PM, Duane Roelandsduane.roela...@gmail.com wrote: RTFM is not a helpful answer, especially when many developers are relying on libraries that they did not write. That's a risk you run when using code you didn't write. I'm not saying that this situation doesn't suck for those affected. I'm sure that it does. But, for a technology so new as OAuth, the libraries may not be mature yet. Officially, Twitter OAuth is still in Public Beta and has never been officially recommended to integrate into production code. That being said, there could still be a problem on Twitter's end with their signature verification mechanism and the libraries could all be valid. I don't have a way of knowing. I do agree that at least a note that a security change was pushed today would be nice, though. -Chad
[twitter-dev] Re: Twitter: What did you change in OAuth?
Looks like it's more than spaces. Looks like other characters are affected and URLPathEncode isn't handling it. Has -anyone- heard -anything- from Twitter? On Jul 28, 6:16 am, scotth_uk satsc...@gmail.com wrote: It's quite funny I suppose, been using basic auth forever, last week change over to OAuth...today, concidering going back, give a couple of years to iron out the bugs and maybe try again. I'm using Abraham Williams' PHP twitter OAuth library, I don't suppose anyone has found a fix for this? getting simply 'Invalid signature' is about as helpful as an unknown error occurred Cheers. On Jul 28, 6:23 am, chinaski007 chinaski...@gmail.com wrote: Confirmed. Google Playground does not work.
[twitter-dev] Re: Protected Resources requests need not be signed by the Consumer secret?
I've been using both consumer keys to sign all of my requests from day one. I still think the issue is related to URL encoding somehow, because I can successfully post tweets if they don't contain troublesome characters (apostrophe, for example). But, so long as Twitter remains silent, we'll never know. On Jul 25, 7:37 am, srikanth yaradla srikanth.yara...@gmail.com wrote: Hi I am newbie and i need clarification for the following 1)OAuth 1.0 specification says All Token requests and Protected Resources requests MUST be signed by theConsumer But twitter doesnt seem to verify the signature for all requests. I found out that signing the request byconsumersecretis required only for generating request token and requestsecret. But for subsequent requestsconsumersecretis not required. ex requesting access tokens or any protected resource (ex fetch direct messages). Is this desired behavior?. Does twitter verify the signature at all for protected resource requests? (i verified with blankconsumersecretwhich means the request is signed only by accesssecret) Or Am i missing something? 2) i am planning to write a desktop application. To protect theconsumersecreti am trying to introduce a proxy which generates the request tokens/secrets, access tokens/secrets. Ifconsumersecretis not required for signing protected resource requests this setup would work fine with me. But the OAuth specification says you require both accesssecretandconsumersecretto sign the request http://oauth.net/core/1.0/#anchor30 Experienced devs please clarify. Regards Srikanth
[twitter-dev] Re: Twitter: What did you change in OAuth?
Twitter Status : ... Is adding feature to his app so it can switch between OAuth and Basic for when OAuth breaks again. :-) Well, at least Basic auth's phase-out date has been pushed back another year.
[twitter-dev] Help with my rate limit issue?
Hi, I'm writing an app that requires semi-live updates from each user. Right now my registered userbase is five, so with a cron job I run the script every two minutes for 150 calls per hour (I'm requesting user Xs updates since last update) with a whitelisted limit of 2/hour though this only let's me serve a thousand or two users. Is there a way to request info for multiple users per REST API call? (And assuredly it seems like the search API would be hammered too hard) Thanks for any insight.
[twitter-dev] Re: streaming API for DM for multiple users ?
On Tue, Jul 28, 2009 at 4:39 AM, Ben Hallben200...@googlemail.com wrote: Random idea, but wouldn't a streaming API for DMs allow IM style clients to be implemented on top of the twitter platform? It would.
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
Indeed very frustrating.. developers also has a life haha.. i hope. My day was gone because of this.. All my GET's work, only POST is not working... using PHP to generate the sig. Any good ideas yet?
[twitter-dev] Re: Twitter: What did you change in OAuth?
Apparently two things were changed: 1. Setting the Consumer Secret is now a mandatory part of the signing process, empty consumer secrets don't work anymore. 2. Parameter encoding didn't previously enforce the part of section 5.1 that says that Hexadecimal characters in encodings MUST be upper case. Maybe more was changed, but these two did it for me. best regards, Toni
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
This is so clown show. On Tue, Jul 28, 2009 at 5:57 AM, soup fritsie2...@gmail.com wrote: Indeed very frustrating.. developers also has a life haha.. i hope. My day was gone because of this.. All my GET's work, only POST is not working... using PHP to generate the sig. Any good ideas yet?
[twitter-dev] Re: updating follow/shadow/birddog list of users
In this case it is fairly clear that you aren't trying to work around a limit, but are trying to get around a product limitation in /shadow. Be sure that you are connecting from two accounts. Keep your total connect rate as low as practical while still maintaining an acceptable user experience. Consider an explicit limiter on your end that prevents connecting more than once every one or two minutes. -John Kalucki http://twitter.com/jkalucki Services, Twitter Inc. On Jul 27, 8:53 pm, nickdella nick.dellamaggi...@gmail.com wrote: John, Thanks for the quick reply! The /shadow + /follow solution should work great! I was considering that, but was worried about opening two streams from the same IP + reconnecting every few minutes. If that indeed is acceptable usage of the streaming API, then I'm good. Thanks for your help! -nick On Jul 27, 8:03 pm, John Kalucki jkalu...@gmail.com wrote: The feature to update streaming api filter predicates has been put on hold for now. It is still desired, but not in the active development plan. You can backfill with the REST API, as you suggest. Or, you could reconnect every few minutes on the Streaming API. It might be best to have two streaming API accounts -- a /shadow stream that is long-lived and /follow stream that you reconnect with every few minutes when a new user is added. You can migrate accounts from the /follow stream to the /track stream once an hour or so. If the /follow stream runs afoul of a rate limit, at least the /shadow stream is still connected. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. On Jul 27, 7:18 pm, nickdella nick.dellamaggi...@gmail.com wrote: Hi, I'm working on a similar system in which members on my site dynamically subscribe to Twitter. Thus, my followinglistis constantly changing. To provide a reasonable user experience, I'd have to disconnect/reconnect every couple minutes to ensure their subscription is recognized in a timely manner :/ I understand that the constant disconnect/reconnect cycle is suboptimal for you guys. So, I have a fallback plan of concurrently using both the streaming API for existing subscribers while using the REST API to temporarily poll for status updates for all new subscribers. Every hour or so, I'd merge these new subscribers into the main followerslistand reconnect the stream. This is possible, but would definitely be some extra work to build. Alex described the possible addition of a REST API to dynamically update the followers list. Is there any chance this is coming in the near future i.e. next 3 weeks? :) Or do you guys have any other ideas on how I'd go about solving this given the current set of APIs? Thanks! -nick On Jul 8, 4:28 pm, John Kalucki jkalu...@gmail.com wrote: Alexy, First, curl isn't the best approach for developing against theStreamingAPI. It's fine for prototyping, but it only goes so far. Yes, the comma separatedlistshould be all on one line if you are using curl. If you want to change the user set, you should connect with the new set and then disconnect the old set immediately once the data starts to flow. This will be hard to coordinate using curl. In some cases, Twitter will throw the first user off once the second user connects. In other cases it will be more lenient. But, beware: if you want to avoid running into various abuse limits, you'd best be sure that your coordination between the first and second streams are quite solid and that the first stream is always terminated in a timely manner. You can also avoid data loss by using the count parameter, available on some, but not all, methods. Please email me with your use case and I'll forward it on to the Platform PM to help prioritize the better solution, as outlined by Alex. -John Kalucki twitter.com/jkalucki Services, Twitter Inc. On Jul 8, 12:17 pm, braver delivera...@gmail.com wrote: Uf you have thousands ofusers, do you really have to cook up a following file with comma-separated say 100,000 user IDs? Should it all be on one line? Now what happens if we want to drop some and add some IDs -- do we have to restart and re-upload all thatlistagain? I see when the curl -d @following ... starts up, it does that. Restarting with huge lists sounds like data loss... Cheers, Alexy
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
I'm the developer who reported this problem to Twitter offline. I had been preparing a test case for them when I noticed this post: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/a195ea9b9952e297?hl=en# I then skipped the preparation of the test case and sent e-mail directly to Twitter since this was what I considered to be a high risk issue. Since the fix from Twitter went in for this last night, I have also seen some strange behaviour with OAuth. I'm getting a lot of 401 responses for users who were already logged in. I'm also getting sporadic bad responses for accesses that ask for a request token (BTW - I'm using https if that makes any difference). I think that there is still a problem. I've switched my application back to using Basic Auth for now. - Scott @scott_carter http://bigtweet.com
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
OAuth isn't perfect yet. However, it is better from one stand point: If I sign up for a website or program with my twitter password, and it does bad things, I have to change my password in EVERY twitter program I use. With OAuth, I can just block your app. On Jul 28, 9:08 am, Duane Roelands duane.roela...@gmail.com wrote: To be fair, OAuth is better for the user, security-wise, because they never have to provide their Twitter credentials to your application. Basic Auth also provides no way to know that the application is actually who it says it is. OAuth is far from perfect on this front, but it's light-years ahead of Basic. I'm just as agitated about this as anyone, because I think that Twittter's behavior in this specific instance has been sub-par. However, OAuth is still far more secure than Basic Auth On Jul 28, 7:27 am, chinaski007 chinaski...@gmail.com wrote: Let's be honest... The end-result for third-party developers using OAuth appears to be fewer sign-ups, less reliability, more complexity, and potentially less security. Google Optimizer reveals that users are more likely to sign-up for Basic Auth than OAuth. That's just fact. Test it for yourself to confirm. I suppose this is not so weird. Users are accustomed to giving user/ pass information even to foreign apps. It is far more disruptive and invasive for them to go to some bizarre Twitter screen asking them to approve an app. To the average user, what does that mean? (And, heck, it may even require more steps if they have to login again to Twitter.) In terms of reliability, Twitter OAuth was down for days several weeks ago. Tonight yet another unannounced change occurred that broke major code libraries. Meanwhile, Basic Auth has been plugging along just fine and dandy... So what IS the benefit of OAuth? It doesn't benefit developers as you will likely get more sign-ups with Basic Auth and Basic Auth is far, far easier to setup. Sure, OAuth might satisfy some power users hungry for security... But is OAuth even more secure than Basic Auth? Perhaps not. After all, tonight's fix was for an OAuth security flaw known for at least 10+ days (judging by tweets to @twitterapi) that allowed for potential impersonations of credentialed users. On the heels of Twitter's (unofficial) assurance of better communication with developers, this sort of unannounced change is distressing. What's next? (Have Labor Day Weekend plans? You might want to cancel those... just the right time for Twitter to make an unannounced API change!) As for us, we are in the strange position of deprecating OAuth in favor of Basic Auth. Weird, eh?? Okay, we are not totally deprecating OAuth, but we are advising users that Basic Auth is far more robust and reliable. And so our message to new developers: avoid OAuth like the plague. If you must, offer it. But let Basic Auth be your backbone: more reliable, more sign-ups, simpler, and probably just as secure. (Just look at Google Code bug reports about OAuth to get a sense of reliablity.) (Okay, okay, this post was written at 4am after a workday that started at 8am, and after Twitter introduced this new change at 5pm... (hey Twitter, can you introduce major new changes EARLIER in the day so we can react!?!?)... it still doesn't excuse Twitter's continued disregard for the small-to-medium size developer.)
[twitter-dev] Re: Protected Resources requests need not be signed by the Consumer secret?
I dont think you got my point. Whether you were signing using both secrets or one secret doesnt matter because twitter wasnt verifying signature at all. Now they have fixed this and all your protected service requests must be signed by both secrets. My problem is how to protect the consumer secret. Looks like i cant protect it as this is the case with desktop clients using oauth On Tue, Jul 28, 2009 at 6:30 PM, Duane Roelands duane.roela...@gmail.comwrote: I've been using both consumer keys to sign all of my requests from day one. I still think the issue is related to URL encoding somehow, because I can successfully post tweets if they don't contain troublesome characters (apostrophe, for example). But, so long as Twitter remains silent, we'll never know. On Jul 25, 7:37 am, srikanth yaradla srikanth.yara...@gmail.com wrote: Hi I am newbie and i need clarification for the following 1)OAuth 1.0 specification says All Token requests and Protected Resources requests MUST be signed by theConsumer But twitter doesnt seem to verify the signature for all requests. I found out that signing the request byconsumersecretis required only for generating request token and requestsecret. But for subsequent requestsconsumersecretis not required. ex requesting access tokens or any protected resource (ex fetch direct messages). Is this desired behavior?. Does twitter verify the signature at all for protected resource requests? (i verified with blankconsumersecretwhich means the request is signed only by accesssecret) Or Am i missing something? 2) i am planning to write a desktop application. To protect theconsumersecreti am trying to introduce a proxy which generates the request tokens/secrets, access tokens/secrets. Ifconsumersecretis not required for signing protected resource requests this setup would work fine with me. But the OAuth specification says you require both accesssecretandconsumersecretto sign the request http://oauth.net/core/1.0/#anchor30 Experienced devs please clarify. Regards Srikanth
[twitter-dev] Re: Protected Resources requests need not be signed by the Consumer secret?
I have the same issue with my application. Desktop apps are forced to either embed the consumer keys in source code or construct some sort of elaborate server mechanism. There's no good answer here. When my application approaches 1.0 release, I'll probably use Dotfuscator or something similar to help protect the keys that are in the source. It won't stop a determined attacker, but it will at least deter the less-determined ones. On Jul 28, 10:38 am, srikanth reddy srikanth.yara...@gmail.com wrote: I dont think you got my point. Whether you were signing using both secrets or one secret doesnt matter because twitter wasnt verifying signature at all. Now they have fixed this and all your protected service requests must be signed by both secrets. My problem is how to protect the consumer secret. Looks like i cant protect it as this is the case with desktop clients using oauth On Tue, Jul 28, 2009 at 6:30 PM, Duane Roelands duane.roela...@gmail.comwrote: I've been using both consumer keys to sign all of my requests from day one. I still think the issue is related to URL encoding somehow, because I can successfully post tweets if they don't contain troublesome characters (apostrophe, for example). But, so long as Twitter remains silent, we'll never know. On Jul 25, 7:37 am, srikanth yaradla srikanth.yara...@gmail.com wrote: Hi I am newbie and i need clarification for the following 1)OAuth 1.0 specification says All Token requests and Protected Resources requests MUST be signed by theConsumer But twitter doesnt seem to verify the signature for all requests. I found out that signing the request byconsumersecretis required only for generating request token and requestsecret. But for subsequent requestsconsumersecretis not required. ex requesting access tokens or any protected resource (ex fetch direct messages). Is this desired behavior?. Does twitter verify the signature at all for protected resource requests? (i verified with blankconsumersecretwhich means the request is signed only by accesssecret) Or Am i missing something? 2) i am planning to write a desktop application. To protect theconsumersecreti am trying to introduce a proxy which generates the request tokens/secrets, access tokens/secrets. Ifconsumersecretis not required for signing protected resource requests this setup would work fine with me. But the OAuth specification says you require both accesssecretandconsumersecretto sign the request http://oauth.net/core/1.0/#anchor30 Experienced devs please clarify. Regards Srikanth
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
On twollo.com I have not seen any issues yet with the changes - no one has ever complained about the Sign in with Twitter option. But I am very glad that Twitter implemented OAuth, I don't have to manage the credentials in the same way - Authenticate using Twitter has been a god send for me, and I am glad I harped on about it for as long as I did, the UX is pretty smooth. From a usage point of view, twollo has about 15000 oauthed users, this is about 30% of the user base. I still provide the option to authenticate using your password (I might remove this soon) - I honestly can't tell why people want to keep giving me their usernames and passwords but they do. If you check http://www.friendboo.com, because I had already implemented Twitter OAuth it was really simple to implement FriendFeeds OAuth - purely because the process is very similar across services - I imagine that this is the case for other services too. I honestly wish Twitter would get out of the oAuth is not meant for production use mindset and really start making people use oAuth. Paul 2009/7/28 chinaski007 chinaski...@gmail.com Let's be honest... The end-result for third-party developers using OAuth appears to be fewer sign-ups, less reliability, more complexity, and potentially less security. Google Optimizer reveals that users are more likely to sign-up for Basic Auth than OAuth. That's just fact. Test it for yourself to confirm. I suppose this is not so weird. Users are accustomed to giving user/ pass information even to foreign apps. It is far more disruptive and invasive for them to go to some bizarre Twitter screen asking them to approve an app. To the average user, what does that mean? (And, heck, it may even require more steps if they have to login again to Twitter.) In terms of reliability, Twitter OAuth was down for days several weeks ago. Tonight yet another unannounced change occurred that broke major code libraries. Meanwhile, Basic Auth has been plugging along just fine and dandy... So what IS the benefit of OAuth? It doesn't benefit developers as you will likely get more sign-ups with Basic Auth and Basic Auth is far, far easier to setup. Sure, OAuth might satisfy some power users hungry for security... But is OAuth even more secure than Basic Auth? Perhaps not. After all, tonight's fix was for an OAuth security flaw known for at least 10+ days (judging by tweets to @twitterapi) that allowed for potential impersonations of credentialed users. On the heels of Twitter's (unofficial) assurance of better communication with developers, this sort of unannounced change is distressing. What's next? (Have Labor Day Weekend plans? You might want to cancel those... just the right time for Twitter to make an unannounced API change!) As for us, we are in the strange position of deprecating OAuth in favor of Basic Auth. Weird, eh?? Okay, we are not totally deprecating OAuth, but we are advising users that Basic Auth is far more robust and reliable. And so our message to new developers: avoid OAuth like the plague. If you must, offer it. But let Basic Auth be your backbone: more reliable, more sign-ups, simpler, and probably just as secure. (Just look at Google Code bug reports about OAuth to get a sense of reliablity.) (Okay, okay, this post was written at 4am after a workday that started at 8am, and after Twitter introduced this new change at 5pm... (hey Twitter, can you introduce major new changes EARLIER in the day so we can react!?!?)... it still doesn't excuse Twitter's continued disregard for the small-to-medium size developer.)
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
On Tue, Jul 28, 2009 at 7:27 AM, chinaski007chinaski...@gmail.com wrote: [the same post three different times] WE GET IT. YOU DON'T LIKE OAUTH. Your (probably statistically insignificant) tests with Google Optimizer reveal that your users are more likely to sign-up for Basic Auth than OAuth. WE GET IT. Did you need to start three different threads to say exactly the same thing on the same day?
[twitter-dev] Possible tips and solutions if you are getting invalid signature since the latest security patch
I finally found out whats causing problems for me.
1. Make sure you are using token secret(oauth_token_secret) to create
signature. I think earlier, twitter was accepting even without token-
secret (a security hole) and hence the fix (I think).
In javascript api to update a status...
var accessor = { consumerSecret: this.consumerSecret
, tokenSecret : token_secret};
var message = { method: POST
, action: http://twitter.com/statuses/update.json;
, parameters: new Array()
};
message.parameters.push([oauth_consumer_key,this.consumerKey]);
message.parameters.push([oauth_version,1.0]);
message.parameters.push([oauth_timestamp, OAuth.timestamp()]);
message.parameters.push([oauth_nonce, OAuth.nonce(11)]);
message.parameters.push([oauth_signature_method, HMAC-SHA1]);
message.parameters.push([oauth_token, ot]);
message.parameters.push([status,Encode(HI FROM TWITTER)]);
2. If the request uses additional parameters, like to send a tweet we
need to add status = tweet text parameter, make sure to also pass
the additional parameters to *create* signature. In the above example,
i am passing status = ,Encode(HI FROM TWITTER) to create
signature.
3. Be careful of double-encoding.
for example: hi there after encoding becomes.. hi%20there and if
your code is mistakenly encoding it a second time.. it would become hi
%2520there. And since it(HTTP post/get parameter) doesn't match what
was used to create signature, you will again get infamous 'invalid
signature'
[twitter-dev] Re: API only shows messages from last 7 days
I am a bit concerned. I remember at one point it being between 30-45 days. Now it seems to be getting smaller by about 1-day per month. Last month it was closer to 10 days. Is it basically going to keep getting smaller and smaller until we get V2 of the API, or will we be forced to all use only streaming services and then locally cache everything that we'd want to search for any time period? I know there are a LOT of problems inherent in the massive scaling out of Twitter, and this is just a symptom of them- but at the same time I can only imagine how unusable Google would be if you only had a 7-day window to Search in, and couldn't get any content made prior to that. Very worried about this soon being a 2-3 day window. dave On Jul 26, 4:11 am, Flashing Moose flashingmo...@gmail.com wrote: Hmm, then i can't use the API for this project, thx for replies guys. On 26 jul, 04:10, Dewald Pretorius dpr...@gmail.com wrote: I believe the tweet retention in Twitter Search has always been 7 days. On Jul 25, 1:18 pm, Flashing Moose flashingmo...@gmail.com wrote: Hello, having some trouble with the API because only the messages from the last 7 days show up: example: feed://search.twitter.com/search.atom?q=from%3AstimulusHome Yes, there must be older posts in there... but how do i get to them? I read about the Operator Limits: filter:links operator: results are limited to 7 days source: operator: results are limited to 7 days queries must contain at least one keyword parameter with the source: operator lang= operator: results are limited to 7 days location operator: results are limited to 7 days but i'm not using filter, source, language or location do i? regards, Moose
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
I don't myself think that twitter are doing anything more than enforcing the standard. I spent 3 hours 'fixing' my code for our application (uses Shannon Whitley's c# library as a base); I only found two bugs in thelibrary that caused any problem... the use of httputility.urlencode in place of the modified urlencode already implemented for use with Oauth, as required by the spec... the library just wasn't using it in two places. Following that, I found I was passing some bad strings to the library... so the methods in it were not urldecoding and re- urlencoding the postdata as required to get it to meet the spec. Once I fixed that also, all seems good. So if our app now posts all data fine over Oauth, it suggests that twitter's interface is OK? Simon On Jul 28, 8:16 am, BlueSkies scarter28m-goo...@yahoo.com wrote: I'm the developer who reported this problem to Twitter offline. I had been preparing a test case for them when I noticed this post:http://groups.google.com/group/twitter-development-talk/browse_thread... I then skipped the preparation of the test case and sent e-mail directly to Twitter since this was what I considered to be a high risk issue. Since the fix from Twitter went in for this last night, I have also seen some strange behaviour with OAuth. I'm getting a lot of 401 responses for users who were already logged in. I'm also getting sporadic bad responses for accesses that ask for a request token (BTW - I'm using https if that makes any difference). I think that there is still a problem. I've switched my application back to using Basic Auth for now. - Scott @scott_carterhttp://bigtweet.com
[twitter-dev] Re: API only shows messages from last 7 days
I agree with you Dave. I have several thought about new services based on searching Twitter's historical data. Unfortunately my ideas appear to be getting less and less practical. Twitter claims to have all its data stored in disk-based databases from what I understand ... yet without access to this data it is worthless. It seems to me they could allow searches of this historical data via a new History API then let us cache the results on our own servers. Most of the services I've conceived would do this infrequently -- never in real time -- and would not impact their existing cached server data because this historical data would exist on separate data storage servers ... theoretically anyways. Owkaye I am a bit concerned. I remember at one point it being between 30-45 days. Now it seems to be getting smaller by about 1-day per month. Last month it was closer to 10 days. Is it basically going to keep getting smaller and smaller until we get V2 of the API, or will we be forced to all use only streaming services and then locally cache everything that we'd want to search for any time period? I know there are a LOT of problems inherent in the massive scaling out of Twitter, and this is just a symptom of them- but at the same time I can only imagine how unusable Google would be if you only had a 7-day window to Search in, and couldn't get any content made prior to that. Very worried about this soon being a 2-3 day window. dave
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
I think the big problem is that twitter's implementation is buggy and given that its relatively convoluted to implement oauth, even our implementation is buggy. Adding to that if we only get 'invalid signature' irrespective of which side the bug resides, frustrating both sides. I think it would be better they give 'clear' and concrete oauth examples for various twitter api calls(few POSTs and few GETs). And more importantly, also list out all the 'gotcha' or common-mistakes would be better for all of us. On Jul 28, 8:40 am, Zaudio si...@z-audio.co.uk wrote: I don't myself think that twitter are doing anything more than enforcing the standard. I spent 3 hours 'fixing' my code for our application (uses Shannon Whitley's c# library as a base); I only found two bugs in thelibrary that caused any problem... the use of httputility.urlencode in place of the modified urlencode already implemented for use with Oauth, as required by the spec... the library just wasn't using it in two places. Following that, I found I was passing some bad strings to the library... so the methods in it were not urldecoding and re- urlencoding the postdata as required to get it to meet the spec. Once I fixed that also, all seems good. So if our app now posts all data fine over Oauth, it suggests that twitter's interface is OK? Simon On Jul 28, 8:16 am, BlueSkies scarter28m-goo...@yahoo.com wrote: I'm the developer who reported this problem to Twitter offline. I had been preparing a test case for them when I noticed this post:http://groups.google.com/group/twitter-development-talk/browse_thread... I then skipped the preparation of the test case and sent e-mail directly to Twitter since this was what I considered to be a high risk issue. Since the fix from Twitter went in for this last night, I have also seen some strange behaviour with OAuth. I'm getting a lot of 401 responses for users who were already logged in. I'm also getting sporadic bad responses for accesses that ask for a request token (BTW - I'm using https if that makes any difference). I think that there is still a problem. I've switched my application back to using Basic Auth for now. - Scott @scott_carterhttp://bigtweet.com
[twitter-dev] Re: Twitter: What did you change in OAuth?
Also check out things that broke for me(and their solutions) http://groups.google.com/group/twitter-development-talk/browse_thread/thread/59ed5372f7c1b623 On Jul 28, 6:42 am, Duane Roelands duane.roela...@gmail.com wrote: Glad things are working for you. ;) Still no luck here. I'm signing the requests with both keys and I'm URLEncoding all %-values to upper case. On Jul 28, 9:18 am, thetago...@googlemail.com anto...@cloudangels.com wrote: Apparently two things were changed: 1. Setting the Consumer Secret is now a mandatory part of the signing process, empty consumer secrets don't work anymore. 2. Parameter encoding didn't previously enforce the part of section 5.1 that says that Hexadecimal characters in encodings MUST be upper case. Maybe more was changed, but these two did it for me. best regards, Toni
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
Although oauth is convoluted and twitter's implementation is buggy, no clear examples and takes time to get it right, I still vote for OAuth. You see people simply don't trust 3rd party apps with their login info as much as they trust the main-application(twitter.com). So at the end of the day, its better for us :)
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
My stuff is based on Shannon Whitley's as well. Do you mind sharing where specifically you had to make the changes? On Jul 28, 11:40 am, Zaudio si...@z-audio.co.uk wrote: I don't myself think that twitter are doing anything more than enforcing the standard. I spent 3 hours 'fixing' my code for our application (uses Shannon Whitley's c# library as a base); I only found two bugs in thelibrary that caused any problem... the use of httputility.urlencode in place of the modified urlencode already implemented for use with Oauth, as required by the spec... the library just wasn't using it in two places.
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
I use this implementation: http://www.codingthewheel.com/archives/codingthetweet works flawlessly! On Tue, Jul 28, 2009 at 5:47 PM, Duane Roelands duane.roela...@gmail.comwrote: My stuff is based on Shannon Whitley's as well. Do you mind sharing where specifically you had to make the changes? On Jul 28, 11:40 am, Zaudio si...@z-audio.co.uk wrote: I don't myself think that twitter are doing anything more than enforcing the standard. I spent 3 hours 'fixing' my code for our application (uses Shannon Whitley's c# library as a base); I only found two bugs in thelibrary that caused any problem... the use of httputility.urlencode in place of the modified urlencode already implemented for use with Oauth, as required by the spec... the library just wasn't using it in two places. -- Cristovao Morgado aka Saintr http://www.oMeuJogoUsado.com http://www.TweetaPorSMS.com http://twitter.com/TheSaintr
[twitter-dev] Re: API only shows messages from last 7 days
I would do anything (including paying good amounts of money) to be able to purchase access to older datasets that I could transfer to my database through non-rest-api methods. I'm envisioning being able to download a CSV or SQL file that I could merge with my database easily, but only have to make a single request to the server to get a month of data. I'd sign agreements and pay money for such. dave On Jul 28, 12:03 pm, owkaye owk...@gmail.com wrote: I agree with you Dave. I have several thought about new services based on searching Twitter's historical data. Unfortunately my ideas appear to be getting less and less practical. Twitter claims to have all its data stored in disk-based databases from what I understand ... yet without access to this data it is worthless. It seems to me they could allow searches of this historical data via a new History API then let us cache the results on our own servers. Most of the services I've conceived would do this infrequently -- never in real time -- and would not impact their existing cached server data because this historical data would exist on separate data storage servers ... theoretically anyways. Owkaye I am a bit concerned. I remember at one point it being between 30-45 days. Now it seems to be getting smaller by about 1-day per month. Last month it was closer to 10 days. Is it basically going to keep getting smaller and smaller until we get V2 of the API, or will we be forced to all use only streaming services and then locally cache everything that we'd want to search for any time period? I know there are a LOT of problems inherent in the massive scaling out of Twitter, and this is just a symptom of them- but at the same time I can only imagine how unusable Google would be if you only had a 7-day window to Search in, and couldn't get any content made prior to that. Very worried about this soon being a 2-3 day window. dave
[twitter-dev] Application statistics
Is there a way of tracking who and how is using your app? Simple search based on app name (like from DroidIn) does not yield any results
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
If you are encoding properly according to: http://oauth.net/core/1.0a#encoding_parameters and it still fails to update post and update to http://code.google.com/p/twitter-api/issues/entry and make Twitter fix it. I've not double checked to verify but ! should encode to %21 and then it should work. Abraham On Tue, Jul 28, 2009 at 10:06, Duane Roelands duane.roela...@gmail.comwrote: Yeah, that's what I'm doing as well. I wish Twitter would give us some answers. I can post a tweet is the text is test If I try to post test!, it fails. Something about the encoding of non-alphanumeric characters is part of the problem. But, because Twitter isn't talking, all we can do is guess. On Jul 28, 12:52 pm, Cristovão Morgado cristovao.morg...@gmail.com wrote: I use this implementation: http://www.codingthewheel.com/archives/codingthetweet works flawlessly! On Tue, Jul 28, 2009 at 5:47 PM, Duane Roelands duane.roela...@gmail.comwrote: My stuff is based on Shannon Whitley's as well. Do you mind sharing where specifically you had to make the changes? On Jul 28, 11:40 am, Zaudio si...@z-audio.co.uk wrote: I don't myself think that twitter are doing anything more than enforcing the standard. I spent 3 hours 'fixing' my code for our application (uses Shannon Whitley's c# library as a base); I only found two bugs in thelibrary that caused any problem... the use of httputility.urlencode in place of the modified urlencode already implemented for use with Oauth, as required by the spec... the library just wasn't using it in two places. -- Cristovao Morgado aka Saintrhttp://www.oMeuJogoUsado.comhttp://www.TweetaPorSMS.comhttp:// twitter.com/TheSaintr -- Abraham Williams | Community Evangelist | http://web608.org Hacker | http://abrah.am | http://twitter.com/abraham Project | http://fireeagle.labs.poseurtech.com This email is: [ ] blogable [x] ask first [ ] private.
[twitter-dev] How can I upload a profile_image with php?
Hi everyone,
I'm trying to upload profile_image with php.
And it seems i have uploaded the image successfully and got the
response, but the image which I've just uploaded was not shown on the
web.
Here are the codes and responses:
--- The php code:
?php
function twitter_process($url, $post_data = false) {
if ($post_data === true) $post_data = array();
$ch = curl_init($url);
if($post_data !== false) {
curl_setopt ($ch, CURLOPT_POST, true);
curl_setopt ($ch, CURLOPT_POSTFIELDS, $post_data);
}
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Expect:',
'X-Twitter-Client: ','X-Twitter-Client-Version:
','X-Twitter-Client-URL: '));
curl_setopt($ch, CURLOPT_USERPWD, 'cnalpha:password');//for testing
curl_setopt($ch, CURLOPT_VERBOSE, 1);
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_USERAGENT, 'testing api');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
echo $response = curl_exec($ch);
$response_info=curl_getinfo($ch);
curl_close($ch);
}
$file = 'ninja-heart.png';
$url = 'https://twitter.com/account/update_profile_image.xml';
$fields['image'] = '@'.realpath($file);
twitter_process($url,$fields);
?
--- The response I've got:
?xml version=1.0 encoding=UTF-8?
user
id55821366/id
namecnAlpha!/name
screen_namecnAlpha/screen_name
locationlocation test/location
descriptiontesting bio/description
profile_image_urlhttp://s3.amazonaws.com/twitter_production/profile_images/ninja-heart_normal.png/profile_image_url
urlhttp://localhost/fake//url
protectedfalse/protected
followers_count5/followers_count
profile_background_color9AE4E8/profile_background_color
profile_text_color33/profile_text_color
profile_link_color0084B4/profile_link_color
profile_sidebar_fill_colorDDFFCC/profile_sidebar_fill_color
profile_sidebar_border_colorBDDCAD/profile_sidebar_border_color
friends_count28/friends_count
created_atSat Jul 11 12:33:05 + 2009/created_at
favourites_count0/favourites_count
utc_offset28800/utc_offset
time_zoneBeijing/time_zone
profile_background_image_urlhttp://static.twitter.com/images/themes/theme1/bg.gif/profile_background_image_url
profile_background_tilefalse/profile_background_tile
statuses_count10/statuses_count
notificationsfalse/notifications
verifiedfalse/verified
followingfalse/following
status
created_atMon Jul 27 08:49:08 + 2009/created_at
id2867594331/id
text#27979;#35797;#31243;#24207;/text
sourceweb/source
truncatedfalse/truncated
in_reply_to_status_id/in_reply_to_status_id
in_reply_to_user_id/in_reply_to_user_id
favoritedfalse/favorited
in_reply_to_screen_name/in_reply_to_screen_name
/status
/user
--- Then I opened https://twitter.com/cnalpha and I found the picture
was not shown.
--- So, I opended
http://s3.amazonaws.com/twitter_production/profile_images/ninja-heart_normal.png,
--- the url of the picture and I got errors:
Error
CodeNoSuchKey/Code
MessageThe specified key does not exist./Message
Keyprofile_images/ninja-heart_normal.png/Key
RequestId9F59BC459B56D618/RequestId
HostId
syUrwNpASUBd0bQA0CLb29GcTnQD4Al7Ors7cnv5zrltqFD5ImeI2W0Prqlj2V2v
/HostId
/Error
So, how can I upload a profile_image with php?
Forgive my poor English
Darasion.
[twitter-dev] Re: API only shows messages from last 7 days
I'm sure others feel the same way Dave, but it looks and feels like Twitter is moving in the opposite direction. The load on a server to extract a big dataset once a month would be minimal, and both you and I can see the value in this approach. But I'm not sure the folks at Twitter do, or if they do maybe they just don't have the people who can (and will) get things like this implemented. Is a shortage of competent staff the cause of this type of problem? Even though I have the capabilities I do not have the 'resume' to get a job there and help them deal with some of this stuff, nor do I have the contacts within the Twitter organization to put a good word in for me and help me get hired so I could do good things for them. I'm 52 years old too, and my age seems to be a negative to most of the Web 2.x companies hiring these days. This is kind of a shame considering that people like me frequently have broader-based experience and insights that are sometimes lacking in younger people, and because of this we can add a lot more value in the areas of planning and structural development than people half our age. Our coding skills are honed after so many years of experience too, not to mention the thousands of code snippets we have collected over the years to contribute to making us even faster. But since jobs like this are basically not open to me and many other folks my age, my alternative is to remain self- employed and try to build something on top of their existing available source data and API's ... and then deal with the issues and frustrations created when building a service on top of a 'moving target' that sometimes seems to be moving in funny directions. I hear about Twitter having lots of money to work with, and I'm probably wrong here but it almost seems like there's too little of this money being dedicated to paying new talent with long term views of some of these issues, and who will implement wise policies to help support and encourage rapid growth in the areas that are lacking. But once again this might just be due to a shortage of the right staff. Obviously we cannot do anything from the outside except point out these issues and ask questions, or beg and plead for changes, but it sure would be great if a few of us could actually get in there as employees and implement a couple of the new features we really need -- such as a new Historical Search API for example. Then developers like you and I could proceed with some of our plans now, instead of months or years from now ... or possibly never. I would love to lead a team on a project like this, or even be one of its members, but until it happens I'll focus on building my own little space in the Twitter universe and continue to hope for the best. :) Owkaye I would do anything (including paying good amounts of money) to be able to purchase access to older datasets that I could transfer to my database through non-rest-api methods. I'm envisioning being able to download a CSV or SQL file that I could merge with my database easily, but only have to make a single request to the server to get a month of data. I'd sign agreements and pay money for such. dave On Jul 28, 12:03 pm, owkaye owk...@gmail.com wrote: I agree with you Dave. I have several thought about new services based on searching Twitter's historical data. Unfortunately my ideas appear to be getting less and less practical. Twitter claims to have all its data stored in disk-based databases from what I understand ... yet without access to this data it is worthless. It seems to me they could allow searches of this historical data via a new History API then let us cache the results on our own servers. Most of the services I've conceived would do this infrequently -- never in real time -- and would not impact their existing cached server data because this historical data would exist on separate data storage servers ... theoretically anyways. Owkaye I am a bit concerned. I remember at one point it being between 30-45 days. Now it seems to be getting smaller by about 1-day per month. Last month it was closer to 10 days. Is it basically going to keep getting smaller and smaller until we get V2 of the API, or will we be forced to all use only streaming services and then locally cache everything that we'd want to search for any time period? I know there are a LOT of problems inherent in the massive scaling out of Twitter, and this is just a symptom of them- but at the same time I can only imagine how unusable Google would be if you only had a 7-day window to Search in, and couldn't get any content made prior to that. Very worried about this soon being a 2-3 day window. dave
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
As many of you have since learned, we deployed an unannounced security fix that has resulted in unexpected failures for quite a few developers using OAuth. A developer reported to us that OAuth signatures were not being verified on our side. The fix was implemented and pushed on Sunday then deployed yesterday. Once the fix was in the wild many applications started returning Invalid Signature errors. Our various successful tests seem to indicate that the signature verification is implemented correctly and yet many people are experiencing errors. So what's going on? One of the main problems seems to be that many OAuth libraries appear to not be generating correctly signed requests. It's likely that Twitter's implementation was used to test out many of these libraries when they were being implemented. Without the correct signature check, it appeared to these developers that their libraries were implementing the spec correctly. For this confusion we must take at least partial blame. The following email from Simon in the UK seems to indicate absent url encoding and decoding is a likely culprit in many of these libraries: I don't myself think that twitter are doing anything more than enforcing the standard. I spent 3 hours 'fixing' my code for our application (uses Shannon Whitley's c# library as a base); I only found two bugs in thelibrary that caused any problem... the use of httputility.urlencode in place of the modified urlencode already implemented for use with Oauth, as required by the spec... the library just wasn't using it in two places. Following that, I found I was passing some bad strings to the library... so the methods in it were not urldecoding and re- urlencoding the postdata as required to get it to meet the spec. Once I fixed that also, all seems good. So if our app now posts all data fine over Oauth, it suggests that twitter's interface is OK? There are at least several things we could have done better in dealing with this: * We should have, it goes without saying, had more extensive test coverage of our implementation ensuring that we were fully implementing the spec so that the whole situation would have been avoided in the first place. * We should have had an email prepared to send out immediately following the deploy explaining the vulnerability and the change that was deployed, encouraging developers to double check that their signatures were in fact being generated correctly. We left a lot of people guessing for half a day, in many cases probably frantically trying to fix mysterious failures in their apps. For that we must admit guilt. We hadn't anticipated that so many libraries might have not been generating signatures correctly. As a result it didn't occur to us to urgently send out details, assuming fully implemented libraries would continue to work transparently and malicious requests would start to fail. We had been focusing our efforts first and foremost on getting the fix implemented and deployed to protect everyone. Lesson learned. We'll take this experience with us and bring it to bear next time such a situation arises. We're going to do a post-mortem on our side to identify all the things we should have done better. We've read all of your feedback about how this could have been done better. To everyone who has chimed into this thread offering details and help, we extend our thanks. On Tue, Jul 28, 2009 at 10:28 AM, Abraham Williams 4bra...@gmail.comwrote: If you are encoding properly according to: http://oauth.net/core/1.0a#encoding_parameters and it still fails to update post and update to http://code.google.com/p/twitter-api/issues/entry and make Twitter fix it. I've not double checked to verify but ! should encode to %21 and then it should work. Abraham On Tue, Jul 28, 2009 at 10:06, Duane Roelands duane.roela...@gmail.comwrote: Yeah, that's what I'm doing as well. I wish Twitter would give us some answers. I can post a tweet is the text is test If I try to post test!, it fails. Something about the encoding of non-alphanumeric characters is part of the problem. But, because Twitter isn't talking, all we can do is guess. On Jul 28, 12:52 pm, Cristovão Morgado cristovao.morg...@gmail.com wrote: I use this implementation: http://www.codingthewheel.com/archives/codingthetweet works flawlessly! On Tue, Jul 28, 2009 at 5:47 PM, Duane Roelands duane.roela...@gmail.comwrote: My stuff is based on Shannon Whitley's as well. Do you mind sharing where specifically you had to make the changes? On Jul 28, 11:40 am, Zaudio si...@z-audio.co.uk wrote: I don't myself think that twitter are doing anything more than enforcing the standard. I spent 3 hours 'fixing' my code for our application (uses Shannon Whitley's c# library as a base); I only found two bugs in thelibrary that caused any problem... the use of httputility.urlencode in place of the modified urlencode already implemented for use with
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
Sorry about that... I deleted those threads before posting this one. I gather you are choosing to receive emails individually. The tests were statistically significant at 95% confidence levels. On Jul 28, 8:09 am, TjL luo...@gmail.com wrote: On Tue, Jul 28, 2009 at 7:27 AM, chinaski007chinaski...@gmail.com wrote: [the same post three different times] WE GET IT. YOU DON'T LIKE OAUTH. Your (probably statistically insignificant) tests with Google Optimizer reveal that your users are more likely to sign-up for Basic Auth than OAuth. WE GET IT. Did you need to start three different threads to say exactly the same thing on the same day?
[twitter-dev] OAuth URLEncode for VB.NET Libraries
My application appears to be back in the game, after some corrections to my url encoding. I've posted the code here (http://dpaste.com/hold/ 72568/) for the benefit of other VB.NET developers. This is a VB.NET port of the URLEncode method found in the Twitter/ OAuth class from Shannon Whitley and Eran Sandler. They rock. Hopefully, this gets you guys back in the game as well.
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
What do you know about your sample, other than they use your app? Are they technically savvy? Mindful of their security? Do they often click on links from Paypal in their email? Do they have friends in Nigeria that are willing to send them money? I think that is the statistical significance to which TjL was referring. At least, I hope so. On Tue, Jul 28, 2009 at 12:12, chinaski007 chinaski...@gmail.com wrote: Sorry about that... I deleted those threads before posting this one. I gather you are choosing to receive emails individually. The tests were statistically significant at 95% confidence levels. On Jul 28, 8:09 am, TjL luo...@gmail.com wrote: On Tue, Jul 28, 2009 at 7:27 AM, chinaski007chinaski...@gmail.com wrote: [the same post three different times] WE GET IT. YOU DON'T LIKE OAUTH. Your (probably statistically insignificant) tests with Google Optimizer reveal that your users are more likely to sign-up for Basic Auth than OAuth. WE GET IT. Did you need to start three different threads to say exactly the same thing on the same day? -- Internets. Serious business.
[twitter-dev] Re: OAuth URLEncode for VB.NET Libraries
On Tue, Jul 28, 2009 at 2:13 PM, Duane Roelands duane.roela...@gmail.comwrote: My application appears to be back in the game, after some corrections to my url encoding. I've posted the code here (http://dpaste.com/hold/ 72568/ http://dpaste.com/hold/%0A72568/) for the benefit of other VB.NETdevelopers. This is a VB.NET port of the URLEncode method found in the Twitter/ OAuth class from Shannon Whitley and Eran Sandler. They rock. Hopefully, this gets you guys back in the game as well. Good stuff Duane, I may refactor this into C#. --ab
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
On Tue, Jul 28, 2009 at 2:15 PM, JDG ghil...@gmail.com wrote: I think that is the statistical significance to which TjL was referring. At least, I hope so. I think TjL was referring more to raw population factor than biases. Any one single non-large userbase app is not likely to be statistically predictive of the results you will find across the spectrum of possible apps.
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
That's sort of what I meant, with more references to 419 scammers, my favorite scammers of all. It's hard to imagine ANY app out there to provide a statistically random enough sample to mean anything. If Twitter itself were to perform the survey, I think you'd be more likely to have a random sample, though of course it would be biased towards those of us that enjoy those sorts of surveys. ;) On Tue, Jul 28, 2009 at 12:17, Andrew Badera and...@badera.us wrote: On Tue, Jul 28, 2009 at 2:15 PM, JDG ghil...@gmail.com wrote: I think that is the statistical significance to which TjL was referring. At least, I hope so. I think TjL was referring more to raw population factor than biases. Any one single non-large userbase app is not likely to be statistically predictive of the results you will find across the spectrum of possible apps. -- Internets. Serious business.
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
@Marcel, Thanks for the post. Here are my suggestions: - Please make 'concrete' API examples(few POSTs and few GETs) with actual requests. - Make a list common-mistakes that a developer might make while he develops twitter appln(you know.. encoding, not-double-encoding, use additional-params-for-signature-generation-if-any etc) - A oauth sandbox where it throws precise errors/feedbacks for developers to debug and test their apps would be very helpful as well. On Jul 28, 10:57 am, Marcel Molina mar...@twitter.com wrote: As many of you have since learned, we deployed an unannounced security fix that has resulted in unexpected failures for quite a few developers using OAuth. A developer reported to us that OAuth signatures were not being verified on our side. The fix was implemented and pushed on Sunday then deployed yesterday. Once the fix was in the wild many applications started returning Invalid Signature errors. Our various successful tests seem to indicate that the signature verification is implemented correctly and yet many people are experiencing errors. So what's going on? One of the main problems seems to be that many OAuth libraries appear to not be generating correctly signed requests. It's likely that Twitter's implementation was used to test out many of these libraries when they were being implemented. Without the correct signature check, it appeared to these developers that their libraries were implementing the spec correctly. For this confusion we must take at least partial blame. The following email from Simon in the UK seems to indicate absent url encoding and decoding is a likely culprit in many of these libraries: I don't myself think that twitter are doing anything more than enforcing the standard. I spent 3 hours 'fixing' my code for our application (uses Shannon Whitley's c# library as a base); I only found two bugs in thelibrary that caused any problem... the use of httputility.urlencode in place of the modified urlencode already implemented for use with Oauth, as required by the spec... the library just wasn't using it in two places. Following that, I found I was passing some bad strings to the library... so the methods in it were not urldecoding and re- urlencoding the postdata as required to get it to meet the spec. Once I fixed that also, all seems good. So if our app now posts all data fine over Oauth, it suggests that twitter's interface is OK? There are at least several things we could have done better in dealing with this: * We should have, it goes without saying, had more extensive test coverage of our implementation ensuring that we were fully implementing the spec so that the whole situation would have been avoided in the first place. * We should have had an email prepared to send out immediately following the deploy explaining the vulnerability and the change that was deployed, encouraging developers to double check that their signatures were in fact being generated correctly. We left a lot of people guessing for half a day, in many cases probably frantically trying to fix mysterious failures in their apps. For that we must admit guilt. We hadn't anticipated that so many libraries might have not been generating signatures correctly. As a result it didn't occur to us to urgently send out details, assuming fully implemented libraries would continue to work transparently and malicious requests would start to fail. We had been focusing our efforts first and foremost on getting the fix implemented and deployed to protect everyone. Lesson learned. We'll take this experience with us and bring it to bear next time such a situation arises. We're going to do a post-mortem on our side to identify all the things we should have done better. We've read all of your feedback about how this could have been done better. To everyone who has chimed into this thread offering details and help, we extend our thanks. On Tue, Jul 28, 2009 at 10:28 AM, Abraham Williams 4bra...@gmail.comwrote: If you are encoding properly according to: http://oauth.net/core/1.0a#encoding_parametersand it still fails to update post and update to http://code.google.com/p/twitter-api/issues/entryand make Twitter fix it. I've not double checked to verify but ! should encode to %21 and then it should work. Abraham On Tue, Jul 28, 2009 at 10:06, Duane Roelands duane.roela...@gmail.comwrote: Yeah, that's what I'm doing as well. I wish Twitter would give us some answers. I can post a tweet is the text is test If I try to post test!, it fails. Something about the encoding of non-alphanumeric characters is part of the problem. But, because Twitter isn't talking, all we can do is guess. On Jul 28, 12:52 pm, Cristovão Morgado cristovao.morg...@gmail.com wrote: I use this implementation: http://www.codingthewheel.com/archives/codingthetweet works flawlessly! On Tue, Jul 28, 2009 at 5:47 PM, Duane Roelands
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
@Marcel, Thanks for the post. Here are my suggestions: - Please make 'concrete' API examples(few POSTs and few GETs) with actual requests. - Make a list common-mistakes that a developer might make while he develops twitter appln(you know.. encoding, not-double-encoding, use additional-params-for-signature-generation-if-any etc) - A oauth sandbox where it throws precise errors/feedbacks for developers to debug and test their apps would be very helpful as well. I think these are excellent ideas. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- In memory of Werner Klemperer --
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
* We should have, it goes without saying, had more extensive test coverage of our implementation ensuring that we were fully implementing the spec so that the whole situation would have been avoided in the first place. More testing is always a good goal if feasible. However, no spec is perfectly complete, thus no spec is perfectly stable. And no implementation is perfect, thus no implementation is perfectly stable. Suggesting that your implementation be perfect next time as a solution to your current instability might not be the best takeaway here. It seems to me that the takeaway is that instability exists and our (twitter and the dev community) system for dealing with it was too fragile. Being constructive: Perhaps an API release mechanism that can withstand a bit of instability is worth investigating. * We should have had an email prepared to send out immediately following the deploy explaining the vulnerability and the change that was deployed, encouraging developers to double check that their signatures were in fact being generated correctly. While I don't disagree at all, why wait until after? While the number of apps that use the twitter api is many, the number of libraries is few. Perhaps a private list to their primary maintainers is worth investigation. Even if it was just the primaries from the list of libraries on your site: http://apiwiki.twitter.com/OAuth-Examples They might have given you a little warning of the likely panic. Perhaps not enough time to change, but at least enough time to soften the blow with some information. We're going to do a post-mortem on our side to identify all the things we should have done better. We've read all of your feedback about how this could have been done better. To everyone who has chimed into this thread offering details and help, we extend our thanks. Not to let this post get too technical -- but my current released code ( OAuth_ObjC_Test_App ) seems to work (e.g. it checks and posts without any problems that I notice), however I'm not entirely sure what corner cases might trigger the failures. If anyone has an idea of what regressions to run, I'd appreciate any info. Thanks. Isaiah
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
oh god yes. ESPECIALLY the last one. On Tue, Jul 28, 2009 at 12:22, Cameron Kaiser spec...@floodgap.com wrote: @Marcel, Thanks for the post. Here are my suggestions: - Please make 'concrete' API examples(few POSTs and few GETs) with actual requests. - Make a list common-mistakes that a developer might make while he develops twitter appln(you know.. encoding, not-double-encoding, use additional-params-for-signature-generation-if-any etc) - A oauth sandbox where it throws precise errors/feedbacks for developers to debug and test their apps would be very helpful as well. I think these are excellent ideas. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- In memory of Werner Klemperer -- -- Internets. Serious business.
[twitter-dev] Re: Failed to validate oauth signature and token
Hi You might have got the samples along with jscript libraries (eg requestToken.html , authorize.html etc ). They are working fine . Just replace the consumer keys and secrets with yours in consumer.js One more change is add the 'oauth_verifier' field in accessToken.html (make sure you trim the trailing whitespace while pasting the value) The sample code provided in Ajax.html is also working fine and i verified with some twitter methods Good luck Srikanth On Tue, Jul 28, 2009 at 10:52 PM, Rock vinoth.nit...@gmail.com wrote: Hello All, I am new to twitter development. I am developing a twitter client for Nokia S60 devices. I wanted to make use of OAuth sign in provided by twitter. I have my customer key and customer secret. However when i try to get the token i receive Failed to validate oauth signature and token message. Also i have come across oauth.js. Since i am new to javascript as well i feel bit difficult to track it. Is there any site which explains on how to use this script. My url to request token from twitter is as shown below. http://twitter.com/oauth/request_token?oauth_version=1.01248801338cdxAC3T2J6Lro7oauth_consumer_key=UoK2gkoRexTkoZy1fBvggoauth_signature_method=HMAC_SHA1oauth_signature=d1AxaPrUbj6RsjXvHM0WkzGujsBz9k4HzFztlhVzbo Thanks in advance.
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
I haven't done any comprehensive profiling of them. (As well, my particular presentation of the OAuth or Basic login options also may confound the data.) That said, the fact that any sub-population of Twitter users shows a preference for Basic Auth is surprising. I suggest that linking another app to one's Twitter account is foreign and difficult for the average person to understand. The OAuth scare page presented by Twitter doesn't help. It clearly hasn't been split-tested and is poorly executed. It is likely responsible for a significant number of desertions. Compare it, for example, to the Facebook app auth page. Twitter's DENY button is just as big as the ALLOW button; Facebook offers approve and then a much smaller cancel link. Add in the current complexity and unreliability of Twitter OAuth, and, at the very least, offering Basic Auth as an adjunct option seems to make sense. On Jul 28, 11:15 am, JDG ghil...@gmail.com wrote: What do you know about your sample, other than they use your app? Are they technically savvy? Mindful of their security? Do they often click on links from Paypal in their email? Do they have friends in Nigeria that are willing to send them money? I think that is the statistical significance to which TjL was referring. At least, I hope so. On Tue, Jul 28, 2009 at 12:12, chinaski007 chinaski...@gmail.com wrote: Sorry about that... I deleted those threads before posting this one. I gather you are choosing to receive emails individually. The tests were statistically significant at 95% confidence levels. On Jul 28, 8:09 am, TjL luo...@gmail.com wrote: On Tue, Jul 28, 2009 at 7:27 AM, chinaski007chinaski...@gmail.com wrote: [the same post three different times] WE GET IT. YOU DON'T LIKE OAUTH. Your (probably statistically insignificant) tests with Google Optimizer reveal that your users are more likely to sign-up for Basic Auth than OAuth. WE GET IT. Did you need to start three different threads to say exactly the same thing on the same day? -- Internets. Serious business.
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
+1. Unfortunately i have to agree. I´m working with mobile twitter applications and oauth is far for been a good solution. I really hope that twitter team provide us a better solutions to work with mobile or embedded environments where the web browser may not be available or have a limited support. regards, Otávio Ribeiro On Tue, Jul 28, 2009 at 8:27 AM, chinaski007 chinaski...@gmail.com wrote: Let's be honest... The end-result for third-party developers using OAuth appears to be fewer sign-ups, less reliability, more complexity, and potentially less security. Google Optimizer reveals that users are more likely to sign-up for Basic Auth than OAuth. That's just fact. Test it for yourself to confirm. I suppose this is not so weird. Users are accustomed to giving user/ pass information even to foreign apps. It is far more disruptive and invasive for them to go to some bizarre Twitter screen asking them to approve an app. To the average user, what does that mean? (And, heck, it may even require more steps if they have to login again to Twitter.) In terms of reliability, Twitter OAuth was down for days several weeks ago. Tonight yet another unannounced change occurred that broke major code libraries. Meanwhile, Basic Auth has been plugging along just fine and dandy... So what IS the benefit of OAuth? It doesn't benefit developers as you will likely get more sign-ups with Basic Auth and Basic Auth is far, far easier to setup. Sure, OAuth might satisfy some power users hungry for security... But is OAuth even more secure than Basic Auth? Perhaps not. After all, tonight's fix was for an OAuth security flaw known for at least 10+ days (judging by tweets to @twitterapi) that allowed for potential impersonations of credentialed users. On the heels of Twitter's (unofficial) assurance of better communication with developers, this sort of unannounced change is distressing. What's next? (Have Labor Day Weekend plans? You might want to cancel those... just the right time for Twitter to make an unannounced API change!) As for us, we are in the strange position of deprecating OAuth in favor of Basic Auth. Weird, eh?? Okay, we are not totally deprecating OAuth, but we are advising users that Basic Auth is far more robust and reliable. And so our message to new developers: avoid OAuth like the plague. If you must, offer it. But let Basic Auth be your backbone: more reliable, more sign-ups, simpler, and probably just as secure. (Just look at Google Code bug reports about OAuth to get a sense of reliablity.) (Okay, okay, this post was written at 4am after a workday that started at 8am, and after Twitter introduced this new change at 5pm... (hey Twitter, can you introduce major new changes EARLIER in the day so we can react!?!?)... it still doesn't excuse Twitter's continued disregard for the small-to-medium size developer.)
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
On Tue, Jul 28, 2009 at 2:49 PM, chinaski007 chinaski...@gmail.com wrote: I haven't done any comprehensive profiling of them. (As well, my particular presentation of the OAuth or Basic login options also may confound the data.) That said, the fact that any sub-population of Twitter users shows a preference for Basic Auth is surprising. I suggest that linking another app to one's Twitter account is foreign and difficult for the average person to understand. The OAuth scare page presented by Twitter doesn't help. It clearly hasn't been split-tested and is poorly executed. It is likely responsible for a significant number of desertions. Compare it, for example, to the Facebook app auth page. Twitter's DENY button is just as big as the ALLOW button; Facebook offers approve and then a much smaller cancel link. Add in the current complexity and unreliability of Twitter OAuth, and, at the very least, offering Basic Auth as an adjunct option seems to make sense. OAuth IS unfamiliar, YES. OAuth DOES ask more of the user, YES. Like anything else new in technology, the better you educate your user, both implicitly and explicitly, about the process, the better the adoption rate is bound to be for a useful or required innovation. In other words, handholding and spoonfeeding your users through the OAuth process is going to give you better conversion rates than simply bouncing them to Twitter with little or no notification or education. --ab
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
OAuth IS unfamiliar, YES. OAuth DOES ask more of the user, YES. So what's the upside for the third-party developer? In terms of security, we've already seen how OAuth-like applications in, e.g., Facebook have led to massive hacker/phishing/etc problems. While OAuth solves one leg of the security problem (not actually having their password), OAuth'd apps still have complete API access to the account and can run rampant before the user realizes or figures out how to revoke credentials.
[twitter-dev] Re: API only shows messages from last 7 days
I don't think that adding more people to the staff at Twitter is the solution. In one startup I saw a thing posted on the refrigerator that had the adage, Adding more people to a project already behind schedule will only slow it down more. Surely for support and customer service issues having more people on the team to deal with growth is good, but I doubt throwing more programmers at it will help fix most issues. It just never seems to work that way. While many startups do tend toward younger employees (I personally think because being younger normally means that you can work a lot with minimal life impact), I'm sure that someone with a strong background would be able to get a job at Twitter if they were local to the company (or willing to move). A lot of this surely comes down to priorities inside the company. While Doug and Team want to support us developers as much as possible, much of our initial 'value' that we've offered in helping push twitter to the masses has already happened. We aren't the core business strategy, and with a fixed amount of resources and focus they aren't working to push mainly for developer access, but for standard user access. This 100% makes sense. Users are what is going to make twitter happen, not 3rd party developers. They want to provide a stable experience on both fronts, but users come first. In my private discussions with some team members, I've gotten the sense that they have good stuff in the pipeline for us and that they are working hard to make it happen. However we're only a small part of the overall strategy of a quickly growing company that is still dealing with massive growing pains which is no fault of theirs and something they are dealing with as best they can. david On Jul 28, 1:46 pm, owkaye owk...@gmail.com wrote: I'm sure others feel the same way Dave, but it looks and feels like Twitter is moving in the opposite direction. The load on a server to extract a big dataset once a month would be minimal, and both you and I can see the value in this approach. But I'm not sure the folks at Twitter do, or if they do maybe they just don't have the people who can (and will) get things like this implemented. Is a shortage of competent staff the cause of this type of problem? Even though I have the capabilities I do not have the 'resume' to get a job there and help them deal with some of this stuff, nor do I have the contacts within the Twitter organization to put a good word in for me and help me get hired so I could do good things for them. I'm 52 years old too, and my age seems to be a negative to most of the Web 2.x companies hiring these days. This is kind of a shame considering that people like me frequently have broader-based experience and insights that are sometimes lacking in younger people, and because of this we can add a lot more value in the areas of planning and structural development than people half our age. Our coding skills are honed after so many years of experience too, not to mention the thousands of code snippets we have collected over the years to contribute to making us even faster. But since jobs like this are basically not open to me and many other folks my age, my alternative is to remain self- employed and try to build something on top of their existing available source data and API's ... and then deal with the issues and frustrations created when building a service on top of a 'moving target' that sometimes seems to be moving in funny directions. I hear about Twitter having lots of money to work with, and I'm probably wrong here but it almost seems like there's too little of this money being dedicated to paying new talent with long term views of some of these issues, and who will implement wise policies to help support and encourage rapid growth in the areas that are lacking. But once again this might just be due to a shortage of the right staff. Obviously we cannot do anything from the outside except point out these issues and ask questions, or beg and plead for changes, but it sure would be great if a few of us could actually get in there as employees and implement a couple of the new features we really need -- such as a new Historical Search API for example. Then developers like you and I could proceed with some of our plans now, instead of months or years from now ... or possibly never. I would love to lead a team on a project like this, or even be one of its members, but until it happens I'll focus on building my own little space in the Twitter universe and continue to hope for the best. :) Owkaye I would do anything (including paying good amounts of money) to be able to purchase access to older datasets that I could transfer to my database through non-rest-api methods. I'm envisioning being able to download a CSV or SQL file that I could merge with my database easily, but only have to make a single request to the server to get a month of data.
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
Ugh, terrible situation here. Things working 99.9% of the time now with Perl. But we continue to get bizarre intermittent errors that span the range of API calls. We are thinking that internal hash re- ordering may invalidate signatures, but that is just speculation.
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
If it works 99.9% of the times and breaks intermittently, its 1000% encoding issue and nothing else - your signature or some-data is having few characters that's not encoded in that particular instance. On Jul 28, 12:36 pm, chinaski007 chinaski...@gmail.com wrote: Ugh, terrible situation here. Things working 99.9% of the time now with Perl. But we continue to get bizarre intermittent errors that span the range of API calls. We are thinking that internal hash re- ordering may invalidate signatures, but that is just speculation.
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
Sorry about your Oauth Implementation, Mine's been working steadily with no hiccups: Lot's of very solid implementations out there. As far as the user sign-up problem, Yeah, I agree, It's a bit of a scare for the user to have to connect to an off-site twitter authority page -- But that's what Facebook, paypal and all the big boys are pushing toward. As Robert Palmer once said: Your gonna have to face it, your addicted to passwords. Jim On Jul 28, 1:27 am, chinaski007 chinaski...@gmail.com wrote: Let's be honest... The end-result for third-party developers using OAuth appears to be fewer sign-ups, less reliability, more complexity, and potentially less security. Google Optimizer reveals that users are more likely to sign-up for Basic Auth than OAuth. That's just fact. Test it for yourself to confirm. I suppose this is not so weird. Users are accustomed to giving user/ pass information even to foreign apps. It is far more disruptive and invasive for them to go to some bizarre Twitter screen asking them to approve an app. To the average user, what does that mean? (And, heck, it may even require more steps if they have to login again to Twitter.) In terms of reliability, Twitter OAuth was down for days several weeks ago. Tonight yet another unannounced change occurred that broke major code libraries. Meanwhile, Basic Auth has been plugging along just fine and dandy... So what IS the benefit of OAuth? It doesn't benefit developers as you will likely get more sign-ups with Basic Auth and Basic Auth is far, far easier to setup. Sure, OAuth might satisfy some power users hungry for security... But is OAuth even more secure than Basic Auth? Perhaps not. After all, tonight's fix was for an OAuth security flaw known for at least 10+ days (judging by tweets to @twitterapi) that allowed for potential impersonations of credentialed users. On the heels of Twitter's (unofficial) assurance of better communication with developers, this sort of unannounced change is distressing. What's next? (Have Labor Day Weekend plans? You might want to cancel those... just the right time for Twitter to make an unannounced API change!) As for us, we are in the strange position of deprecating OAuth in favor of Basic Auth. Weird, eh?? Okay, we are not totally deprecating OAuth, but we are advising users that Basic Auth is far more robust and reliable. And so our message to new developers: avoid OAuth like the plague. If you must, offer it. But let Basic Auth be your backbone: more reliable, more sign-ups, simpler, and probably just as secure. (Just look at Google Code bug reports about OAuth to get a sense of reliablity.) (Okay, okay, this post was written at 4am after a workday that started at 8am, and after Twitter introduced this new change at 5pm... (hey Twitter, can you introduce major new changes EARLIER in the day so we can react!?!?)... it still doesn't excuse Twitter's continued disregard for the small-to-medium size developer.)
[twitter-dev] Re: Failed to validate oauth signature and token
Thanks srikanth. It worked :-)
[twitter-dev] Re: Twitter: What did you change in OAuth?
I am signing with both secrets too, and have upper case urlencoding.
Signing requests with an empty token secret (i.e. when getting
original request token) work 100%
I am doing the following to obtain the hmac key:
$key = rawurlencode($this-consumer_secret).''.rawurlencode($this-
token_secret);
when token_secret is an empty string - no probs!
Example request:
GET /statuses/followers.json?
screen_name=timwhitlockpage=1oauth_consumer_key=[removed]
oauth_nonce=1248788126.331844oauth_signature_method=HMAC-
SHA1oauth_timestamp=1248788126oauth_token=[removed]
oauth_version=1.0oauth_signature=bGLpUe4LisXrn1ffGIafwod54ZE%3D HTTP/
1.0
PHP source code snippet:
public function sign_hmac( $http_method, $http_rsc ){
$this-args['oauth_signature_method'] = 'HMAC-SHA1';
$this-args['oauth_timestamp'] = sprintf('%u', time() );
$this-args['oauth_nonce'] = sprintf('%f', microtime(true) );
// normalize args first
unset( $this-args['oauth_signature'] );
$str = $this-__toString();
// prepend other values, double-encoding the args
$str = strtoupper($http_method).''.rawurlencode
($http_rsc).''.rawurlencode($str);
// sign it
$key =
rawurlencode($this-consumer_secret).''.rawurlencode($this-
token_secret);
$this-args['oauth_signature'] = base64_encode( hash_hmac(
'sha1',
$str, $key, true ) );
return parent::serialize( $this-args );
}
[twitter-dev] Re: ASP .NET Development Issue w/OAuth Callback Parameter
AB, I'm using http://localhost as my call back parameter. But, Twitter just sends me back to my registered application site http://www.populartweets.com -Matt On Jul 27, 8:49 pm, Andrew Badera and...@badera.us wrote: On Mon, Jul 27, 2009 at 6:49 PM, mattarnold1977 matt.arnold.1...@gmail.comwrote: I've been able to create a successful web request to receive an auth token from Twitter. However, Twitter is not sending me back to my development environment even though I have put the oauth_callback parameter on my request. It even shows my call back parameter in the URL on the Twitter oAuth authentication page. I'm wondering if anyone else is using VS 08 (ASP .NET) as their development environment and were able to successfully get the oAuth call back parameter to redirect back to their development environment? -Matt As I think I'd mentioned off-list, I'm able to redirect no problem, using VS05 or VS08 or even VS10 VPC. I'm able to default to my registered callback, and I'm able to provide an oauth_callback value for testing (localhost) that works without difficulty. What oauth_callback value are you providing, and what URL are you ending up at? --ab
[twitter-dev] Re: Potential Solution To OAuth Problem
Sorry, no. I'm using rawurlencode in PHP, which encodes %20 still failing. // snip $key = rawurlencode($this-consumer_secret).''.rawurlencode($this- token_secret); $this-args['oauth_signature'] = base64_encode( hash_hmac( 'sha1', $str, $key, true ) ); // snip
[twitter-dev] Re: ASP .NET Development Issue w/OAuth Callback Parameter
Hello Abraham, Thanks for helping me out. I was using a different code before and then I used your code and it works like a charm. Thanks for making that code so simple. regards R On Mon, Jul 27, 2009 at 4:10 PM, Abraham Williams 4bra...@gmail.com wrote: Are you adding oauth_callback to the oauth/request_token call? Along with the request_token you should be getting an oauth_callback_confirmed=true. Passing a callback url with a user when they go to authorize access does not work anymore: http://groups.google.com/group/twitter-api-announce/browse_frm/thread/472500cfe9e7cdb9?hl=en Abraham On Mon, Jul 27, 2009 at 15:49, mattarnold1977 matt.arnold.1...@gmail.comwrote: I've been able to create a successful web request to receive an auth token from Twitter. However, Twitter is not sending me back to my development environment even though I have put the oauth_callback parameter on my request. It even shows my call back parameter in the URL on the Twitter oAuth authentication page. I'm wondering if anyone else is using VS 08 (ASP .NET) as their development environment and were able to successfully get the oAuth call back parameter to redirect back to their development environment? -Matt -- Abraham Williams | Community Evangelist | http://web608.org Hacker | http://abrah.am | http://twitter.com/abraham Project | http://fireeagle.labs.poseurtech.com This email is: [ ] blogable [x] ask first [ ] private.
[twitter-dev] Re: oAuth .NET receiving Unauthorized Error (401)
Matt, Try to register a new application for your development environment. I know it sounds not smart, but I guess it is a simple way to achieve. I think twitter did the same to me , when I tired to change the call back url. regards R On Sun, Jul 26, 2009 at 1:50 PM, mattarnold1977 matt.arnold.1...@gmail.comwrote: Andy, That was it! Sorting my parameters did the trick. After that I was able to successfully post a web request to Twitter's OAuth request token URL. Now, the next problem. I'm working in a development environment and I can not get the call back argument to work correctly. I've added it as a parameter in my web request and you can see it in the URL when logging into Twitter to get the token. But, Twitter just returns me back to my application that I registered with them (not my development environment that I've setup in my call back argument). -Matt On Jul 26, 4:55 am, Andrew Badera and...@badera.us wrote: On Sat, Jul 25, 2009 at 6:46 PM, mattarnold1977 matt.arnold.1...@gmail.comwrote: Bojan, Thanks for the reply. I'm using ASP .NET. -Matt I suspect Bojan was more curious about what OAuth library you're using. If you're doing it on your own, allow me to suggest DotNetOpenAuth instead. Also, are you sorting your parameters correctly? Non-alphabetized sort of parameters prior to signing will give you a 401. Thanks- - Andy Badera - and...@badera.us - Google me:http://www.google.com/search?q=andrew+badera - This email is: [ ] bloggable [x] ask first [ ] private
[twitter-dev] Status Id question
Quick question from a a newbie to the API development. Is there a way to connect a reply to a status update to the original message? i.e. if Joe posts - who has a red car? many people can reply to this message which is all public. then after 4 hours Mary replies to that post and says - i do.. however, since Joe receives many many updates because he has thousands of followers, he don't know why Mary is saying i do after 4 hours. Is there a way to take a look at Mary's status update with the message I do and connect it to Joe's original question who has a red car? I only find status id and not reply_to_status_id. Any help would be appreciated. Thanks, Guna
[twitter-dev] Re: Status Id question
Guna,Check into the in_reply_to_status_id parameter for the statuses/update method [1]: in_reply_to_status_id. Optional. The ID of an existing status that the update is in reply to. - Note: This parameter will be ignored unless the author of the tweet this parameter references is mentioned within the status text. Therefore, you must include @username, where username is the author of the referenced tweet, within the update. 1. http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses%C2%A0update Thanks, Doug On Tue, Jul 28, 2009 at 8:26 AM, Guna gdeivend...@gmail.com wrote: Quick question from a a newbie to the API development. Is there a way to connect a reply to a status update to the original message? i.e. if Joe posts - who has a red car? many people can reply to this message which is all public. then after 4 hours Mary replies to that post and says - i do.. however, since Joe receives many many updates because he has thousands of followers, he don't know why Mary is saying i do after 4 hours. Is there a way to take a look at Mary's status update with the message I do and connect it to Joe's original question who has a red car? I only find status id and not reply_to_status_id. Any help would be appreciated. Thanks, Guna
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
It's only a scare if the development community neglects or refuses to educate the populace at large that only Twitter really needs your password, so why give it to anyone else? On Tue, Jul 28, 2009 at 13:27, jahbini jahb...@celarien.com wrote: Sorry about your Oauth Implementation, Mine's been working steadily with no hiccups: Lot's of very solid implementations out there. As far as the user sign-up problem, Yeah, I agree, It's a bit of a scare for the user to have to connect to an off-site twitter authority page -- But that's what Facebook, paypal and all the big boys are pushing toward. As Robert Palmer once said: Your gonna have to face it, your addicted to passwords. Jim On Jul 28, 1:27 am, chinaski007 chinaski...@gmail.com wrote: Let's be honest... The end-result for third-party developers using OAuth appears to be fewer sign-ups, less reliability, more complexity, and potentially less security. Google Optimizer reveals that users are more likely to sign-up for Basic Auth than OAuth. That's just fact. Test it for yourself to confirm. I suppose this is not so weird. Users are accustomed to giving user/ pass information even to foreign apps. It is far more disruptive and invasive for them to go to some bizarre Twitter screen asking them to approve an app. To the average user, what does that mean? (And, heck, it may even require more steps if they have to login again to Twitter.) In terms of reliability, Twitter OAuth was down for days several weeks ago. Tonight yet another unannounced change occurred that broke major code libraries. Meanwhile, Basic Auth has been plugging along just fine and dandy... So what IS the benefit of OAuth? It doesn't benefit developers as you will likely get more sign-ups with Basic Auth and Basic Auth is far, far easier to setup. Sure, OAuth might satisfy some power users hungry for security... But is OAuth even more secure than Basic Auth? Perhaps not. After all, tonight's fix was for an OAuth security flaw known for at least 10+ days (judging by tweets to @twitterapi) that allowed for potential impersonations of credentialed users. On the heels of Twitter's (unofficial) assurance of better communication with developers, this sort of unannounced change is distressing. What's next? (Have Labor Day Weekend plans? You might want to cancel those... just the right time for Twitter to make an unannounced API change!) As for us, we are in the strange position of deprecating OAuth in favor of Basic Auth. Weird, eh?? Okay, we are not totally deprecating OAuth, but we are advising users that Basic Auth is far more robust and reliable. And so our message to new developers: avoid OAuth like the plague. If you must, offer it. But let Basic Auth be your backbone: more reliable, more sign-ups, simpler, and probably just as secure. (Just look at Google Code bug reports about OAuth to get a sense of reliablity.) (Okay, okay, this post was written at 4am after a workday that started at 8am, and after Twitter introduced this new change at 5pm... (hey Twitter, can you introduce major new changes EARLIER in the day so we can react!?!?)... it still doesn't excuse Twitter's continued disregard for the small-to-medium size developer.) -- Internets. Serious business.
[twitter-dev] Re: Stats on what % of users complete the oauth flow
When you say 95%, do you derive that percentage from the number of people who click on access via OAuth (or whatever) and then Allow the authorization? Or do you mean 95% of the unauthenticated who visit your particular page authenticate via OAuth? On Jul 28, 1:08 pm, jmathai jmat...@gmail.com wrote: I was surprised to find out that 95% of our users (sample set of a couple hundred) complete the oauth flow and approve access to at least one twitter account. What experiences have other developers had in relation to this? More information:http://publicitweet.wordpress.com/2009/07/28/95-of-publicitweet-users...
[twitter-dev] Twitter counts wrong the number of followers
Hi, everybody I'm working on a application! My account has 19648 followers! When using users/show, i get the followers 19648! But when i start to get followers from API! I can just get to 101 pages (the rest page is empty with no users at all)! That says that i just have 101x100=10100 followrs! Then i try to check with: http://twitter.com/Mrlandmark/followers?page=1 I got 502 page! Each page has 20 member! = i actually have ~10.100 folloers! So, why tewitter API users/show return that i have 19648 and on my profile page, it displays 19648 members! I don't know to correct this? Or is this a bug of Twitter? Thank you!
[twitter-dev] Re: Potential Solution To OAuth Problem
The + - %20 solution seems to work for me. I am writing my own OAuth library in Java, and java.net.URLEncoder encodes the space character to +. There could be a better way, but replacing the resulted + with %20, status update on Twitter now seems to work.
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
As a developer who has recent launched Twaller (http:// www.twaller.com) which supports OAuth, I think I should share my perspective on this. I really loved OAuth because: (1) Ease of coding. I could get OAuth working within a couple of days. Saves me any password maintenance, encryption etc. (2) Integration with Twitter Branding. With the OAuth scheme, I believe my website is more integrated with Twitter. It would also be nicer if Twitter would maintain their own list of websites they trust with Oauth, just to give users the added confidence that Twitter trusts me. (3) Saves me worrying about SSL. A lot of people are finicky about HTTPS/SSL. This was I can just ytell them that if Twitter wants Oauth that way in future, we will simple provide it. The part I hate about OAuth is that the OAUth page is extremely slow to load and sometimes does not load at all. I see this issue with the Twitter website in general as well, sometime postst from the web just don't go through. I would much appreciate if people at Twitter can address scalability problems to OAUTH, because that I believe is the biggest user turnoff. On Jul 28, 1:11 pm, JDG ghil...@gmail.com wrote: It's only a scare if the development community neglects or refuses to educate the populace at large that only Twitter really needs your password, so why give it to anyone else? On Tue, Jul 28, 2009 at 13:27, jahbini jahb...@celarien.com wrote: Sorry about your Oauth Implementation, Mine's been working steadily with no hiccups: Lot's of very solid implementations out there. As far as the user sign-up problem, Yeah, I agree, It's a bit of a scare for the user to have to connect to an off-site twitter authority page -- But that's what Facebook, paypal and all the big boys are pushing toward. As Robert Palmer once said: Your gonna have to face it, your addicted to passwords. Jim On Jul 28, 1:27 am, chinaski007 chinaski...@gmail.com wrote: Let's be honest... The end-result for third-party developers using OAuth appears to be fewer sign-ups, less reliability, more complexity, and potentially less security. Google Optimizer reveals that users are more likely to sign-up for Basic Auth than OAuth. That's just fact. Test it for yourself to confirm. I suppose this is not so weird. Users are accustomed to giving user/ pass information even to foreign apps. It is far more disruptive and invasive for them to go to some bizarre Twitter screen asking them to approve an app. To the average user, what does that mean? (And, heck, it may even require more steps if they have to login again to Twitter.) In terms of reliability, Twitter OAuth was down for days several weeks ago. Tonight yet another unannounced change occurred that broke major code libraries. Meanwhile, Basic Auth has been plugging along just fine and dandy... So what IS the benefit of OAuth? It doesn't benefit developers as you will likely get more sign-ups with Basic Auth and Basic Auth is far, far easier to setup. Sure, OAuth might satisfy some power users hungry for security... But is OAuth even more secure than Basic Auth? Perhaps not. After all, tonight's fix was for an OAuth security flaw known for at least 10+ days (judging by tweets to @twitterapi) that allowed for potential impersonations of credentialed users. On the heels of Twitter's (unofficial) assurance of better communication with developers, this sort of unannounced change is distressing. What's next? (Have Labor Day Weekend plans? You might want to cancel those... just the right time for Twitter to make an unannounced API change!) As for us, we are in the strange position of deprecating OAuth in favor of Basic Auth. Weird, eh?? Okay, we are not totally deprecating OAuth, but we are advising users that Basic Auth is far more robust and reliable. And so our message to new developers: avoid OAuth like the plague. If you must, offer it. But let Basic Auth be your backbone: more reliable, more sign-ups, simpler, and probably just as secure. (Just look at Google Code bug reports about OAuth to get a sense of reliablity.) (Okay, okay, this post was written at 4am after a workday that started at 8am, and after Twitter introduced this new change at 5pm... (hey Twitter, can you introduce major new changes EARLIER in the day so we can react!?!?)... it still doesn't excuse Twitter's continued disregard for the small-to-medium size developer.) -- Internets. Serious business.
[twitter-dev] Re: search.twitter.com only returns 30 days of content?
I can see the restriction here: http://apiwiki.twitter.com/Twitter-Search-API-Method%3A-search Ouch -- that's just a silly. What people have said in the past is important. In the future it would be great for twitter to remove this restriction and offer historical data. On Jul 27, 5:38 pm, Doug Williams d...@twitter.com wrote: No. We currently only return around 7 days of data with search. You can learn more about this, and the reasons behind it, in our Getting Started materials provided on apiwiki.twitter.com. Thanks, Doug On Mon, Jul 27, 2009 at 2:23 PM, jms justen.ste...@gmail.com wrote: We recently hosted conference attendees used twitter to stay in touch. We had been pulling in an RSS hash feed of the event and displaying the comments on our website as part of a post social aspect of the conference. Recently I noticed that the comments stopped showing up on the RSS feed... from what I can tell the tweets are disappearing after 30 days. The last comment on the matter has likely been posted, however we'd like to keep the tweets on our website for those returning to the site, however the data isn't there. Is there a way to get this historical data?
[twitter-dev] Twitter + OAuth for iPhone
If anyone is interested, I've implemented Twitter OAuth on iPhone (which includes an iPhone version of the OAuth static lib). It's on GitHub: http://github.com/bengottlieb/Twitter-OAuth-iPhone/tree/master
[twitter-dev] URI Escape fix for OAuth - correct usage of uri_escape() with Perl
This post is geared toward Perl implementations of OAuth, though it may shed some light on recent URI escape problems in other languages as well. use Encode qw(encode); use URI::Escape; I previously had been escaping my parameters with a call such as: my $value = uri_escape(encode(UTF-8,$param)); The encode() call was encoding the $param as UTF-8 octets before percent encoding with uri_escape(). The use of uri_escape() above is NOT correct to meet the requirements of the OAuth spec. The following is the explanation and fix: # OAUTH spec URI encoding # = # # http://oauth.net/core/1.0a#encoding_parameters # with reference to # http://tools.ietf.org/html/rfc3986#section-2.3 # # 5.1. Parameter Encoding # # All parameter names and values are escaped using the [RFC3986] # percent-encoding (%xx) mechanism. Characters not in the unreserved character # set MUST be encoded. Characters in the unreserved character # set MUST NOT be encoded. Hexadecimal characters in encodings MUST be upper case. # Text names and values MUST be encoded as UTF-8 octets before percent-encoding # them per [RFC3629] # # unreserved = ALPHA, DIGIT, '-', '.', '_', '~' # # # URI::Escape # = # http://search.cpan.org/~gaas/URI-1.38/URI/Escape.pm # uri_escape() by default encodes # ^A-Za-z0-9\-_.!~*'() # # We must subtract from this the reserved characters: ! * ' ( ) # ^A-Za-z0-9\-_.~ # The correct assignment in Perl is thus: my $value = uri_escape(encode(UTF-8,$param),^A-Za-z0-9\-_.~); I've tested this and it fixed the problems I was having sending characters ! * etc. I suspect percent encoding in other languages may need a similar implementation. - Scott @scott_carter http://www.bigtweet.com/
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
I think goodtest is correct. Please see my post at: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/27f991f752786843?hl=en It may be relevant to your Perl problems. - Scott @scott_carter On Jul 28, 3:42 pm, goodtest goodtest...@gmail.com wrote: If it works 99.9% of the times and breaks intermittently, its 1000% encoding issue and nothing else - your signature or some-data is having few characters that's not encoded in that particular instance. On Jul 28, 12:36 pm, chinaski007 chinaski...@gmail.com wrote: Ugh, terrible situation here. Things working 99.9% of the time now with Perl. But we continue to get bizarre intermittent errors that span the range of API calls. We are thinking that internal hash re- ordering may invalidate signatures, but that is just speculation.
[twitter-dev] Re: URI Escape fix for OAuth - correct usage of uri_escape() with Perl
If you are using Net::Twitter in Perl, the developer released a new release today that now correctly handles OAuth and Unicode-related issues. http://search.cpan.org/dist/Net-Twitter/ On Jul 28, 3:21 pm, Scott Carter scarter28m-goo...@yahoo.com wrote: This post is geared toward Perl implementations of OAuth, though it may shed some light on recent URI escape problems in other languages as well. use Encode qw(encode); use URI::Escape; I previously had been escaping my parameters with a call such as: my $value = uri_escape(encode(UTF-8,$param)); The encode() call was encoding the $param as UTF-8 octets before percent encoding with uri_escape(). The use of uri_escape() above is NOT correct to meet the requirements of the OAuth spec. The following is the explanation and fix: # OAUTH spec URI encoding # = # #http://oauth.net/core/1.0a#encoding_parameters # with reference to #http://tools.ietf.org/html/rfc3986#section-2.3 # # 5.1. Parameter Encoding # # All parameter names and values are escaped using the [RFC3986] # percent-encoding (%xx) mechanism. Characters not in the unreserved character # set MUST be encoded. Characters in the unreserved character # set MUST NOT be encoded. Hexadecimal characters in encodings MUST be upper case. # Text names and values MUST be encoded as UTF-8 octets before percent-encoding # them per [RFC3629] # # unreserved = ALPHA, DIGIT, '-', '.', '_', '~' # # # URI::Escape # = #http://search.cpan.org/~gaas/URI-1.38/URI/Escape.pm # uri_escape() by default encodes # ^A-Za-z0-9\-_.!~*'() # # We must subtract from this the reserved characters: ! * ' ( ) # ^A-Za-z0-9\-_.~ # The correct assignment in Perl is thus: my $value = uri_escape(encode(UTF-8,$param),^A-Za-z0-9\-_.~); I've tested this and it fixed the problems I was having sending characters ! * etc. I suspect percent encoding in other languages may need a similar implementation. - Scott @scott_carterhttp://www.bigtweet.com/
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
Funny, I posted about our high success rate (95% of all users) with OAuth. I'm trying to get a feel for if we're fortunate, have a good flow or everyone has the same rates. http://groups.google.com/group/twitter-development-talk/browse_thread/thread/da46cd261fa13bca?hl=en On Jul 28, 2:13 pm, Amitab hiamita...@gmail.com wrote: As a developer who has recent launched Twaller (http://www.twaller.com) which supports OAuth, I think I should share my perspective on this. I really loved OAuth because: (1) Ease of coding. I could get OAuth working within a couple of days. Saves me any password maintenance, encryption etc. (2) Integration with Twitter Branding. With the OAuth scheme, I believe my website is more integrated with Twitter. It would also be nicer if Twitter would maintain their own list of websites they trust with Oauth, just to give users the added confidence that Twitter trusts me. (3) Saves me worrying about SSL. A lot of people are finicky about HTTPS/SSL. This was I can just ytell them that if Twitter wants Oauth that way in future, we will simple provide it. The part I hate about OAuth is that the OAUth page is extremely slow to load and sometimes does not load at all. I see this issue with the Twitter website in general as well, sometime postst from the web just don't go through. I would much appreciate if people at Twitter can address scalability problems to OAUTH, because that I believe is the biggest user turnoff. On Jul 28, 1:11 pm, JDG ghil...@gmail.com wrote: It's only a scare if the development community neglects or refuses to educate the populace at large that only Twitter really needs your password, so why give it to anyone else? On Tue, Jul 28, 2009 at 13:27, jahbini jahb...@celarien.com wrote: Sorry about your Oauth Implementation, Mine's been working steadily with no hiccups: Lot's of very solid implementations out there. As far as the user sign-up problem, Yeah, I agree, It's a bit of a scare for the user to have to connect to an off-site twitter authority page -- But that's what Facebook, paypal and all the big boys are pushing toward. As Robert Palmer once said: Your gonna have to face it, your addicted to passwords. Jim On Jul 28, 1:27 am, chinaski007 chinaski...@gmail.com wrote: Let's be honest... The end-result for third-party developers using OAuth appears to be fewer sign-ups, less reliability, more complexity, and potentially less security. Google Optimizer reveals that users are more likely to sign-up for Basic Auth than OAuth. That's just fact. Test it for yourself to confirm. I suppose this is not so weird. Users are accustomed to giving user/ pass information even to foreign apps. It is far more disruptive and invasive for them to go to some bizarre Twitter screen asking them to approve an app. To the average user, what does that mean? (And, heck, it may even require more steps if they have to login again to Twitter.) In terms of reliability, Twitter OAuth was down for days several weeks ago. Tonight yet another unannounced change occurred that broke major code libraries. Meanwhile, Basic Auth has been plugging along just fine and dandy... So what IS the benefit of OAuth? It doesn't benefit developers as you will likely get more sign-ups with Basic Auth and Basic Auth is far, far easier to setup. Sure, OAuth might satisfy some power users hungry for security... But is OAuth even more secure than Basic Auth? Perhaps not. After all, tonight's fix was for an OAuth security flaw known for at least 10+ days (judging by tweets to @twitterapi) that allowed for potential impersonations of credentialed users. On the heels of Twitter's (unofficial) assurance of better communication with developers, this sort of unannounced change is distressing. What's next? (Have Labor Day Weekend plans? You might want to cancel those... just the right time for Twitter to make an unannounced API change!) As for us, we are in the strange position of deprecating OAuth in favor of Basic Auth. Weird, eh?? Okay, we are not totally deprecating OAuth, but we are advising users that Basic Auth is far more robust and reliable. And so our message to new developers: avoid OAuth like the plague. If you must, offer it. But let Basic Auth be your backbone: more reliable, more sign-ups, simpler, and probably just as secure. (Just look at Google Code bug reports about OAuth to get a sense of reliablity.) (Okay, okay, this post was written at 4am after a workday that started at 8am, and after Twitter introduced this new change at 5pm... (hey Twitter, can you introduce major new changes EARLIER in the day so we can react!?!?)... it still doesn't excuse Twitter's continued disregard for the small-to-medium size developer.) --
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
I publish an open source example of using a OAuth in a standalone mac app -- so I'm bought in to the OAuth idea. But it wasn't easy, I had to fight to make it appear even somewhat integrated, and the lack of security around my apps private keys really freaks me out. On the other hand I see a lot of posts like this where I tilt my head and say, what are you talking about? Because I just don't get where you're coming from. It's like there's some hidden assumption someone forgot to tell me. So, please don't take offense, I'd just like to play devil's advocate and ask you to back up these reasons with some more info. I'll try to be specific about what seems odd, or at least odd to me: I really loved OAuth because: (1) Ease of coding. I could get OAuth working within a couple of days. You're saying that OAuth was easier to implement than basic auth? How so? Basic auth just places the authorization info into the request -- oauth requires the entire token request, token exchange, token inclusion dance. At best I could see someone arguing that it's roughly the same because you can use a nice library either way, but saying OAuth is actually easier seems a bit far fetched. Saves me any password maintenance, encryption etc. But how do you maintain the user's auth tokens? Since they're basically as powerful as a password (so long as the user has not turned them off) they need to be given the same care, right? In my implementation I save them just like passwords. Are other developers not doing this? If not why not? (2) Integration with Twitter Branding. With the OAuth scheme, I believe my website is more integrated with Twitter. It would also be nicer if Twitter would maintain their own list of websites they trust with Oauth, just to give users the added confidence that Twitter trusts me. I'm sure if Twitter decided that tomorrow that OAuth was out, and that PAuth or QAuth were the new black, then those would be more integrated. My point being that this is not an advantage intrinsic to OAuth, just an advantage of using the currently blessed standard. I'll give you that one, if you also agree if that if tomorrow Twitter decided Basic Auth was the way forward, Basic Auth would then be more integrated than OAuth. (3) Saves me worrying about SSL. A lot of people are finicky about HTTPS/SSL. This was I can just ytell them that if Twitter wants Oauth that way in future, we will simple provide it. But doesn't that mean that people sniffing on the network where you host your app could potentially grab the authentication tokens of your users as they fly by? Or even just your application tokens if they were interested in spoofing you? I don't mean to be paranoid, but my rather tiny little site was attacked and compromised once a week by evil folks in June -- 4 different attacks by four separate security holes (note to self, don't run a wiki on the same host as my web store). These jerks are everywhere now, and they're the real deal. They have a lot of cash and a lot of patience to think of new ways to exploit your resources to their own end. The part I hate about OAuth is that the OAUth page is extremely slow to load and sometimes does not load at all. I see this issue with the Twitter website in general as well, sometime postst from the web just don't go through. I would much appreciate if people at Twitter can address scalability problems to OAUTH, because that I believe is the biggest user turnoff. I've noticed this too. From an outsider layperson's point of view is seems as though we're pushing every authorization request through a single doorway. My hope is that it's more a lack of my understanding, than anything else. Right? Right?!?! ;-) Thanks for hearing my devil's advocate argument. Don't feel compelled to respond. I don't *need* answers, just curious, that's all. Isaiah
[twitter-dev] Re: Avatar returning the same large file for mini, normal, bigger
So I guess that you are not going back and fixing the ones that are incorrect - like this one? Displaying a couple user's avatars like this one really drags down a page. Any other suggestion (anyone) to detect these large images and prevent displaying them? On Jul 16, 11:54 am, Doug Williams d...@twitter.com wrote: That looks like the result from a rather old bug (which has been closed) that allowed images to upload without resizing. Thanks, Doug On Wed, Jul 15, 2009 at 11:22 PM, TCI ticoconid...@gmail.com wrote: ... which is evidently slowing down pages that download these images and then scale them to their small size. Is it some kind of image reduction bug? Example: http://s3.amazonaws.com/twitter_production/profile_images/109775456/h... http://s3.amazonaws.com/twitter_production/profile_images/109775456/h... http://s3.amazonaws.com/twitter_production/profile_images/109775456/h... These are the avatar for user @hu3vo0 R
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
We had much lower rates. But it is difficult to disentangle if that is due to the extra steps required for OAuth, the OAuth scare screen on Twitter.com, or because of the copy we initially used to invite users to use OAuth. (For example, we had text that read add your Twitter account via OAuth which admittedly isn't going to be very well understand by the average user... login with Twitter would be better.) But for the last 3282 users who added accounts in our system, and for whom we offered BOTH OAuth and Basic Auth options (and where the OAuth step was clearer, indicating that they wouldn't have to give us user/ pass), 1209 or 36% chose OAuth. While this might again be confounded by other factors, this does suggest that for our app, at least, given the choice between Basic and OAuth, users show a preference for Basic Auth. On reflection (and after some sleep), I admit that my initial post was a bit hyperbolic, and partly due to my frustration dealing with another unannounced API change. That said, at least for us, evidence bears out that Basic Auth is just as accepted, if not more accepted, than OAuth by our users. On Jul 28, 3:58 pm, jmathai jmat...@gmail.com wrote: Funny, I posted about our high success rate (95% of all users) with OAuth. I'm trying to get a feel for if we're fortunate, have a good flow or everyone has the same rates.http://groups.google.com/group/twitter-development-talk/browse_thread... On Jul 28, 2:13 pm, Amitab hiamita...@gmail.com wrote: As a developer who has recent launched Twaller (http://www.twaller.com) which supports OAuth, I think I should share my perspective on this. I really loved OAuth because: (1) Ease of coding. I could get OAuth working within a couple of days. Saves me any password maintenance, encryption etc. (2) Integration with Twitter Branding. With the OAuth scheme, I believe my website is more integrated with Twitter. It would also be nicer if Twitter would maintain their own list of websites they trust with Oauth, just to give users the added confidence that Twitter trusts me. (3) Saves me worrying about SSL. A lot of people are finicky about HTTPS/SSL. This was I can just ytell them that if Twitter wants Oauth that way in future, we will simple provide it. The part I hate about OAuth is that the OAUth page is extremely slow to load and sometimes does not load at all. I see this issue with the Twitter website in general as well, sometime postst from the web just don't go through. I would much appreciate if people at Twitter can address scalability problems to OAUTH, because that I believe is the biggest user turnoff. On Jul 28, 1:11 pm, JDG ghil...@gmail.com wrote: It's only a scare if the development community neglects or refuses to educate the populace at large that only Twitter really needs your password, so why give it to anyone else? On Tue, Jul 28, 2009 at 13:27, jahbini jahb...@celarien.com wrote: Sorry about your Oauth Implementation, Mine's been working steadily with no hiccups: Lot's of very solid implementations out there. As far as the user sign-up problem, Yeah, I agree, It's a bit of a scare for the user to have to connect to an off-site twitter authority page -- But that's what Facebook, paypal and all the big boys are pushing toward. As Robert Palmer once said: Your gonna have to face it, your addicted to passwords. Jim On Jul 28, 1:27 am, chinaski007 chinaski...@gmail.com wrote: Let's be honest... The end-result for third-party developers using OAuth appears to be fewer sign-ups, less reliability, more complexity, and potentially less security. Google Optimizer reveals that users are more likely to sign-up for Basic Auth than OAuth. That's just fact. Test it for yourself to confirm. I suppose this is not so weird. Users are accustomed to giving user/ pass information even to foreign apps. It is far more disruptive and invasive for them to go to some bizarre Twitter screen asking them to approve an app. To the average user, what does that mean? (And, heck, it may even require more steps if they have to login again to Twitter.) In terms of reliability, Twitter OAuth was down for days several weeks ago. Tonight yet another unannounced change occurred that broke major code libraries. Meanwhile, Basic Auth has been plugging along just fine and dandy... So what IS the benefit of OAuth? It doesn't benefit developers as you will likely get more sign-ups with Basic Auth and Basic Auth is far, far easier to setup. Sure, OAuth might satisfy some power users hungry for security... But is OAuth even more secure than Basic Auth? Perhaps not. After all, tonight's fix was for an OAuth security flaw known for at least 10+ days (judging by tweets to @twitterapi) that allowed for potential
[twitter-dev] Re: Twitter: What did you change in OAuth?
other threads suggest resolution by checking and changing the method of url encoding. On Jul 28, 12:27 am, Duane Roelands duane.roela...@gmail.com wrote: Simply telling developers that something changed is not sufficient information to help us get our applications back online. We need specific information concerning which part of the signature generation/validation was changed.
