Re: Getting 503 errors with search API
I recommend getting your IP white listed. http://twitter.com/help/request_whitelisting On Jan 4, 9:16 am, Amir Michail amich...@gmail.com wrote: Hi, What would be reasonable usage for the search API? And if I need more, can I request more? I'm making the requests server-side without authentication. Amir
Friends / Followers without authentication?
Hi,
Is is possible to retrieve a list of peoples friends and followers
without authenticating with Twitter?
I've discovered http://twitter.com/statuses/friends/{username}.xml
which seems to work but the equivalent
http://twitter.com/statuses/followers/{username}.xml
requires authentication.
I can create a Twitter account and use those login details as the
authentication but it's limited to a maximum of 100 requests per hour,
which isn't any good for an application.
Any help appreciated
Pete
Re: a simple workaround for lack of OAuth
On Jan 2, 11:31 pm, Jesse Stay jesses...@gmail.com wrote: Well put Chris - I had forgotten about that. I just want something - I don't care what, but I need it soon, as it's starting to make it really difficult to market my App and keep users feeling secure. I *hate* knowing my users Twitter passwords (I have over 5,000 of them - it's really scary that I do). I sincerely hope this is top priority for Twitter right now - it should have been implemented last year so long as they have an API in place. On my App, it took about 2 hours max to write, test, and implement a very simple API key system like this for the API I'm providing. I don't get why it's taking Twitter so long. John Adams from Twitter's operations team replied to my post on this subject: The plan is to support Basic Auth and OAuth concurrently, for at least 6 months, if not more. We can’t completely turn off the Basic Auth API without having a large impact to many APIs and clients. http://factoryjoe.com/blog/2009/01/02/twitter-and-the-password-anti-pattern/comment-page-1/#comment-103431 So, you will be given an option (no telling when) to use OAuth instead of the plaintext username/password combo. Of course it means many folks will still use the lowest common denominator (and the most insecure method available) for some time, but at least there will be a good transitional time period where developers who want to use OAuth can do so, paving a path for those who will need to migrate later. Heck if Flickr could get its user base to move over to Yahoo accounts, I imagine Twitter will be able to get app developers and users to move over to OAuth in six months. Chris
Direct Destory in Docs points to regular Destory
Just thought I would pass along that when you click on the help link for the Destory for Direct Messages it takes you to #destory which is the regular Tweet destroy Thought maybe someone could update the docs to reflect so others do hist the smame issue of using the wrong URL Dave
Re: a simple workaround for lack of OAuth
We'll certainly be doing our utmost to incentivize developers to move to OAuth. The next major version of the API will be OAuth-only, for example. This is where I get antsy, and maybe Chris can point out some ways to deal with this, but from my perspective as a desktop client author OAuth is a lot of hurt without a lot of benefit to me the developer (other than it's the only way in so love it or lump it), and I think even the user's benefits are nebulous. If you don't trust an application, you shouldn't be running it. Isn't that where Trojan horses come in? But let's say that there is (a) good reason for a desktop application to use OAuth as its primary method; now I have a technical question. The way I'm reading http://oauth.net/core/1.0/ is that I go and get a request token (A.2), but I need to redirect a user to a service provider's login page (ouch) for her to authorize that token (A.3), then provide a callback URL (double ouch) (A.3). At best this is turning my application into not only a Twitter client, but also a web server (to accept the callback). At worst this isn't possible because the Service provider *can't* call me back due to network restrictions on the desktop machine. Also, since TTYtter is text based, I *really* don't want to be opening up a browser to get logins (or if I do, I want it to be Lynx, and fat chance I bet). Clearly OAuth is the way to go for standalone web sites talking to Twitter, but I get nervous about hearing OAuth will be the only method of access while trying to work through the issues unique to a desktop client. I would appreciate hearing from someone knowledgeable about the best way to overcome these issues, or if there is a special way that I missed where an application can authenticate itself by just asking the user for their OAuth credentials and proxy everything to the service provider, which would also suck, but less, from a developer standpoint. (But that would also probably defeat the purpose of OAuth.) -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Blanket statements are always wrong. ---
Re: a simple workaround for lack of OAuth
Anecdotally, you can look at most any Flickr app to see how they handle an auth system that's very similar to OAuth. It does often involve bouncing to the browser, but that's the intended workflow. That's what I mean. This would definitely be UX hurt for a standalone application, and it still doesn't solve the callback problem. Chris? -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- This message will self-destruct in five seconds. Good luck, Jim. -- M:I
Uniqueness of screen_name
Hi, Aren't screen_names (from http://twitter.com/users/show/twitter_id.xml) supposed to be unique? For instance twitter ids 12197222, 12221352,12248852,12276002,12283472,12283902,12286122,12580542,13906422, and 14089985 all have the same screen_name. Thanks, Ram
Re: a simple workaround for lack of OAuth
Anecdotally, you can look at most any Flickr app to see how they handle an auth system that's very similar to OAuth. It does often involve bouncing to the browser, but that's the intended workflow. That's what I mean. This would definitely be UX hurt for a standalone application, and it still doesn't solve the callback problem. Chris? And one more followup is how Google tried to deal with this, which I just found. Some of these issues would be very difficult to overcome in practice. http://sites.google.com/site/oauthgoog/UXFedLogin/desktopapps -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- When the going gets weird, the weird turn pro. -- Hunter S. Thompson ---
Re: Uniqueness of screen_name
They are supposed to be unique, but there were periods in our operation where our validation code failed. I'll forward these accounts to our support staff to get them resolved. On Sun, Jan 4, 2009 at 14:19, Ram ram.ravichand...@gmail.com wrote: Hi, Aren't screen_names (from http://twitter.com/users/show/twitter_id.xml) supposed to be unique? For instance twitter ids 12197222, 12221352,12248852,12276002,12283472,12283902,12286122,12580542,13906422, and 14089985 all have the same screen_name. Thanks, Ram -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
Re: Friends / Followers without authentication?
How do they make requests while authenticated as their own account
without supplying a password? Am I missing something here... Oh they
put in their username and the request for the followers list is made
under my whitelisted account?
Think I get it now..
Thanks very much Alex
On Jan 4, 10:13 pm, Alex Payne a...@twitter.com wrote:
All they need is a username. They make requests while authenticated as
their own account.
On Sun, Jan 4, 2009 at 14:05, peterhough em...@peterhough.co.uk wrote:
You're limit requests to 100 per hour from IP addresses? In that case
I will need my server's IP white listing and will fill out the form.
Thanks!
However, this still doesn't solve the problem of requiring
authentication to list followers. Ideally I don't want people to have
to enter their Twitter password into my webform. Mr Tweet and
friendorfollow.com seem to be able to retrieve these without my
Twitter account details. How?
Regards,
Pete
On Jan 4, 9:42 pm, Alex Payne a...@twitter.com wrote:
Whether authenticated or not, we limit the number of requests per hour
to 100. We can whitelist your username and/or server's IP address(es),
though. Please fill out this form to get the process
started:http://twitter.com/help/request_whitelisting.
On Sun, Jan 4, 2009 at 06:01, peterhough em...@peterhough.co.uk wrote:
Hi,
Is is possible to retrieve a list of peoples friends and followers
without authenticating with Twitter?
I've discoveredhttp://twitter.com/statuses/friends/{username}.xml
which seems to work but the
equivalenthttp://twitter.com/statuses/followers/{username}.xml
requires authentication.
I can create a Twitter account and use those login details as the
authentication but it's limited to a maximum of 100 requests per hour,
which isn't any good for an application.
Any help appreciated
Pete
--
Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
--
Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
Racking my brain to figure out how to use users/show
I am trying to get the user picture (profile_image_url) from a Twitter account using either http://twitter.com/users/show/username.xml or http://twitter.com/users/show/username.json. My problem is that I am a PHP guy and it seems that I can't load this information via the http protocol. It would on the surface seem simple enough to do but it is not working out that way. I may be having a brain-dead-day so I thought I would ask for any ideas I may be overlooking from this bright group. Pete
Re: a simple workaround for lack of OAuth
Those who expect OAuth to be a panacea for identity theft on Twitter simply don't understand the issues involved. Operating a modern computer involves a lot of trust - trusting applications you run on your machine, trusting web sites you set up accounts on, and the like. And when you trust, there's always the potential for getting burned. OAuth doesn't change that fundamentally. I agree completely with your post, Ed. I put forward my thoughts on OAuth and phishing in April last year: http://log.lachstock.com.au/past/2008/4/1/phishing-fools/ Basically, I think OAuth is awesome, but the idea that it's going to somehow stop phishing is extreme. Lachlan Hardy
Re: a simple workaround for lack of OAuth
On Sun, Jan 4, 2009 at 5:20 PM, Lachlan Hardy lach...@lachstock.com.auwrote: Those who expect OAuth to be a panacea for identity theft on Twitter simply don't understand the issues involved. Operating a modern computer involves a lot of trust - trusting applications you run on your machine, trusting web sites you set up accounts on, and the like. And when you trust, there's always the potential for getting burned. OAuth doesn't change that fundamentally. I agree completely with your post, Ed. I put forward my thoughts on OAuth and phishing in April last year: http://log.lachstock.com.au/past/2008/4/1/phishing-fools/ Basically, I think OAuth is awesome, but the idea that it's going to somehow stop phishing is extreme. I don't get how it won't help fight phishing. Right now the worm is being spread via an App. (if it's not, then Twitter really needs a Captcha on the Twitter login page) At the moment all Twitter can do is chase down IPs to kill the App. With OAuth it would be as simple as killing the API key itself and the worm would be dead. Could they go in and create another one? Probably, but it makes it a whole lot harder for someone to create such a worm. This is the reason most of the Facebook worms right now are spreading through simple screen scraping and not the App platform. It's too much work to do it on the App platform there because Facebook would just shut you down each time their alarms went off. Jesse
Re: a simple workaround for lack of OAuth
On Sun, Jan 4, 2009 at 7:32 PM, Jesse Stay jesses...@gmail.com wrote: On Sun, Jan 4, 2009 at 5:20 PM, Lachlan Hardy lach...@lachstock.com.au wrote: Those who expect OAuth to be a panacea for identity theft on Twitter simply don't understand the issues involved. Operating a modern computer involves a lot of trust - trusting applications you run on your machine, trusting web sites you set up accounts on, and the like. And when you trust, there's always the potential for getting burned. OAuth doesn't change that fundamentally. I agree completely with your post, Ed. I put forward my thoughts on OAuth and phishing in April last year: http://log.lachstock.com.au/past/2008/4/1/phishing-fools/ Basically, I think OAuth is awesome, but the idea that it's going to somehow stop phishing is extreme. I don't get how it won't help fight phishing. Right now the worm is being spread via an App. Help us out here with what worm you mean -- there are lots of them 8) (if it's not, then Twitter really needs a Captcha on the Twitter login page) At the moment all Twitter can do is chase down IPs to kill the App. Sure. With OAuth it would be as simple as killing the API key itself and the worm would be dead. If the malicious application uses OAuth via Twitter, yes. Could they go in and create another one? Probably, but it makes it a whole lot harder for someone to create such a worm. This is the reason most of the Facebook worms right now are spreading through simple screen scraping and not the App platform. It's too much work to do it on the App platform there because Facebook would just shut you down each time their alarms went off. I'd note that it used to be too much work to spam Google Groups because of CAPTCHAs too, but almost all CAPTCHAs can be defeated now programatically and via mechanical turk-style attacks. I and a few others have to review posts from all new users for this reason. Also, why do you assume that phishing attacks would have to come via Twitter messages, though? Most come via email or web content on other sites. Twitter currently uses email notifications for several events -- faking those would be quite easy to do, for example. OAuth may have mitigated (not blocked) *one* particular worm that was sending messages directing people to a phishing site. And yes, removing everyone's shoes does stop the shoe bombing attack. Whether or not this actually makes you *safer* is something we should very carefully consider. Personally, I'd say it helps, but only a little -- far less than most of our Thought Leaders claim. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron
Re: a simple workaround for lack of OAuth
On Sun, Jan 4, 2009 at 8:55 PM, Jesse Stay jesses...@gmail.com wrote: So what do *you* recommend Ed (that goes for everyone that is criticizing OAuth, including Alex)? I see a lot of criticism against OAuth, but I see no suggestions for a solution. Perhaps you're mistaking criticism with an attempt to make for realistic expectations, and temper an artificial urgency. Generally I think OAuth is a Good Idea, and I think it's probably a good step for Twitter to take. I think I can say Alex agrees, or he and the rest of the API team wouldn't be implementing it. It's not really my job to tell Twitter what to do – first off, I think they have people with very good security backgrounds in place, and secondly I'm not on their payroll. But if you actually want to hear a few things, I'll toss them out. I don't have time or motiviation atm for a lot of detail (we just lost a family friend tonight to cancer), but I'm happy to talk about them another day in detail if you want. - immediately cease the development of any web-based applications that require user credentials. I generally don't think that you're keeping your user's best interests in mind when you do this. - educate users about risk acceptance: what it means to trust a web application with your credentials (or OAuth permissions), and what the consequences could be if trust is broken. - educate users about how to identify phishing attacks - possibly implement some personal site ID techniques on the Twitter homepage, like user-chosen identifier images Even if you do a great job on all of these, though, you will always have some people who fall for it. Right now, I think it's a step in the right direction - I see a lot of theories here, but not a lot of urgency to fix the problem. As I said, I don't care what the solution is - I just need something, other than requiring my users to enter their plain text usernames and passwords. There's huge urgency here - what's the solution to the problem? There is no solution. Really. There isn't. People who work in security will tell you this. The security industry spends millions and millions of dollars on application trust issues, and there is no solution. There are things you can do, but you can't solve the problem. You can only *mitigate* risk. People clamoring for OAuth -- this is the urgency you refer to -- are participating in security theater. They want it implemented not because it will make things a little better, but because they have been whipped up into a frenzy by ye olde Thought Leaders and want *something* to be done. I was completely serious about my shoe bomb analogy, because it's a classic security theater – oh shit, you could put a bomb in your shoe! better check everyone's shoes! It's a temporary PR fix, but it doesn't solve the problem other than making people feel better -- until the next security flavor of the week comes around. If you seriously want to study this kind of thing further, I think starting off with Schneier's Beyond Fear: Thinking Sensibly About Security in an Uncertain World would be a good idea. As a developer, you should also dig into all the security info you can, and make security a first-level concern. If you're a PHP dev (I know a lot of folks here are), I'd probably start out with Chris Shiflett's Essential PHP Security. Rails devs should keep an eye on http://www.rorsecurity.info/. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron
This is why it's Urgent
We're on the verge of a full boycott by users on apps that take passwords. Comments like this on ChrisBrogan.com keep me up at night. There's a groundswell happening, and it doesn't look pretty. I know Twitter is working on something, I just really hope it's soon. --Jesse -- Forwarded message -- From: chrisbrogan.com b...@chrisbrogan.com Date: Sun, Jan 4, 2009 at 10:29 PM Subject: [chrisbrogan.com] New Comment On: Log Into Twitter And Change Your Password To: je...@staynalive.com There is a new comment on the post Log Into Twitter And Change Your Password. http://www.chrisbrogan.com/log-into-twitter-and-change-your-password/ Author: Myron Tay Comment: Sounds simple enough. Am so not going to trust another twitter based service that requires my password. See all comments on this post here: http://www.chrisbrogan.com/log-into-twitter-and-change-your-password/#comments
Re: This is why it's Urgent
I've been lurking on this list for a while. It's a nice resource for Twitter development. I'm currently working on my own desktop Twitter app. However I have apparently missed something on this list. What exactly is wrong with an application (for Mac OS X in this case) asking for a user's Twitter user name and password. Storing the password in the OS X Keychain isn't hard at all and it is encrypted. Ed and I were sort of making that argument earlier. Have I really missed something important? Does this fever about apps asking for passwords apply to desktop and web apps, or just web apps? I'd really like to know whether or not my application would suddenly become evil because it asked for an account password. And yes, my app does inform the user that the password will be stored in the Keychain and it uses HTTPS when talking to the Twitter servers. In my opinion (I don't work for twitter or speak for them), I think 3rd party webapps have the most to gain from going OAuth, and desktop apps probably have the least. This is why I'm hoping Basic Auth will persist, even if in a limited or deprecated sense. It's not much good to make a desktop app walk the OAuth workflow because frankly an evil client application can do many more usefully evil things than simply being naughty with an OAuth token, and in some situations might make it impossible for that app to operate in a useful sense. (Think of all the little Twitter bots that are basically curl and a shell script, but still do useful monitoring work.) However, it *is* much more useful to make a 3rd party standalone web app do it, and that's why Twitter is going to offer it. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- We shoulda bought a squirrel. -- Rat Race
Re: This is why it's Urgent
If you're storing the password securely and only using HTTPS, I'd say you're doing right by your users. In the absence of OAuth, that's basically best practice. It's also a pattern that's been deemed adequate by companies like Amazon, who collect and store financial information from their customers. Christopher St John's comments above accurately reflect my own concerns. OAuth is not a security magic bullet, and it only encourages phishing attacks. I feel bad for users that have given their credentials to a phishing site, and we'll do everything we can to educate them, but token-based authentication systems are not going to fix this particular security problem. Getting worked up into hysterics about boycotts is just, as security expert Bruce Schenier is fond of saying, security theater. It's the equivalent of an apartment building's tenants telling their landlord they refuse to use keys because someone's place got broken into. On Sun, Jan 4, 2009 at 22:07, Dale Merrick theunstable...@gmail.com wrote: I've been lurking on this list for a while. It's a nice resource for Twitter development. I'm currently working on my own desktop Twitter app. However I have apparently missed something on this list. What exactly is wrong with an application (for Mac OS X in this case) asking for a user's Twitter user name and password. Storing the password in the OS X Keychain isn't hard at all and it is encrypted. Have I really missed something important? Does this fever about apps asking for passwords apply to desktop and web apps, or just web apps? I'd really like to know whether or not my application would suddenly become evil because it asked for an account password. And yes, my app does inform the user that the password will be stored in the Keychain and it uses HTTPS when talking to the Twitter servers. Reply on list or off list, which ever works best for you. Dale On Jan 4, 2009, at 11:59 PM, Christopher St John wrote: On Sun, Jan 4, 2009 at 11:39 PM, Jesse Stay jesses...@gmail.com wrote: We're on the verge of a full boycott by users on apps that take passwords. Comments like this on ChrisBrogan.com keep me up at night. There's a groundswell happening, and it doesn't look pretty. I know Twitter is working on something, I just really hope it's soon. Honestly, most people (rightly or wrongly, i suspect rightly) don't really worry about it that much. I don't really think a boycott is likely to be effective. Also, the chrisbrogan.com post confuses phishing with risk of giving an evil service your password. They aren't really the same thing. For example, oauth type systems are generally considered to raise the risk of phishing happening (because they involve jumping the user all over the place to different sites) while at the same time (if implemented well) they can reduce the impact of a successful phish (by giving the user and the service more tools to control usage) They're also substantially more difficult to implement perfectly, raising the risk of code vulnerabilities. Lots of tradeoffs well worth discussing (it's certainly a teaching moment) but the level of run-in-circles-scream-and-shout is getting to the point of being unhelpful. -cks -- Christopher St. John http://artofsystems.blogspot.com -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
Re: This is why it's Urgent
On Mon, Jan 5, 2009 at 12:07 AM, Dale Merrick theunstable...@gmail.com wrote: What exactly is wrong with an application (for Mac OS X in this case) asking for a user's Twitter user name and password. Because your app could be evil[1], and, right now, a Twitter password is a non-expiring full-access read/write token. And somebody could tweet something evil while masquerading as you. Of course, you can always just change your password, but that's inconvenient. And there's a chance you use the same password for Twitter and your bank account. Have I really missed something important? Does this fever about apps asking for passwords apply to desktop and web apps, or just web apps? Logically, it's just as risky to give your password to an evil desktop app as it is to an evil web app (since the desktop app can always transmit the password to a remote server) However, most of the discussion has been about web apps. And yes, my app does inform the user that the password will be stored in the Keychain and it uses HTTPS when talking to the Twitter servers. To be fair, an evil app could just as easily say (and even do) that. -cks [1] In this contect, the word evil must be pronounced ala Time Bandits Mum! Dad! It's EVIL! Don't touch it!. http://www.youtube.com/watch?v=v60-qRvmzKA -- Christopher St. John http://artofsystems.blogspot.com
Re: This is why it's Urgent
Cameron, Alex: Thanks for responding. I just wanted to make sure I hadn't missed some major technical issue. I see that I haven't. I do agree with Alex in regards to the security theater comments he made. It doesn't appear that OAuth will make things any better, even if all Twitter apps are required to support it. Christopher, I agree with your points. As someone else on the list asked, what is the solution to this issue? It doesn't really seem to be a technical issue at all, but rather a trust issue. Unless I have missed something you need the users password to post an update to their personal timeline. If the application doesn't ask for this information then how will their timeline get updated? Perhaps someone has already provided that answer. I'll dig through the archives tomorrow. And with it being a trust issue you can extend that to a multitude of things in terms of computer applications (desktop and web based). Actually the real issue is the reputation of the entity that wrote the application. It all comes down to public relations. For my own self, or rather for my application, I feel pretty comfortable asking users to enter their user name and password combo. Can I prove I won't be doing anything evil with it? Yes, if I release the source code (which is currently under consideration). If I don't though then obviously I can't prove I'm not doing bad things with it. Don't you just love moral dilemmas brought up by technology? :D Thanks to all three of you for providing answers that were free of scare mongering. Dale On Jan 5, 2009, at 12:28 AM, Christopher St John wrote: On Mon, Jan 5, 2009 at 12:07 AM, Dale Merrick theunstable...@gmail.com wrote: What exactly is wrong with an application (for Mac OS X in this case) asking for a user's Twitter user name and password. Because your app could be evil[1], and, right now, a Twitter password is a non-expiring full-access read/write token. And somebody could tweet something evil while masquerading as you. Of course, you can always just change your password, but that's inconvenient. And there's a chance you use the same password for Twitter and your bank account. Have I really missed something important? Does this fever about apps asking for passwords apply to desktop and web apps, or just web apps? Logically, it's just as risky to give your password to an evil desktop app as it is to an evil web app (since the desktop app can always transmit the password to a remote server) However, most of the discussion has been about web apps. And yes, my app does inform the user that the password will be stored in the Keychain and it uses HTTPS when talking to the Twitter servers. To be fair, an evil app could just as easily say (and even do) that. -cks [1] In this contect, the word evil must be pronounced ala Time Bandits Mum! Dad! It's EVIL! Don't touch it!. http://www.youtube.com/watch?v=v60-qRvmzKA -- Christopher St. John http://artofsystems.blogspot.com
Maximum allowed tweets per minute
What is the maximum allowed rate of tweeting. I'm hitting some limit where tweets are simply not being allowed for a user, and I presume this is because the rate of tweeting is too high. Does Twitter have a limit of how often a user is allowed to tweet? Doug
