[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
Personally I've found JavaScript based auth systems like Facebook Connect and Google Friend Connect to be very difficult to debug and use. I am also a lot more comfortable with PHP then JS. As far as UX. Sign in with Twitter has the same flow as FBC and GFC. Click a link on your site, jump to provider to authorize, and return to consumer. Abraham On Thu, Jul 30, 2009 at 22:12, Jesse Stay jesses...@gmail.com wrote: I understand the reasoning behind OAuth, and think it's a step in the right direction, but, does Twitter have plans to improve and move to a better Auth system than OAuth? With Facebook Connect I just have to click once, and if the user is already logged in and approved my app, they never see the Facebook login box again. Where as with Twitter there are 3 points of potential failure every single time the user logs in. It's a Ux nightmare, IMO. While it does solve a problem, I don't think OAuth is the end or ideal solution. Are there plans to improve this process? Jesse On Wed, Jul 29, 2009 at 1:05 PM, Doug Williams d...@twitter.com wrote: Well said, Duane. Thanks, Doug On Wed, Jul 29, 2009 at 7:18 AM, Duane Roelands duane.roela...@gmail.com wrote: First, let me state from the start that I am no fan of OAuth, Twitter's implementation of it, or the way that they've behaved with regard to it. Now, with all that being said. If your website expects me to hand over my Twitter password, I'm not using your web site. Just yesterday, another scam site (TwitViewer) managed to steal thousands of accounts, and convince other people to hand over their information because it was posting tweets from the stolen accounts. OAuth is not perfect, but it provides individual users and Twitter with a way to identify bad actors and lock them out of the ecosystem. OAuth works. There are examples out there. There are developers who are willing to help you. Implementing OAuth tells your customers that the security of their account is important to you, and shutting down Basic Auth trains your users to stop giving away their password. If your product has value, and you clearly communicate what that value is, the users will use OAuth. On Jul 29, 9:10 am, Dewald Pretorius dpr...@gmail.com wrote: It would not surprise me at all if using OAuth resulted in fewer signups. Potential technical advantages of OAuth aside, every additional click that you add in the conversion process adds an addition leakage point where some users can and will abandon the signup process. -- 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. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: Twitter4J 2.0.9 released - introduces tons of bugs, and lots of new features including Android support
Hi, The changes made with TFJ-187 is fairly trivial. You can see the change at: http://yusuke.homeip.net/fisheye/browse/svn/twitter4j/trunk/src/main/java/twitter4j/http/OAuth.java?r2=355r1=305 Cheers, -- Yusuke Yamamoto yus...@mac.com this email is: [x] bloggable/tweetable [ ] ask first [ ] private follow me on : http://twitter.com/yusukeyamamoto subscribe me at : http://yusuke.homeip.net/blog/ On 7月30日, 午後2:55, Amitab hiamita...@gmail.com wrote: Thanks a lot Yusuke, Did you do any major changes to Oauth aoart from fixing TFJ-187? I will get working with this for twaller.com /Amitab On Jul 30, 5:36 am, Yusuke Yamamoto yus...@mac.com wrote: Versoin 2.0.9 is not meant to introduce tons of bugs, it actually *fixes* tons of bugs of course. -- Yusuke Yamamoto yus...@mac.com this email is: [x] bloggable/tweetable [ ] ask first [ ] private follow me on :http://twitter.com/yusukeyamamoto subscribe me at :http://yusuke.homeip.net/blog/ On 2009/07/30, at 2:16, Yusuke Yamamoto wrote: Hi all, Twitter4J 2.0.9 is available for download. http://yusuke.homeip.net/twitter4j/en/index.html#download It is(or will be) also available at the Maven central repository. http://repo1.maven.org/maven2/net/homeip/yusuke/twitter4j/ Snapshot builds can be found at: http://yusuke.homeip.net/maven2/net/homeip/yusuke/twitter4j/ Release Notes - Twitter4J - Version 2.0.9 - HTML format Bug [TFJ-167] - push style streaming thread quits with IOException [TFJ-173] - is mapped to \\u0022 [TFJ-175] - Streaming API now requires comma separated follow parameter [TFJ-181] - ExceptionInInitializationError on Android platforms [TFJ-187] - SerializationException with twitter4j.http.OAuth [TFJ-189] - TwitterException with streaming API : twitter4j.TwitterException: JSONObject[id] not found with streaming api Improvement [TFJ-174] - inconsistent method names in User Methods [TFJ-177] - the scope of the junit dependencies in the pom should be set to test [TFJ-178] - getPublicTimeline(int sinceID) should take long sinceId [TFJ-179] - scope of junit should be test, not compile [TFJ-180] -http://twitter.com/statuses/friends_timeline/ userId.xml is not supported anymore [TFJ-182] - ExceptionInInitializerError with Java applets [TFJ-183] - method name refactor: RateLimitStatus.getDateTime() - RateLimitStatus.getResetTime() New Feature [TFJ-163] - introduce twitter4j.properties that overrides default properties [TFJ-170] - dynamic callback support [TFJ-176] - Streaming API : support track method Task [TFJ-184] - refactor: some fields in HttpClient can be static [TFJ-190] - slf4j, and rome are not required libraries, scope in pom.xml should be provided instead of compile Cheers, -- Yusuke Yamamoto yus...@mac.com this email is: [x] bloggable/tweetable [ ] ask first [ ] private follow me on :http://twitter.com/yusukeyamamoto subscribe me at :http://yusuke.homeip.net/blog/
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
Oh yes!!! The methods which didn't work were sent by plain HTTP and the other methods that work ok were using HTTPS didn't mind!! Now, all methods are working on HTTPS, and all are working properly!! Sure, it seams the solution is use HTTPS Thanks!! On Thu, Jul 30, 2009 at 10:16 PM, AlbertC compl...@gmail.com wrote: I don't know if this will help at all, but I had the same problem...after hours spent on this stupid error, I realized that some of my request URLs were using http, and some https. After changing all the request URLs to https, everything's working perfectly (I'm using exactly the same client library). It does make all kinds of sense. Regular http requests worked fine before, though. It's probably been mentioned before. If so, I missed it, sorry. :) On Jul 30, 12:03 pm, Andreu andreup...@gmail.com wrote: I read this discussion carefully and I cannot extract a conclusion... The question is why a set of API methods are working and others aren't working properly, returning a 'Incorrect signature' error. Methods working now: - posting a tweet (statuses/update). Works fine - extract user timeline (statuses/user_timeline). Works fine either the request is made by the authenticated user (user requesting his own timeline) or requesting a 3rd user timeline - verify credentials (account/verify_credentials). Works fine. Methods not working: - delete a tweet (statuses/destroy). - destroy a relationship (friendships/destroy) - create a relationship (friendships/create) - extract friends timeline (statuses/friends_timeline) All methods are relying over the same base python method, building the same requests changing the API urls and/or parameters... The library I am using ishttp://oauth.googlecode.com/svn/code/python/oauth/oauth.py I think if server signature verification have been modified, and now is running 'properly', all my methods should fail, especially the methods that authentication is required... but the problem is ones are working and others not working.
[twitter-dev] Re: twitter api server seems to be down (getting invalid signature) since 5.15 pm pst
Oh yes!!! The methods which didn't work were sent by plain HTTP and the other methods that work ok were using HTTPS didn't mind!! Now, all methods are working on HTTPS, and all are working properly!! Sure, it seams the solution is use HTTPS Thanks!! On Jul 30, 10:16 pm, AlbertC compl...@gmail.com wrote: I don't know if this will help at all, but I had the same problem...after hours spent on this stupid error, I realized that some of my request URLs were using http, and some https. After changing all the request URLs to https, everything's working perfectly (I'm using exactly the same client library). It does make all kinds of sense. Regular http requests worked fine before, though. It's probably been mentioned before. If so, I missed it, sorry. :) On Jul 30, 12:03 pm, Andreu andreup...@gmail.com wrote: I read this discussion carefully and I cannot extract a conclusion... The question is why a set of API methods are working and others aren't working properly, returning a 'Incorrect signature' error. Methods working now: - posting a tweet (statuses/update). Works fine - extract user timeline (statuses/user_timeline). Works fine either the request is made by the authenticated user (user requesting his own timeline) or requesting a 3rd user timeline - verify credentials (account/verify_credentials). Works fine. Methods not working: - delete a tweet (statuses/destroy). - destroy a relationship (friendships/destroy) - create a relationship (friendships/create) - extract friends timeline (statuses/friends_timeline) All methods are relying over the same base python method, building the same requests changing the API urls and/or parameters... The library I am using ishttp://oauth.googlecode.com/svn/code/python/oauth/oauth.py I think if server signature verification have been modified, and now is running 'properly', all my methods should fail, especially the methods that authentication is required... but the problem is ones are working and others not working.
[twitter-dev] Search API and using since_id and max_id
I want to retrieve all tweets that meet a certain criteria, so I tried using the since_id as a starting point, and incrementing by a reasonable delta for subsequent calls, and using that value for a max_id. I was expecting to get different results when I do: Run 1: since_id=2815106475 max_id-since_id+100 Run 2: since_id=2815106475+1000 max_id-since_id+100 but I am getting the same results every time. It seems as if the max_id value is ignored and it's default to the current date (I tried until as well). Any ideas?
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
On Jul 31, 4:37 am, Duane Roelands duane.roela...@gmail.com wrote: OAuth lets you access the Twitter service without giving your Twitter credentials to anyone but Twitter. Basic Auth requires you to give your Twitter credentials to someone other than Twitter. Therefore, OAuth is more secure than Basic Auth. This is not rocket science. I agree with Bradley. It's how you (user) see the situation, but the situation is not that way. You do give password to application (or application can take it if it wants). You are just fooling yourself, and this makes security even worser. With basic auth you are aware of the fact you are giving application credentials, so are able to make thoughtful decision. With OAuth you (ordinary user) are not aware of the fact that you give application credentials, so you are under wrong illusion that you may use any application and you on the safe side. In reality you give application everything when installed it to your computer. In this situation basic auth becomes more secure because it shows situation to a user as it is (stupid! you must trust any application you are installing!), OAuth panders security threats (relax, you may think as if you may not trust the application, because you are as if not giving it credentials). -- Dmitriy V'jukov
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
On Jul 30, 7:40 pm, Bradley S. O'Hearne brad.ohea...@gmail.com wrote: 2. Passwords being stored locally. Comment: The application integrating with Twitter is already effectively trusted, so the concern should not be with the app itself. The concern here would be other apps or people being able to grab passwords off of disk where stored. Again, I think this goes back to encryption. If all credentials are encrypted locally, then again, the concern becomes the breaking of encryption, and if that is done, then again whatever app or session token represents the key to the city can be acquired to use in OAuth too, if I'm not mistaken. Note that with basic auth it's perfectly possible to store only indirect security token too. Assume: application asks user for credentials, verifies them on the server, in response server issues unique indirect security token, application discards original credentials and stores token. This will depend on the application's security culture, though. -- Dmitriy V'jukov
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
I am surprised nobody is bringing up these too points: - people will use the more secure thing once they are educated. you know the kind of stuff where you tell the people you support that they will not get tech support any more if they do this. - the argument about 'having to agree on something' is not as bad as it sound because they do it every day on facebook. The one thing I do mind that even I always have to search aruond to find the place where my apps are located. Nicole ~~~ -- Jetzt im Buchhandel: Twitter - Mit 140 Zeichen zum Web 2.0 Amazon: http://tinyurl.com/6at9c5 http://mit140zeichen.de - http://twitter.com/m140z Kontakt: http://twitter.com/NicoleSimon https://www.xing.com/profile/Nicole_Simon skype: nicole.simon / mailto:nicole.si...@mit140zeichen.de phone: +49 451 899 75 03 / mobile: +49 179 499 7076
[twitter-dev] Obtaining a list of valid recipients for direct messages
If I understand correctly, in order to send a direct message to another user, we must be mutual followers; he must be following me and I must be following him. Now, I could call friends/ids and then followers/ids and use the intersection of those two calls. That seems like an awful lot of data to pull down to get to a much smaller subset. Is there a more direct way, perhaps a method call I have overlooked?
[twitter-dev] Re: Obtaining a list of valid recipients for direct messages
This is incorrect. Account A can send DMs to any accounts that are following account A. Account A does not having to be following the accounts receiving the DMs. Abraham On Fri, Jul 31, 2009 at 07:25, Duane Roelands duane.roela...@gmail.comwrote: If I understand correctly, in order to send a direct message to another user, we must be mutual followers; he must be following me and I must be following him. Now, I could call friends/ids and then followers/ids and use the intersection of those two calls. That seems like an awful lot of data to pull down to get to a much smaller subset. Is there a more direct way, perhaps a method call I have overlooked? -- 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. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: Obtaining a list of valid recipients for direct messages
Ah, I see. I was misled by the Twitter.com website. If go to Twitter.com and select Direct Messages on the right, you are taken to a screen with a dropdown list for selecting the recipient. That dropdown does -not- have all of my followers in it. But, I see that if I browse to the profile of one of my followers, I can send them a direct message from there. Thanks, Abraham! Followup: Twitter Devs, what's the rationale for not showing all potential recipients in the dropdown? On Jul 31, 9:12 am, Abraham Williams 4bra...@gmail.com wrote: This is incorrect. Account A can send DMs to any accounts that are following account A. Account A does not having to be following the accounts receiving the DMs. Abraham On Fri, Jul 31, 2009 at 07:25, Duane Roelands duane.roela...@gmail.comwrote: If I understand correctly, in order to send a direct message to another user, we must be mutual followers; he must be following me and I must be following him. Now, I could call friends/ids and then followers/ids and use the intersection of those two calls. That seems like an awful lot of data to pull down to get to a much smaller subset. Is there a more direct way, perhaps a method call I have overlooked? -- 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. Sent from Madison, Wisconsin, United States
[twitter-dev] Unable to get tweets from Twitter API when set Geo-code
Hi, I am unable to get tweets from Twitter API for the query credit cards OR card when set geocode to New York,US within:2500km. Search Link http://search.twitter.com/search.json?q=credit+cards+OR+cardrpp=100page=1geocode=40.756054%2C-73.986951%2C2500.0km but when i decrease radius from 2500KM to 2400 KM i got tweets. Also i got tweets when i changed query to credit cards and radius 2500KM http://search.twitter.com/search.json?q=credit+cardsrpp=100page=1geocode=40.756054%2C-73.986951%2C2500.0km Why is this random behaviour. Please help me and reply soon. Regards, Praveen Kumar .N
[twitter-dev] Re: Obtaining a list of valid recipients for direct messages
No, that's wrong! You can send DMs to any account as long as he is following you! You even doesn't need to follow him! 2009/7/31 Abraham Williams 4bra...@gmail.com This is incorrect. Account A can send DMs to any accounts that are following account A. Account A does not having to be following the accounts receiving the DMs. Abraham On Fri, Jul 31, 2009 at 07:25, Duane Roelands duane.roela...@gmail.comwrote: If I understand correctly, in order to send a direct message to another user, we must be mutual followers; he must be following me and I must be following him. Now, I could call friends/ids and then followers/ids and use the intersection of those two calls. That seems like an awful lot of data to pull down to get to a much smaller subset. Is there a more direct way, perhaps a method call I have overlooked? -- 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. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
About the first point, this will just keep happening. The only difference is that instead of have their credential stolen, they will have their token stolen. Then, spammers, for example, will use this tokens to send a lot of spam messages, or do whatever they want. When the user notice it will be too late.The damage will be done. Spammers can just provide a simple site, like those test sites around, for example, and collect a lot of request token before send the spams. But it is ok, the user can just block this application without changing the password. That is very nice. Second, there will be applications asking for username and password even if twitter do not support basic authentication anymore. And we can try to educate our users, but, as far as I know all Banks are trying to do this for some couple of years without success. The main problem here is that the security breach of all systems is the user. And unfortunately we can not change them as fast as we can change our codes. :-( That is just my opinion and i´m a little out of date within oauth. I like the idea but think that the current flow is very poor for mobile and embedded devices. regards, Otávio Ribeiro On Fri, Jul 31, 2009 at 9:18 AM, Duane Roelands duane.roela...@gmail.comwrote: With basic auth you are aware of the fact you are giving application credentials, so are able to make thoughtful decision. This is not supported by the evidence, as thousands of people thoughtfully gave their Twitter credentials to TwitViewer and got their accounts stolen. With OAuth you (ordinary user) are not aware of the fact that you give application credentials This is incorrect. WIth OAuth, you don't give your credentials to anyone except Twitter. It's a bad idea to give your account credentials to a third party. Basic Auth forces you to give your account credentials to a third party. Therefore, using Basic Auth is a bad idea. On Jul 31, 8:09 am, Nicole Simon nee...@gmail.com wrote: I am surprised nobody is bringing up these too points: - people will use the more secure thing once they are educated. you know the kind of stuff where you tell the people you support that they will not get tech support any more if they do this. - the argument about 'having to agree on something' is not as bad as it sound because they do it every day on facebook. The one thing I do mind that even I always have to search aruond to find the place where my apps are located. Nicole ~~~ -- Jetzt im Buchhandel: Twitter - Mit 140 Zeichen zum Web 2.0 Amazon:http://tinyurl.com/6at9c5 http://mit140zeichen.de-http://twitter.com/m140z Kontakt: http://twitter.com/NicoleSimonhttps://www.xing.com/profile/Nicole_Simon skype: nicole.simon / mailto:nicole.si...@mit140zeichen.de phone: +49 451 899 75 03 / mobile: +49 179 499 7076
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
No, Sign in with Twitter doesn't have the same flow as Facebook Connect. With Facebook Connect, once your sessions are created, they remain for that user for a given time. The user doesn't have to go through the entire login process again each time you request a signature for them. With Twitter, the user has to go to an *entirely* different page, log in if they haven't, click accept or decline, and then come all the way back to your site, *every time*. I also don't get why you think Facebook Connect is difficult to debug. Sounds like more an issue of education than not. I've had worse issues with OAuth debugging, to tell you the truth. All the methods are provided for you in Facebook Connect to know exactly what's going on - it's actually very simple compared to the work I've done with OAuth, and the user never has to leave my site to login. With OAuth, there's no way of verifying if your URL was written correctly, or what the issue was when tokens weren't returned. With Facebook, all that work is done for you, no coding necessary on your end until the user is authenticated. It's incredibly simple. Jesse On Fri, Jul 31, 2009 at 2:21 AM, Abraham Williams 4bra...@gmail.com wrote: Personally I've found JavaScript based auth systems like Facebook Connect and Google Friend Connect to be very difficult to debug and use. I am also a lot more comfortable with PHP then JS. As far as UX. Sign in with Twitter has the same flow as FBC and GFC. Click a link on your site, jump to provider to authorize, and return to consumer. Abraham On Thu, Jul 30, 2009 at 22:12, Jesse Stay jesses...@gmail.com wrote: I understand the reasoning behind OAuth, and think it's a step in the right direction, but, does Twitter have plans to improve and move to a better Auth system than OAuth? With Facebook Connect I just have to click once, and if the user is already logged in and approved my app, they never see the Facebook login box again. Where as with Twitter there are 3 points of potential failure every single time the user logs in. It's a Ux nightmare, IMO. While it does solve a problem, I don't think OAuth is the end or ideal solution. Are there plans to improve this process? Jesse On Wed, Jul 29, 2009 at 1:05 PM, Doug Williams d...@twitter.com wrote: Well said, Duane. Thanks, Doug On Wed, Jul 29, 2009 at 7:18 AM, Duane Roelands duane.roela...@gmail.com wrote: First, let me state from the start that I am no fan of OAuth, Twitter's implementation of it, or the way that they've behaved with regard to it. Now, with all that being said. If your website expects me to hand over my Twitter password, I'm not using your web site. Just yesterday, another scam site (TwitViewer) managed to steal thousands of accounts, and convince other people to hand over their information because it was posting tweets from the stolen accounts. OAuth is not perfect, but it provides individual users and Twitter with a way to identify bad actors and lock them out of the ecosystem. OAuth works. There are examples out there. There are developers who are willing to help you. Implementing OAuth tells your customers that the security of their account is important to you, and shutting down Basic Auth trains your users to stop giving away their password. If your product has value, and you clearly communicate what that value is, the users will use OAuth. On Jul 29, 9:10 am, Dewald Pretorius dpr...@gmail.com wrote: It would not surprise me at all if using OAuth resulted in fewer signups. Potential technical advantages of OAuth aside, every additional click that you add in the conversion process adds an addition leakage point where some users can and will abandon the signup process. -- 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. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
One security advantage of oauth with desktop apps is allowing the application to keep you logged in without having to store your password in plaintext on the hard disk. This way if the computer is compromised or stolen later on your password is not compromised. I still think the UX with desktop based oauth apps isn't the most joyful and could be improved upon. One possible solution that has been brought up is allowing the desktop app to authorize on your behalf using your username and password. This way the app can get the access token without the user having to visit the SP's site. Once the access token has been retrieved the application can forget the password and remain logged in even if the password changes in the future. All resource requests would then be done using oauth with the access token. Overall I think OAuth is a good solution for API authentication. Its secure and provides benefits to the user, consumer, and sp. On Fri, Jul 31, 2009 at 9:41 AM, Christopher St John ckstj...@gmail.comwrote: On Thu, Jul 30, 2009 at 6:07 PM, Bradley S. O'Hearnebrad.ohea...@gmail.com wrote: I really want to hear stated, or read on a FAQ, is the pre-requisite security trust, that in that scenario, it necessarily makes OAuth superior to basic authentication. The problem here is that you're paying attention, instead of just accepting oauth is better because it is! statements :-) For desktop apps (and in any case where the application has has control of the UI and/or your computer) OAuth has no security advantage (since the app can snoop the interaction) I'm sure bad people are working on a way to make this true in browser apps as well, but I don't know of any examples. For web applications, many commentators acknowledge an increased risk of phishing as a potential problem with OAuth, although I haven't personally read any studies that indicate whether it's a theoretical or practical problem at this point. In any case, the primary benefit in OAuth is not protecting the user immediately from an evil application (since the authorization tokens an OAuth server hand out are just as powerful as passwords and must be protected like passwords) it's that: - the owners of the service can (in theory) administratively ban an application without forcing all the users to change their passwords (a potentially very big benefit, maybe the single benefit that justifies the general inconvenience) - an individual user can ban an application by revoking its authz token without having to change their password (a moderate-at-best benefit, since you could always just change your password) - an individual who is using exactly the same password at many sites doesn't have to expose out their mono-password to an app (people mention this a lot, but come on, should security system try to make people feel better about hitting themselves on the head with a hammer? but this gets mentioned a lot, so there you go) So, the security picture is actually a little fuzzy. There are some big wins for service administrators, some real (but medium-sized?) wins for users, some fundamental limits of applicability (web-apps only) and some open questions about phishing and snooping. And lots and lots of hype :-) -cks -- Christopher St. John http://praxisbridge.com http://artofsystems.blogspot.com -- Josh
[twitter-dev] Search is no longer indexing Portuguese (pt) tweets
The results in english is fine: - http://search.twitter.com/search?lang=allq=307.to Results in portuguese, simple doesn't return nothing: - http://search.twitter.com/search?lang=ptq=307.to But yes, there is portuguese tweets with 307.to string: - http://search.twitter.com/search?lang=ptq=framework+from%3Acaioariede What's the problem? Thx! Caio Ariede http://caioariede.com/
[twitter-dev] Re: Follow up
Thanks for the kind words, from the Twitter team. Cheers, Doug On Thu, Jul 30, 2009 at 8:52 PM, MRWILLAN timothywil...@gmail.com wrote: I like to take this time to personally THANK Twitter Development for the work your doing and fixing in the line of spam follow up and tactical problems, I know there must be alot of hands full of JUNK! ON Twitter, So may Thanks for what you do!
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
Jesse, That is not true. With the Sign in with Twitter flow (not the standard OAuth flow which is also available) -- If the user is logged in and has previously approved the app, they will be immediately redirected back to the application without ever seeing a Twitter dialog. Thanks, Doug On Fri, Jul 31, 2009 at 9:31 AM, Jesse Stay jesses...@gmail.com wrote: No, Sign in with Twitter doesn't have the same flow as Facebook Connect. With Facebook Connect, once your sessions are created, they remain for that user for a given time. The user doesn't have to go through the entire login process again each time you request a signature for them. With Twitter, the user has to go to an *entirely* different page, log in if they haven't, click accept or decline, and then come all the way back to your site, *every time*. I also don't get why you think Facebook Connect is difficult to debug. Sounds like more an issue of education than not. I've had worse issues with OAuth debugging, to tell you the truth. All the methods are provided for you in Facebook Connect to know exactly what's going on - it's actually very simple compared to the work I've done with OAuth, and the user never has to leave my site to login. With OAuth, there's no way of verifying if your URL was written correctly, or what the issue was when tokens weren't returned. With Facebook, all that work is done for you, no coding necessary on your end until the user is authenticated. It's incredibly simple. Jesse On Fri, Jul 31, 2009 at 2:21 AM, Abraham Williams 4bra...@gmail.comwrote: Personally I've found JavaScript based auth systems like Facebook Connect and Google Friend Connect to be very difficult to debug and use. I am also a lot more comfortable with PHP then JS. As far as UX. Sign in with Twitter has the same flow as FBC and GFC. Click a link on your site, jump to provider to authorize, and return to consumer. Abraham On Thu, Jul 30, 2009 at 22:12, Jesse Stay jesses...@gmail.com wrote: I understand the reasoning behind OAuth, and think it's a step in the right direction, but, does Twitter have plans to improve and move to a better Auth system than OAuth? With Facebook Connect I just have to click once, and if the user is already logged in and approved my app, they never see the Facebook login box again. Where as with Twitter there are 3 points of potential failure every single time the user logs in. It's a Ux nightmare, IMO. While it does solve a problem, I don't think OAuth is the end or ideal solution. Are there plans to improve this process? Jesse On Wed, Jul 29, 2009 at 1:05 PM, Doug Williams d...@twitter.com wrote: Well said, Duane. Thanks, Doug On Wed, Jul 29, 2009 at 7:18 AM, Duane Roelands duane.roela...@gmail.com wrote: First, let me state from the start that I am no fan of OAuth, Twitter's implementation of it, or the way that they've behaved with regard to it. Now, with all that being said. If your website expects me to hand over my Twitter password, I'm not using your web site. Just yesterday, another scam site (TwitViewer) managed to steal thousands of accounts, and convince other people to hand over their information because it was posting tweets from the stolen accounts. OAuth is not perfect, but it provides individual users and Twitter with a way to identify bad actors and lock them out of the ecosystem. OAuth works. There are examples out there. There are developers who are willing to help you. Implementing OAuth tells your customers that the security of their account is important to you, and shutting down Basic Auth trains your users to stop giving away their password. If your product has value, and you clearly communicate what that value is, the users will use OAuth. On Jul 29, 9:10 am, Dewald Pretorius dpr...@gmail.com wrote: It would not surprise me at all if using OAuth resulted in fewer signups. Potential technical advantages of OAuth aside, every additional click that you add in the conversion process adds an addition leakage point where some users can and will abandon the signup process. -- 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. Sent from Madison, Wisconsin, United States
[twitter-dev] 2 week advance notice: changes to /friends/ids and /followers/ids
The Twitter API currently has two methods for returning a user's
denormalized social graph: /friends/ids [1] and /followers/ids [2].
These methods presently allow pagination by use of a ?page=n
parameter; without that parameter, they attempt to return all user IDs
in the specified set. If you've used this methods, particularly for
exploring the social graphs of users that are following or followed by
a large number of other users, you've probably run into lag and server
errors.
In two weeks, we'll be addressing this with a change in back-end
infrastructure. The page parameter will be replaced with a cursor
parameter, which in turn will result in a change in the response
bodies for these two methods. Whereas currently you'd receive an array
response like this (in JSON):
[1,2,3,...]
You will now receive:
{ids: [1,2,3], next_id: 1231232}
You can then use the next_id value to paginate through the set:
/followers/ids.json?cursor=1231232
To start paginating:
/followers/ids.json?cursor=-1
The negative one (-1) indicates that you want to begin paginating.
When the next_id value is zero (0), you're at the last page.
Documentation of the new functionality will, of course, be provided on
the API Wiki in advance of the change going live. If you have any
questions or concerns, please contact us as soon as possible.
[1] http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friends%C2%A0ids
[2] http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-followers%C2%A0ids
--
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x
[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids
Alex, thanks for the advance notice, and having notification when you're at
the last page will be a huge improvement and help. Does this mean pagination
is now required for that method?
Jesse
On Fri, Jul 31, 2009 at 1:35 PM, Alex Payne a...@twitter.com wrote:
The Twitter API currently has two methods for returning a user's
denormalized social graph: /friends/ids [1] and /followers/ids [2].
These methods presently allow pagination by use of a ?page=n
parameter; without that parameter, they attempt to return all user IDs
in the specified set. If you've used this methods, particularly for
exploring the social graphs of users that are following or followed by
a large number of other users, you've probably run into lag and server
errors.
In two weeks, we'll be addressing this with a change in back-end
infrastructure. The page parameter will be replaced with a cursor
parameter, which in turn will result in a change in the response
bodies for these two methods. Whereas currently you'd receive an array
response like this (in JSON):
[1,2,3,...]
You will now receive:
{ids: [1,2,3], next_id: 1231232}
You can then use the next_id value to paginate through the set:
/followers/ids.json?cursor=1231232
To start paginating:
/followers/ids.json?cursor=-1
The negative one (-1) indicates that you want to begin paginating.
When the next_id value is zero (0), you're at the last page.
Documentation of the new functionality will, of course, be provided on
the API Wiki in advance of the change going live. If you have any
questions or concerns, please contact us as soon as possible.
[1] http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friends%C2%A0ids
[2]
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-followers%C2%A0ids
--
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
Doug, interesting - I didn't realize that's what Sign on With Twitter did. Last I tried that wasn't working though - is that working now? Jesse On Fri, Jul 31, 2009 at 1:31 PM, Doug Williams d...@twitter.com wrote: Jesse, That is not true. With the Sign in with Twitter flow (not the standard OAuth flow which is also available) -- If the user is logged in and has previously approved the app, they will be immediately redirected back to the application without ever seeing a Twitter dialog. Thanks, Doug On Fri, Jul 31, 2009 at 9:31 AM, Jesse Stay jesses...@gmail.com wrote: No, Sign in with Twitter doesn't have the same flow as Facebook Connect. With Facebook Connect, once your sessions are created, they remain for that user for a given time. The user doesn't have to go through the entire login process again each time you request a signature for them. With Twitter, the user has to go to an *entirely* different page, log in if they haven't, click accept or decline, and then come all the way back to your site, *every time*. I also don't get why you think Facebook Connect is difficult to debug. Sounds like more an issue of education than not. I've had worse issues with OAuth debugging, to tell you the truth. All the methods are provided for you in Facebook Connect to know exactly what's going on - it's actually very simple compared to the work I've done with OAuth, and the user never has to leave my site to login. With OAuth, there's no way of verifying if your URL was written correctly, or what the issue was when tokens weren't returned. With Facebook, all that work is done for you, no coding necessary on your end until the user is authenticated. It's incredibly simple. Jesse On Fri, Jul 31, 2009 at 2:21 AM, Abraham Williams 4bra...@gmail.comwrote: Personally I've found JavaScript based auth systems like Facebook Connect and Google Friend Connect to be very difficult to debug and use. I am also a lot more comfortable with PHP then JS. As far as UX. Sign in with Twitter has the same flow as FBC and GFC. Click a link on your site, jump to provider to authorize, and return to consumer. Abraham On Thu, Jul 30, 2009 at 22:12, Jesse Stay jesses...@gmail.com wrote: I understand the reasoning behind OAuth, and think it's a step in the right direction, but, does Twitter have plans to improve and move to a better Auth system than OAuth? With Facebook Connect I just have to click once, and if the user is already logged in and approved my app, they never see the Facebook login box again. Where as with Twitter there are 3 points of potential failure every single time the user logs in. It's a Ux nightmare, IMO. While it does solve a problem, I don't think OAuth is the end or ideal solution. Are there plans to improve this process? Jesse On Wed, Jul 29, 2009 at 1:05 PM, Doug Williams d...@twitter.comwrote: Well said, Duane. Thanks, Doug On Wed, Jul 29, 2009 at 7:18 AM, Duane Roelands duane.roela...@gmail.com wrote: First, let me state from the start that I am no fan of OAuth, Twitter's implementation of it, or the way that they've behaved with regard to it. Now, with all that being said. If your website expects me to hand over my Twitter password, I'm not using your web site. Just yesterday, another scam site (TwitViewer) managed to steal thousands of accounts, and convince other people to hand over their information because it was posting tweets from the stolen accounts. OAuth is not perfect, but it provides individual users and Twitter with a way to identify bad actors and lock them out of the ecosystem. OAuth works. There are examples out there. There are developers who are willing to help you. Implementing OAuth tells your customers that the security of their account is important to you, and shutting down Basic Auth trains your users to stop giving away their password. If your product has value, and you clearly communicate what that value is, the users will use OAuth. On Jul 29, 9:10 am, Dewald Pretorius dpr...@gmail.com wrote: It would not surprise me at all if using OAuth resulted in fewer signups. Potential technical advantages of OAuth aside, every additional click that you add in the conversion process adds an addition leakage point where some users can and will abandon the signup process. -- 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. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids
To clarify, since several people have asked: this pending change does
NOT mean that pagination is required. You can still attempt to
retrieve all IDs in one call, but be aware that this is likely to time
out or fail for users with large social graphs.
On Fri, Jul 31, 2009 at 10:35, Alex Paynea...@twitter.com wrote:
The Twitter API currently has two methods for returning a user's
denormalized social graph: /friends/ids [1] and /followers/ids [2].
These methods presently allow pagination by use of a ?page=n
parameter; without that parameter, they attempt to return all user IDs
in the specified set. If you've used this methods, particularly for
exploring the social graphs of users that are following or followed by
a large number of other users, you've probably run into lag and server
errors.
In two weeks, we'll be addressing this with a change in back-end
infrastructure. The page parameter will be replaced with a cursor
parameter, which in turn will result in a change in the response
bodies for these two methods. Whereas currently you'd receive an array
response like this (in JSON):
[1,2,3,...]
You will now receive:
{ids: [1,2,3], next_id: 1231232}
You can then use the next_id value to paginate through the set:
/followers/ids.json?cursor=1231232
To start paginating:
/followers/ids.json?cursor=-1
The negative one (-1) indicates that you want to begin paginating.
When the next_id value is zero (0), you're at the last page.
Documentation of the new functionality will, of course, be provided on
the API Wiki in advance of the change going live. If you have any
questions or concerns, please contact us as soon as possible.
[1] http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friends%C2%A0ids
[2] http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-followers%C2%A0ids
--
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x
--
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x
[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids
On Jul 31, 9:03 pm, Alex Payne a...@twitter.com wrote: To clarify, since several people have asked: this pending change does NOT mean that pagination is required. You can still attempt to retrieve all IDs in one call, but be aware that this is likely to time out or fail for users with large social graphs. What is defined as large social graphs? -- Arik Fraimovich follow me on twitter: http://twitter.com/arikfr
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
Jesse, If it is not, then it is a defect. That is the intended functionality. Thanks, Doug On Fri, Jul 31, 2009 at 10:57 AM, Jesse Stay jesses...@gmail.com wrote: Doug, interesting - I didn't realize that's what Sign on With Twitter did. Last I tried that wasn't working though - is that working now? Jesse On Fri, Jul 31, 2009 at 1:31 PM, Doug Williams d...@twitter.com wrote: Jesse, That is not true. With the Sign in with Twitter flow (not the standard OAuth flow which is also available) -- If the user is logged in and has previously approved the app, they will be immediately redirected back to the application without ever seeing a Twitter dialog. Thanks, Doug On Fri, Jul 31, 2009 at 9:31 AM, Jesse Stay jesses...@gmail.com wrote: No, Sign in with Twitter doesn't have the same flow as Facebook Connect. With Facebook Connect, once your sessions are created, they remain for that user for a given time. The user doesn't have to go through the entire login process again each time you request a signature for them. With Twitter, the user has to go to an *entirely* different page, log in if they haven't, click accept or decline, and then come all the way back to your site, *every time*. I also don't get why you think Facebook Connect is difficult to debug. Sounds like more an issue of education than not. I've had worse issues with OAuth debugging, to tell you the truth. All the methods are provided for you in Facebook Connect to know exactly what's going on - it's actually very simple compared to the work I've done with OAuth, and the user never has to leave my site to login. With OAuth, there's no way of verifying if your URL was written correctly, or what the issue was when tokens weren't returned. With Facebook, all that work is done for you, no coding necessary on your end until the user is authenticated. It's incredibly simple. Jesse On Fri, Jul 31, 2009 at 2:21 AM, Abraham Williams 4bra...@gmail.comwrote: Personally I've found JavaScript based auth systems like Facebook Connect and Google Friend Connect to be very difficult to debug and use. I am also a lot more comfortable with PHP then JS. As far as UX. Sign in with Twitter has the same flow as FBC and GFC. Click a link on your site, jump to provider to authorize, and return to consumer. Abraham On Thu, Jul 30, 2009 at 22:12, Jesse Stay jesses...@gmail.com wrote: I understand the reasoning behind OAuth, and think it's a step in the right direction, but, does Twitter have plans to improve and move to a better Auth system than OAuth? With Facebook Connect I just have to click once, and if the user is already logged in and approved my app, they never see the Facebook login box again. Where as with Twitter there are 3 points of potential failure every single time the user logs in. It's a Ux nightmare, IMO. While it does solve a problem, I don't think OAuth is the end or ideal solution. Are there plans to improve this process? Jesse On Wed, Jul 29, 2009 at 1:05 PM, Doug Williams d...@twitter.comwrote: Well said, Duane. Thanks, Doug On Wed, Jul 29, 2009 at 7:18 AM, Duane Roelands duane.roela...@gmail.com wrote: First, let me state from the start that I am no fan of OAuth, Twitter's implementation of it, or the way that they've behaved with regard to it. Now, with all that being said. If your website expects me to hand over my Twitter password, I'm not using your web site. Just yesterday, another scam site (TwitViewer) managed to steal thousands of accounts, and convince other people to hand over their information because it was posting tweets from the stolen accounts. OAuth is not perfect, but it provides individual users and Twitter with a way to identify bad actors and lock them out of the ecosystem. OAuth works. There are examples out there. There are developers who are willing to help you. Implementing OAuth tells your customers that the security of their account is important to you, and shutting down Basic Auth trains your users to stop giving away their password. If your product has value, and you clearly communicate what that value is, the users will use OAuth. On Jul 29, 9:10 am, Dewald Pretorius dpr...@gmail.com wrote: It would not surprise me at all if using OAuth resulted in fewer signups. Potential technical advantages of OAuth aside, every additional click that you add in the conversion process adds an addition leakage point where some users can and will abandon the signup process. -- 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. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids
First off, thanks for the heads up and giving us a large lead time. It's what I asked for in a previous email, and even if you never read that email and this isn't a response to me at all. I'll say thanks anyway, because it's great. :-) But, forgive me if I'm off base, but you're saying this change is going to happen just like a switch. One minute the API will behave one way, then next minute the API will behave differently? Doesn't this level of behavior change merit a bit of a deprecation period where both behaviors function? After a sudden change any app still using the old behavior is guaranteed to fail. If the app fixes early then it will fail up until the api change. In other words, ALL APPS that use this api call WILL be guaranteed to FAIL for some period of time. That seems like a pretty ugly prospect. Many api temper this sort of change in behavior by adding a new method call or a new argument to the method call. And for some period of time letting both function while marking the old method deprecated, use at the risk of being abandoned without warning at the next update. This lets apps update from one functioning call to another functioning call without users experiencing any downtime. I understand that some changes might need to be rolled in quickly to avert infrastructure disaster or to patch security holes, but with 2 weeks notice, I'm guessing that's not what we're dealing with here. Isaiah YourHead Software supp...@yourhead.com http://www.yourhead.com On Jul 31, 2009, at 11:09 AM, Arik Fraimovich wrote: On Jul 31, 9:03 pm, Alex Payne a...@twitter.com wrote: To clarify, since several people have asked: this pending change does NOT mean that pagination is required. You can still attempt to retrieve all IDs in one call, but be aware that this is likely to time out or fail for users with large social graphs. What is defined as large social graphs? -- Arik Fraimovich follow me on twitter: http://twitter.com/arikfr
[twitter-dev] Re: 401 Unauthorized When Getting an Access Token
Please, if anyone can assist I would be grateful. Here is a sample of my url I've formed to get the access token: http://twitter.com/oauth/access_token?oauth_consumer_key=myconsumerkeyoauth_nonce=6475147oauth_signature=mysignatureoauth_signature_method=HMAC-SHA1oauth_timestamp=1248981982oauth_token=mytokenoauth_version=1.0 -Matt On Jul 30, 7:49 pm, mattarnold1977 matt.arnold.1...@gmail.com wrote: I am using ASP .NET (VB) to try and authenticate using oAuth. I have been able to get a request token and direct a user to Twitter's authentication page. Twitter then redirects back to my app. At that point I attempt to get an access token, but I continue to receive 401 unauthorized errors. I have made sure that I am getting a new signature, using both the token and token secret when generating the signature, and that my url parameters are in alphabetical order, but I continue to get 401 errors. Has anyone experienced this, and if so, could you point me in the right direction toward diagnosing this issue? -Matt
[twitter-dev] Internal Server Error on statuses/update with OAuth
Hi, Since few hours statuses/update return always Internal Server Error! I work on my own lib for Twitter with OAuth authentification on Android plateform. Yesterday and this morning, I have no problem. Now, it always work for all others method that I used : oauth/ request_token, oauth/access_token and account/verify_credentials.
[twitter-dev] Re: Help signing OAuth requests
Thanks for the tip, Marcel. I am trying to build my signed requests using that page, but I found this weird thing: The hueniverse page converts véio (in Brazil most words have such marks) to v%C3%A9io but my C# lib UrlEncode method outputs v%E9io So does this URL encode example page http://www.albionresearch.com/misc/urlencode.php Any help ? Thanks. On 30 jul, 18:58, Marcel Molina mar...@twitter.com wrote: For those who might be struggling to ensure their OAuth signatures are being generated correctly, this guide provides more hand holding with the process than the specification. It includes custom forms where you can fill out all the details of your request and see what the signature and its related data *should* be. http://www.hueniverse.com/hueniverse/2008/10/beginners-gui-1.html -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio
[twitter-dev] Re: 401 Unauthorized When Getting an Access Token
Since you're not including an oauth_callback, i would assume you're using the oob flow, in which case, i have to ask, where's your oauth_verifier parameter? On Fri, Jul 31, 2009 at 13:09, mattarnold1977 matt.arnold.1...@gmail.comwrote: Please, if anyone can assist I would be grateful. Here is a sample of my url I've formed to get the access token: http://twitter.com/oauth/access_token?oauth_consumer_key=myconsumerkeyoauth_nonce=6475147oauth_signature=mysignatureoauth_signature_method=HMAC-SHA1oauth_timestamp=1248981982oauth_token=mytokenoauth_version=1.0 -Matt On Jul 30, 7:49 pm, mattarnold1977 matt.arnold.1...@gmail.com wrote: I am using ASP .NET (VB) to try and authenticate using oAuth. I have been able to get a request token and direct a user to Twitter's authentication page. Twitter then redirects back to my app. At that point I attempt to get an access token, but I continue to receive 401 unauthorized errors. I have made sure that I am getting a new signature, using both the token and token secret when generating the signature, and that my url parameters are in alphabetical order, but I continue to get 401 errors. Has anyone experienced this, and if so, could you point me in the right direction toward diagnosing this issue? -Matt -- Internets. Serious business.
[twitter-dev] Re: Help signing OAuth requests
the former is assuming UTF-8, which is likely the correct assumption to make. %E9 is the actual unicode codepoint, whereas the %C3%A9 is the UTF-8 encoding of said codepoint. I believe the API wiki says something about requiring UTF-8 encoding (and if it doesn't, it should). On Fri, Jul 31, 2009 at 13:14, Ney Garcia neygar...@gmail.com wrote: Thanks for the tip, Marcel. I am trying to build my signed requests using that page, but I found this weird thing: The hueniverse page converts véio (in Brazil most words have such marks) to v%C3%A9io but my C# lib UrlEncode method outputs v%E9io So does this URL encode example page http://www.albionresearch.com/misc/urlencode.php Any help ? Thanks. On 30 jul, 18:58, Marcel Molina mar...@twitter.com wrote: For those who might be struggling to ensure their OAuth signatures are being generated correctly, this guide provides more hand holding with the process than the specification. It includes custom forms where you can fill out all the details of your request and see what the signature and its related data *should* be. http://www.hueniverse.com/hueniverse/2008/10/beginners-gui-1.html -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio -- Internets. Serious business.
[twitter-dev] Re: 2 week advance notice: changes to /friends/ids and /followers/ids
Thanks for the heads-up on this change! Good show. On Jul 31, 3:06 pm, Isaiah supp...@yourhead.com wrote: First off, thanks for the heads up and giving us a large lead time. It's what I asked for in a previous email, and even if you never read that email and this isn't a response to me at all. I'll say thanks anyway, because it's great. :-) But, forgive me if I'm off base, but you're saying this change is going to happen just like a switch. One minute the API will behave one way, then next minute the API will behave differently? Doesn't this level of behavior change merit a bit of a deprecation period where both behaviors function? After a sudden change any app still using the old behavior is guaranteed to fail. If the app fixes early then it will fail up until the api change. In other words, ALL APPS that use this api call WILL be guaranteed to FAIL for some period of time. That seems like a pretty ugly prospect. Many api temper this sort of change in behavior by adding a new method call or a new argument to the method call. And for some period of time letting both function while marking the old method deprecated, use at the risk of being abandoned without warning at the next update. This lets apps update from one functioning call to another functioning call without users experiencing any downtime. I understand that some changes might need to be rolled in quickly to avert infrastructure disaster or to patch security holes, but with 2 weeks notice, I'm guessing that's not what we're dealing with here. Isaiah YourHead Software supp...@yourhead.comhttp://www.yourhead.com On Jul 31, 2009, at 11:09 AM, Arik Fraimovich wrote: On Jul 31, 9:03 pm, Alex Payne a...@twitter.com wrote: To clarify, since several people have asked: this pending change does NOT mean that pagination is required. You can still attempt to retrieve all IDs in one call, but be aware that this is likely to time out or fail for users with large social graphs. What is defined as large social graphs? -- Arik Fraimovich follow me on twitter:http://twitter.com/arikfr
[twitter-dev] Introducing Chad Etzel, Twitter Platform Support
Hi all -- We are excited to announce that Chad Etzel has joined our team part-time to support the developer community. He is the one man show behind TweetGrid [1] amongst other projects [2]. We reached out to Chad to join our team after his continual and valuable participation in the community made his passion for the Platform evident. The Platform team is not the only Twitter team that noticed his value. On a recent trip to our local coffee shop [3], a search engineer shared that Chad often notices search defects and suggests fixes consistently ahead of most other developers. He is one of the most experienced Twitter API developers in the community and we feel this experience will serve developers' interests well. Chad will be helping to answer requests that enter our support channels [3] to bolster our support to developer community. He will be working remotely from his home in North Carolina. You can follow him on Twitter at http://twitter.com/jazzychad. We are happy to have Chad on our team an look forward to continuing to build support as a pillar of our offering .The API is hiring passionate developers and evangelists so if you are interested in getting involved, please let us know. 1. http://tweetgrid.com 2. http://jazzychad.net 3. http://twitpic.com/a99zj (@noradio and @al3x in frame) Thanks, Doug
[twitter-dev] Re: Introducing Chad Etzel, Twitter Platform Support
Well done Chad. It's nice to see Twitter looking out for some of the developers in the community. :)
[twitter-dev] oAuth Token JSON
Hey all, I'm working on a Javascript library for full API access with Twitter, and a current hickup in the system is fetching the oAuth token from Javascript. I'm new to the twitter API, so I'm not sure if I'm missing something, but I can't seem to get my API call to: http://twitter.com/oauth/request_token to return JSON to me. Is this something doable? (Ideally through a jsonp implementation)
[twitter-dev] Twitpocalypse: The Second Coming is on the horizon
Twitter status ids are fast approaching the maximum 32-bit *unsigned* integer value (4,294,967,295). The current estimate is that this will occur in approximately 60 days, at the end of September. The 60 day window is a best-guess approximation based on projections. It could conceivably happen sooner. Developers are encouraged to not only update their applications to use a 64-bit integer (BIGINT/long long), but also verify that all libraries they use are also prepared to handle 64-bit integers. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Introducing Chad Etzel, Twitter Platform Support
Thanks, Doug! I really appreciate all the well-wishing tweets and emails. I have been noticeably silent on the list recently while all of these details have been worked out. Now that it's official I can get back to responding. As always, if you have suggestions about making the lines of communication more effective between Twitter and the app developers, please let us know. While my personal account will remain @jazzychad, I am planning on using @jazzychadAPI for more Twitter API related information. Thanks, -Chad Twitter API Platform Support On Fri, Jul 31, 2009 at 4:59 PM, Doug Williamsd...@twitter.com wrote: Hi all -- We are excited to announce that Chad Etzel has joined our team part-time to support the developer community. He is the one man show behind TweetGrid [1] amongst other projects [2]. We reached out to Chad to join our team after his continual and valuable participation in the community made his passion for the Platform evident. The Platform team is not the only Twitter team that noticed his value. On a recent trip to our local coffee shop [3], a search engineer shared that Chad often notices search defects and suggests fixes consistently ahead of most other developers. He is one of the most experienced Twitter API developers in the community and we feel this experience will serve developers' interests well. Chad will be helping to answer requests that enter our support channels [3] to bolster our support to developer community. He will be working remotely from his home in North Carolina. You can follow him on Twitter at http://twitter.com/jazzychad. We are happy to have Chad on our team an look forward to continuing to build support as a pillar of our offering .The API is hiring passionate developers and evangelists so if you are interested in getting involved, please let us know. 1. http://tweetgrid.com 2. http://jazzychad.net 3. http://twitpic.com/a99zj (@noradio and @al3x in frame) Thanks, Doug
[twitter-dev] Re: Twitpocalypse: The Second Coming is on the horizon
Huh? I thought this issue was resolved already? My developer for www.MyTwitterButler.com said he solved this problem back in June? Am I missing something? Cheers, Dean -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Marcel Molina Sent: Friday, July 31, 2009 5:53 PM To: twitter-development-talk@googlegroups.com; twitter-api-annou...@googlegroups.com Subject: [twitter-dev] Twitpocalypse: The Second Coming is on the horizon Twitter status ids are fast approaching the maximum 32-bit *unsigned* integer value (4,294,967,295). The current estimate is that this will occur in approximately 60 days, at the end of September. The 60 day window is a best-guess approximation based on projections. It could conceivably happen sooner. Developers are encouraged to not only update their applications to use a 64-bit integer (BIGINT/long long), but also verify that all libraries they use are also prepared to handle 64-bit integers. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Twitpocalypse: The Second Coming is on the horizon
The first Twitpocalypse involved the tweet ID's moving past the highest 32-bit *signed* integer (which is 2,147,483,647). This time around the tweet ID's will move past the highest 32-bit *un*signed integer (which is 4,294,967,295). Developers should make sure the code they are using to store/manipulate tweet ID's is treating them as (at least) 64 bit integers (BIGINT in sql or long long in some other typed languages, unsigned preferably). Some people have expressed storing tweet ID's as strings, however never having personally done that, I'm not fully aware of the implications of doing so. -Chad Twitter Platform Team On Fri, Jul 31, 2009 at 6:21 PM, Dean Collinsd...@cognation.net wrote: Huh? I thought this issue was resolved already? My developer for www.MyTwitterButler.com said he solved this problem back in June? Am I missing something? Cheers, Dean -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Marcel Molina Sent: Friday, July 31, 2009 5:53 PM To: twitter-development-talk@googlegroups.com; twitter-api-annou...@googlegroups.com Subject: [twitter-dev] Twitpocalypse: The Second Coming is on the horizon Twitter status ids are fast approaching the maximum 32-bit *unsigned* integer value (4,294,967,295). The current estimate is that this will occur in approximately 60 days, at the end of September. The 60 day window is a best-guess approximation based on projections. It could conceivably happen sooner. Developers are encouraged to not only update their applications to use a 64-bit integer (BIGINT/long long), but also verify that all libraries they use are also prepared to handle 64-bit integers. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Twitpocalypse: The Second Coming is on the horizon
Well 64 bit should last for a while. Curious how long it will be until 128 bit will be required.
[twitter-dev] Re: Twitpocalypse: The Second Coming is on the horizon
Just store everything in strings and give up :-) Zac Bowling On Fri, Jul 31, 2009 at 3:37 PM, Josh Roessleinjroessl...@gmail.com wrote: Well 64 bit should last for a while. Curious how long it will be until 128 bit will be required.
[twitter-dev] Re: Twitpocalypse: The Second Coming is on the horizon
On Jul 31, 2009, at 3:37 PM, Josh Roesslein wrote: Well 64 bit should last for a while. Curious how long it will be until 128 bit will be required. Mathematica tells me: Fri 24 Sep 58821 22:55:00 I think you'll be fine for a long time at 64 bit. -john --- John Adams Twitter Operations j...@twitter.com http://twitter.com/netik
[twitter-dev] Re: Twitpocalypse: The Second Coming is on the horizon
On Fri, Jul 31, 2009 at 6:59 PM, John Adams j...@twitter.com wrote: On Jul 31, 2009, at 3:37 PM, Josh Roesslein wrote: Well 64 bit should last for a while. Curious how long it will be until 128 bit will be required. Mathematica tells me: Fri 24 Sep 58821 22:55:00 I think you'll be fine for a long time at 64 bit. -john --- John Adams Twitter Operations j...@twitter.com http://twitter.com/netik but why not go with 128 bit decimal/floating point precision datatypes to begin with, and never have this issue? if anyone says overhead I'm gonna whack 'em like a popup weasel. in this day and age of CPU cycles and RAM, you might as well go big or go home. --ab
[twitter-dev] Re: Twitpocalypse: The Second Coming is on the horizon
Srew it. Go with 1024 bit unsigned int! Abraham On Fri, Jul 31, 2009 at 18:04, Andrew Badera and...@badera.us wrote: On Fri, Jul 31, 2009 at 6:59 PM, John Adams j...@twitter.com wrote: On Jul 31, 2009, at 3:37 PM, Josh Roesslein wrote: Well 64 bit should last for a while. Curious how long it will be until 128 bit will be required. Mathematica tells me: Fri 24 Sep 58821 22:55:00 I think you'll be fine for a long time at 64 bit. -john --- John Adams Twitter Operations j...@twitter.com http://twitter.com/netik but why not go with 128 bit decimal/floating point precision datatypes to begin with, and never have this issue? if anyone says overhead I'm gonna whack 'em like a popup weasel. in this day and age of CPU cycles and RAM, you might as well go big or go home. --ab -- 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. Sent from Madison, Wisconsin, United States
[twitter-dev] Re: Twitpocalypse: The Second Coming is on the horizon
On Fri, Jul 31, 2009 at 3:59 PM, John Adams j...@twitter.com wrote: On Jul 31, 2009, at 3:37 PM, Josh Roesslein wrote: Well 64 bit should last for a while. Curious how long it will be until 128 bit will be required. Mathematica tells me: Fri 24 Sep 58821 22:55:00 Darn it - I was planning to be on vacation that day! Nick
[twitter-dev] Re: Introducing Chad Etzel, Twitter Platform Support
Awesome Chad! Sent from my iPhone On Jul 31, 2009, at 2:59 PM, Chad Etzel c...@twitter.com wrote: Thanks, Doug! I really appreciate all the well-wishing tweets and emails. I have been noticeably silent on the list recently while all of these details have been worked out. Now that it's official I can get back to responding. As always, if you have suggestions about making the lines of communication more effective between Twitter and the app developers, please let us know. While my personal account will remain @jazzychad, I am planning on using @jazzychadAPI for more Twitter API related information. Thanks, -Chad Twitter API Platform Support On Fri, Jul 31, 2009 at 4:59 PM, Doug Williamsd...@twitter.com wrote: Hi all -- We are excited to announce that Chad Etzel has joined our team part- time to support the developer community. He is the one man show behind TweetGrid [1] amongst other projects [2]. We reached out to Chad to join our team after his continual and valuable participation in the community made his passion for the Platform evident. The Platform team is not the only Twitter team that noticed his value. On a recent trip to our local coffee shop [3], a search engineer shared that Chad often notices search defects and suggests fixes consistently ahead of most other developers. He is one of the most experienced Twitter API developers in the community and we feel this experience will serve developers' interests well. Chad will be helping to answer requests that enter our support channels [3] to bolster our support to developer community. He will be working remotely from his home in North Carolina. You can follow him on Twitter at http://twitter.com/jazzychad. We are happy to have Chad on our team an look forward to continuing to build support as a pillar of our offering .The API is hiring passionate developers and evangelists so if you are interested in getting involved, please let us know. 1. http://tweetgrid.com 2. http://jazzychad.net 3. http://twitpic.com/a99zj (@noradio and @al3x in frame) Thanks, Doug
[twitter-dev] Re: Twitpocalypse: The Second Coming is on the horizon
On Fri, Jul 31, 2009 at 7:07 PM, Abraham Williams 4bra...@gmail.com wrote: Srew it. Go with 1024 bit unsigned int! Hey, if the common frameworks and languages of the day supported it, sure, why not?
[twitter-dev] Re: oAuth Token JSON
That will never return JSON, per the OAuth spec. It will return a token in the HTTP Query String format. If you are using Dojo, you can use dojo.queryToObject to convert it to json. On Fri, Jul 31, 2009 at 14:59, Eric Garside gars...@gmail.com wrote: Hey all, I'm working on a Javascript library for full API access with Twitter, and a current hickup in the system is fetching the oAuth token from Javascript. I'm new to the twitter API, so I'm not sure if I'm missing something, but I can't seem to get my API call to: http://twitter.com/oauth/request_token to return JSON to me. Is this something doable? (Ideally through a jsonp implementation) -- Internets. Serious business.
[twitter-dev] Re: oAuth Token JSON
alternatively, you could of course do something like this:
var token = {};
var parts = theReturnString.split('');
for (var part in parts) {
var parm = part.split('=');
token[parm[0]] = parm[1] || ;
}
On Fri, Jul 31, 2009 at 17:54, JDG ghil...@gmail.com wrote:
That will never return JSON, per the OAuth spec. It will return a token in
the HTTP Query String format. If you are using Dojo, you can use
dojo.queryToObject to convert it to json.
On Fri, Jul 31, 2009 at 14:59, Eric Garside gars...@gmail.com wrote:
Hey all,
I'm working on a Javascript library for full API access with Twitter,
and a current hickup in the system is fetching the oAuth token from
Javascript.
I'm new to the twitter API, so I'm not sure if I'm missing something,
but I can't seem to get my API call to:
http://twitter.com/oauth/request_token
to return JSON to me. Is this something doable? (Ideally through a
jsonp implementation)
--
Internets. Serious business.
--
Internets. Serious business.
[twitter-dev] Re: Twitpocalypse: The Second Coming is on the horizon
On Jul 31, 2009, at 4:04 PM, Andrew Badera wrote: but why not go with 128 bit decimal/floating point precision datatypes to begin with, and never have this issue? if anyone says overhead I'm gonna whack 'em like a popup weasel. in this day and age of CPU cycles and RAM, you might as well go big or go home. Because none of us will be alive in the year 58,821. -john
[twitter-dev] Re: Twitpocalypse: The Second Coming is on the horizon
@John Adams How do you know it will be ok till 58821? How many new twitter user sign-up each days? I just do a google and 2^64 = *1.84467441 × 1019*I don't know how you calculater which days? We can not know how many news user will register twitter? 2009/8/1 John Adams j...@twitter.com On Jul 31, 2009, at 4:04 PM, Andrew Badera wrote: but why not go with 128 bit decimal/floating point precision datatypes to begin with, and never have this issue? if anyone says overhead I'm gonna whack 'em like a popup weasel. in this day and age of CPU cycles and RAM, you might as well go big or go home. Because none of us will be alive in the year 58,821. -john
[twitter-dev] Very Simple OAuth Question
Once an Access Token and Token Secret have been obtained and stored in the app's database, can the app then access the user's protected resources until the user revokes access, or is there a certain timeframe after which the access token automatically expires (and must be renewed)?
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
Christopher, It is good to see that someone understands the bigger picture here. This conversation suffers from a presumption of a specific use-case (web application communicating with Twitter), and a particular presumption of trust, or lack thereof. The particular comments such as: You can lead a horse to water ... and This is not rocket science. pretty much demonstrate a very narrow contextual view, in which their view might make sense, but outside of which it does not. Restated, this is optimistic thinking from the perspective of their particular use case, and ignores the perspective of either other use cases, and overlooks someone trying to exploit a security vulnerability. To my knowledge, and certainly in this conversation, OAuth is being touted as an across-the-board superior security approach for ALL use cases. Having spent the better part of the last two and half years doing secure data storage development far more complex than that of just authorization, but also securing the payloads across an entire cloud and desktops, and the network as a whole, my comments here are simply to see the claim of OAuth being undisputably superior supported with fact against legitimate breach points. I'll give an example. My personal development use case for security is communicating with Twitter from an iPhone app. Applying the same broad brush you wouldn't give your data to a complete stranger comments to the iPhone, your complete stranger here is the iPhone app you are using. So effectively, your complete stranger assertion maps to the following: 1) You've downloaded an app from the App Store with the intention of using it for communicating with Twitter, yet it is considered a complete stranger, and untrusted. 2) You use the app, and explicitly initiate communication to Twitter within this very complete stranger. This complete stranger assertion is absurd. First, you haven't treated the iPhone app like a complete stranger. You explicitly downloaded (and likely paid money) to explicitly put this application on your phone. Furthermore, it doesn't really matter if you pull up the OAuth login page within your iPhone app. That complete stranger iPhone app could capture keyboard events and/or filter EVERYTHING you send across the wire prior to any encryption being applied. Furthermore, even if OAuth itself isn't breached, as soon as your token is acquired, what's to prevent the app from then going absolutely haywire with your account, posting malicious status, following / blocking who it chooses, etc.? Furthermore, all of the other apps comments don't directly apply -- every app on the iPhone is sandboxed, which protects it from any other app tampering or accessing data. The only breach of this, of course, is jailbreaking, but then again this is analogous to someone hacking and owning the desktop you are browsing on, in which case OAuth is no protection again. The variance for desktop apps is that they aren't sandboxed away from other apps on the machine, but other than that, most of this all applies to that environment too. Unless other information surfaces, Christopher, best I can tell, you are spot on. OAuth seems particularly relevant to web applications, and relevant to desktop and iPhone apps primarily if your desktop / iPhone are NOT password protected, and the application in question has stored credentials, and you either lose or have stolen your desktop / iPhone. In conclusion, addressing one last example of ATM cards and pins -- you picked the safe example. A credit card is far less safe than all of this, because lose one of those, and the finder is on a shopping spree, no ID or pin required. And I'd bet 99% of this mailing list, including the OAuth devotees, carry a credit card, and don't think twice about the fact that they are one hole in their pocket away from receiving a truckload of Shamwow's delivered to their house. Regards, Brad On Jul 31, 2009, at 7:41 AM, Christopher St John wrote: On Thu, Jul 30, 2009 at 6:07 PM, Bradley S. O'Hearnebrad.ohea...@gmail.com wrote: I really want to hear stated, or read on a FAQ, is the pre-requisite security trust, that in that scenario, it necessarily makes OAuth superior to basic authentication. The problem here is that you're paying attention, instead of just accepting oauth is better because it is! statements :-) For desktop apps (and in any case where the application has has control of the UI and/or your computer) OAuth has no security advantage (since the app can snoop the interaction) I'm sure bad people are working on a way to make this true in browser apps as well, but I don't know of any examples. For web applications, many commentators acknowledge an increased risk of phishing as a potential problem with OAuth, although I haven't personally read any studies that indicate whether it's a theoretical or practical
[twitter-dev] Re: Very Simple OAuth Question
Per the OAuth spec: Access Tokens MAY limit access to certain Protected Resources, and MAY have a limited lifetime. [1] At this time, I don't believe Twitter expires their access token, but that doesn't mean you shouldn't take it into account, as they may decide to in the future. [1] http://oauth.net/core/1.0/#anchor9 On Fri, Jul 31, 2009 at 20:54, Dewald Pretorius dpr...@gmail.com wrote: Once an Access Token and Token Secret have been obtained and stored in the app's database, can the app then access the user's protected resources until the user revokes access, or is there a certain timeframe after which the access token automatically expires (and must be renewed)? -- Internets. Serious business.
[twitter-dev] Re: OAUTH: Basic Auth is simpler/more reliable/more secure/better received than OAuth!?
On Fri, Jul 31, 2009 at 21:02, Bradley S. O'Hearne brad.ohea...@gmail.comwrote: In conclusion, addressing one last example of ATM cards and pins -- you picked the safe example. A credit card is far less safe than all of this, because lose one of those, and the finder is on a shopping spree, no ID or pin required. And I'd bet 99% of this mailing list, including the OAuth devotees, carry a credit card, and don't think twice about the fact that they are one hole in their pocket away from receiving a truckload of Shamwow's delivered to their house. My God, you're RIGHT. I could have a hole in my pocket, lose my credit card, and NEVER BE ABLE TO BUY THE TRUCKLOAD OF SHAMWOWS I SO RICHLY DESIRE. I assume that's what you meant, anyway ;) -- Internets. Serious business.
[twitter-dev] Oauth Ruby Example on Wiki
Hi, Any reason we can no longer access this page on the wiki? http://apiwiki.twitter.com/OAuth+Example+-+Ruby It know it used to be public, and it was very helpful. Thanks
[twitter-dev] Re: Updating the APIs authentication limiting policy
Hi Doug, Is there a timescale for rolling back / making the change to the new scheme? We're just putting the finishing touches to moving to OAuth and we're experiencing the issue when using verify_credentials to get the users basic details once we've got the token back from the authentication process. We're experiencing the issue when: 1. Testing our login and authentication processes 2. When users login and logout of our application frequently A heads up on when these changes will be made would be useful. Thanks, Bob On Jul 29, 6:37 pm, Grant Emsley grant.ems...@gmail.com wrote: Locked out of authenticated resources for that account, or will that IP not be able to login to any account? On Jul 29, 1:14 pm, Doug Williams d...@twitter.com wrote: Ray,For clarity, we will roll back the current restriction of 15 calls per user per hour to account/verify_credentials, and implement the proposed scheme: ... we will limit the total number of unsuccessful attempts to access authenticated resources to 15 an hour per user per IP address. If a single IP address makes 15 attempts to access a protected resource unsuccessfully for a given user (as indicated by an HTTP 401), then the user will be locked out of authenticated resources from that IP address for 1 hour. Thanks, Doug On Wed, Jul 29, 2009 at 9:51 AM, Ray rvizz...@testlabs.com wrote: Doug, I'm in a similar situation as that voiced by TinBlue. This change has affected our iPhone App. We also want to encourage you to rollback this change ASAP. When you say This approach is what we are going to take., do you mean rolling back the fix so as not to affect multiple, successful, authorized logins? I'm hopeful that this approach means that our apps will not be affected yet again by changing to a new auth approach. I appreciate you all keeping this thread informed. Ray On Jul 27, 11:23 am, Doug Williams d...@twitter.com wrote: Thanks to everyone who has contributed feedback. This approach is what we are going to take. Alex will be making this change shortly. I will update this thread when there is timeframe to share. Thanks, Doug On Mon, Jul 27, 2009 at 7:52 AM, TinBlue tinb...@gmail.com wrote: What is happening? This rollback is taking far too long for something that has affected a lot of people! On Jul 25, 2:32 pm, Dewald Pretorius dpr...@gmail.com wrote: Doug, I would prefer to adopt OAuth instead of writing code for Basic Auth. So, you guys need to move OAuth out of public beta into full production sooner rather than later. :-) I manage 100,000+ Twitter accounts, and I simply cannot take on the support workload of answering user tickets when there's a snag with OAuth beta. I monitor these forums and the API Issues and still see too many OAuth issues being reported to give me a level of comfort that I can safely switch over to OAuth. On Jul 24, 5:46 pm, Doug Williams d...@twitter.com wrote: Well said Joshua. Dewald, you have identified the risk of using basic authentication. If your users being locked out due to malicious behavior, you should either implement further user-level rate limiting on your side or adopt OAuth. Are there any other glaring omissions in our thinking or should we proceed with this as our solution? Thanks, Doug On Fri, Jul 24, 2009 at 11:08 AM, Joshua Perryj...@6bit.com wrote: Jim's concern is valid, fortunately OAuth is immune to brute-force attacks once the access key has been issued to an application. For this reason alone I would urge people to switch to OAuth if at all possible. I would hope (and assume) that if login attempts for an account are locked out that a user would still be able to successfully use an already authorized OAuth driven application. Unfortunately allowing a successful un/pw login while an account is locked out even when the correct password is presented effectively bypasses the whole reason for a lockout in the first place, preventing brute-force password attempts. If an attacker used a dictionary or brute-force attack and the account was locked out after 15 attempts, then they could continue trying even though the system replied locked out; if they eventually sent the correct password it would just bypass the lockout and they would then know the correct password. Perhaps Twitter could implement a selective captcha, I know they are annoying but if executed properly it could be effective protection against brute-force and dictionary attacks. Say after 3 or
[twitter-dev] Re: Introducing Chad Etzel, Twitter Platform Support
Welcome :) On Jul 31, 9:59 pm, Doug Williams d...@twitter.com wrote: Hi all -- We are excited to announce that Chad Etzel has joined our team part-time to support the developer community. He is the one man show behind TweetGrid [1] amongst other projects [2]. We reached out to Chad to join our team after his continual and valuable participation in the community made his passion for the Platform evident. The Platform team is not the only Twitter team that noticed his value. On a recent trip to our local coffee shop [3], a search engineer shared that Chad often notices search defects and suggests fixes consistently ahead of most other developers. He is one of the most experienced Twitter API developers in the community and we feel this experience will serve developers' interests well. Chad will be helping to answer requests that enter our support channels [3] to bolster our support to developer community. He will be working remotely from his home in North Carolina. You can follow him on Twitter athttp://twitter.com/jazzychad. We are happy to have Chad on our team an look forward to continuing to build support as a pillar of our offering .The API is hiring passionate developers and evangelists so if you are interested in getting involved, please let us know. 1.http://tweetgrid.com 2.http://jazzychad.net 3.http://twitpic.com/a99zj(@noradio and @al3x in frame) Thanks, Doug
[twitter-dev] Re: URI Escape fix for OAuth - correct usage of uri_escape() with Perl
this is my 1st twitter dev, and i've been wondering what i've done wrong with the oauth stuff. as it turns out, only some of the problems i've faced have been mine! thanks for the updates and info chinaski007 Scott i'd like to add some keywords to this post so others may find it: Incorrect Signature perl Net::Twitter oauth twitter dev On Jul 29, 8:32 am, chinaski007 chinaski...@gmail.com wrote: If you are using Net::Twitter inPerl, 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 towardPerlimplementations 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 inPerlis 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/
