Re: [twitter-dev] What Is The Status of Twitter OAuth?
On Mon, 30 Nov 2009 10:27:24 -0800 (PST) Dewald Pretorius wrote: > Last information I've seen said that Twitter OAuth is in public beta, > if I remember correctly. > > Has that status changed, as in, has OAuth been moved out of beta and > into production? This doesn't look beta to me: http://oauth.net/core/1.0a A is a revision code, not alpha. Chris signature.asc Description: PGP signature
[twitter-dev] Re: OAuth in popup, does not work when auto close
> I authenticate with twitter oauth using a popup from my site. When the
> authentication is done, twitter redirects the user to my site again.
> The user then has my site both in the original browser window, and in
> the popup.
One way of formulating your problem would be "How can I avoid having two
windows open?" The simplest answer would be, "Don't open a second
window."
> I want to close the popup automatically, so the user don't have to. I
> do this with the following:
> 0) { echo "self.close
> ()"; } ?
>
> The problem is that when using the above code, the authentication
> don't seem to work. When trying to tweet I get this:
> /statuses/update.xml Could not authenticate you.
>
> When I don't use the above code, and thereby force the user to close
> the popup manually if he don't want it open, everything works fine.
>
> Can someone explain this to me, and help with how I can auto close the
> popup without messing with the authentication?
PHP is not my language of choice, but that looks like a scoping issue.
When you close the window with JavaScript, the authentication data you
obtained is lost when the window containing it is closed. You need to
persist the data whatever that means for your application - save a
cookie, submit data or (Ugh!) set a global - before you close the
window
Chris Babcock
[twitter-dev] Re: OAuth without user interaction
On Fri, 23 Oct 2009 16:32:25 -0400 ryan alford wrote: > It is possible to do OAuth without user interaction if you have their > username and password, but this is frowned upon by Twitter and could > get your IP blacklisted. You do need user interaction to get initial approval for a token, after which you can reuse a token until it is revoked. There is a chance (Has this happened recently?) that a token may expire without obvious reason, but they are supposed to be reusable. There's no replacement for testing, which has been absent in my shop recently because of the churn on the API... which I'm hoping will be addressed by versioning. Chris Babcock
[twitter-dev] Re: url fail
> Using IE seems like a personal problem, and something you'll have to > conquer on your own ;) Yes, but sending a screenshot to a development mailing list to report a broken link on a website is so wrong on so many levels... Using IE is a bit like smoking marijauna after work or having an expensive fetish - as long you don't drive while you're doing it or involve vulnerable members of society then there's no harm in it. On the other hand, can you imagine what life would be like if every user sent a screen shot of the fail whale to a random Twitter contact every time *that* happened with a comment like "Someone might want to look into this"? With the OP's reputation as a spamware vender and FUDmonger, I think we may have to face the fact that he has finally unleashed his master plan to bring down the Internet. We may be looking at the equivalent of the 'Dr. Doofenshmirtz Roller Skating in His Underwear Until He Falls Head First into a Toilet' video. If this practice goes viral, it could make the original Twitapocalypse seem like a spring day. Chris Babcock
[twitter-dev] Re: [OOT] Hijacking twitter account, is it possible?
On Thu, 15 Oct 2009 12:32:19 +0700 Dwi Sasongko Supriyadi wrote: > Okay. If Mallory changed Bob's password after successfully get in, > Can Bob still access his account through his application (which is > authorized)? Yes, OAuth apps that have their own authentication context would still work for Bob. A change in Bob's Twitter password will not prevent the OAuth application from working. As long as Bob can prove that he is Bob to the application's satisfication then he can use that application and that application can use OAuth tokens that Bob previously authorized. > From your explanation above, the answer is no, it is > impossible. Since Bob cannot sign in anymore, Mallory has changed his > password. The application may or may not relay on Twitter itself to authenticate the Twitter user after it has obtained a token. While Twitter is kind enough to give us the "Sign-in with Twitter" work flow, OAuth does not specify the means by which the application should authenticate the user. Account hi-jacking is a minor risk; It is auditable and reversible. OAuth is low risk because it is being offered in parallel with HTTP methods that have known vulnerabilities. Twitter accounts are low risk targets because the content is public, transient and repudiatable. A threat model that over-emphasizes those risks reveals fundamental misperceptions about the Twitter meme that is going to result in disappointment when those misperceptions attempt to manifest themselves as a business model. Chris Babcock
[twitter-dev] Re: [OOT] Hijacking twitter account, is it possible?
The situation in this scenario is that Mallory phished Bob's Twitter credentials and used them to authorize access for himself with an OAuth App that Bob also uses. Mallory can only be detected by the changes he makes in the account; He cannot be detected by viewing the list of OAuth apps with access to the account. Additionally, Mallory's access does not disturb Bob's access to the account via the OAuth consumer App. This scenario is largely equivalent to Mallory's posession of the credentials themselves. The only difference is that Mallory retains certain capabilities even if the credentials he obtained are changed. The real security profile for this scenario is that it adds an extra layer of maintenance to be done by a user if a compromise is suspected. In addition to changing passwords, Bob should cancel all other accesses to his account and reauthorize those that are trusted and necessary. Chris Babcock On Wed, 14 Oct 2009 20:17:48 +0530 srikanth reddy wrote: > Yes. The risk is high with Desktop apps as Consumer secret/keys are > distributed. > > On Wed, Oct 14, 2009 at 8:04 PM, Dewald Pretorius > wrote: > > > > > So this is a problem with web apps as well then. > > > > If User Bob authorized Web App to work on his account, and Phishing > > Dude also authorizes his Web App account to work on User Bob's > > Twitter account because he phished User Bob's Twitter username and > > password, User Bob is blissfully unaware of that? > >
[twitter-dev] Re: [OOT] Hijacking twitter account, is it possible?
On Tue, 13 Oct 2009 23:48:13 -0700 (PDT) ruckuus wrote: > Is there anyone have an experience to hijack a twitter account? The security profile of a Twitter account is no different than that of many other on-line services. The major weaknesses are signing in over HTTP, accepting insecure cookies for account modifications and password 'reminders' (actually replacements) by email. > well, the story is really weird. There is a celebrity's account > hijacked (password stolen, etc), and then he created a new account, > the told the world that he could do something in his old account, e.g. > sending a new tweet as usual. > > This case is the same with: Bob can tweet in Alice's timeline. Can Bob > do that? This is almost being very stupid question, and the answer is: > IMPOSSIBLE, or possible with an 'if' ...? There are a couple scenarios. The thing that gets overlooked in these discussions is how these situations benefit the attacker. It's not a technical challenge, so there's no Cracker Glory in it. There's no money involved. Twitter could always return control of a hijacked account manually. It's a risk without reward. Most anyone suitably incentivized to run exploits would be better served by attacking the service as a whole anonymously than attacking one account. > To make long story short, I am developing a twitter client in C, and I > am implementing oauth with liboauth and I feel I do not deeply > understood of oauth in the case above (hijack vulnerability). If you use OAuth with a desktop client, you are distributing your secret key with the application. Users should not assume that an authorization request for your app is from their copy of the app unless they initiated the transaction. Chris Babcock
[twitter-dev] Re: Randomly Sampling Users: Suggestions?
> I am doing some research using the Twitter API and I would like to get > a random sample of Twitter users. Any ideas of how this can be > accomplished? Here's a start: http://en.wikipedia.org/wiki/Sampling_(statistics) At this point you are asking for a sampling method without providing an adequate definition of the population. > So far, I have scraped 2 weeks from the Streaming API and extracted 3 > million user IDs from the stream. Any arguments as to whether or not > this could constitute random? That sample will be biased towards more active posters and may include some demographic biases due to seasonal activities during the limited time frame of the sample. Chris Babcock
[twitter-dev] Re: About the oneforty application directory
On Mon, 28 Sep 2009 16:49:29 -0700 (PDT) Dewald Pretorius wrote: > Then I don't understand. Why would OneForty elect to pay the > developer's 70% in the form of a gift or donation to the developer? All hypothetical, no malice imputed... - What if program costs run away and there isn't enough $$$ to cover the obligations? How much can developers legally recover? 30%. - Above a certain $$$ threshold, the accounting requirements change. Reporting 70% of the distribution as a gift effective triples the total payments that can be made to a developer before tax status changes. - Some development *is* done by non-profit organizations or could possibly be donated to a non-profit. If the structure of the developer agreement was conduscive to it, as this is, then non-profit work and code donations to non-profit orgs would be encouraged and there could be tax benefits. Chris Babcock
[twitter-dev] Re: Implementing update via JS
On Mon, 7 Sep 2009 02:06:33 -0700 (PDT) Srinivas wrote: > > Hi, >I have to implement updating Twitter status through JS. > Need pointers on how to get started http://apiwiki.twitter.com/Libraries#JavaScript
[twitter-dev] Re: Is twitter a fad or worth development efforts?
entirely different than using broadcast media. It's viable and monetizable, but it is not easy to scale. The challenge will be to see if Twitter can become a financial success without become a soulless waste of electrons like MySpace. > Apple has shown us this model at scale. Models from hardware vendors may not apply. The only commodity that Twitter can gateway here is access to the Tweet stream. > A rich developer community, incentivized by a Twitter regulated "app > store," and a firm developer bill of rights will ensure Twitter stays > relevant (and its users enjoy a rich experience) for a lot longer than > it should. It also gets to 'grow up' into a real company and earn > revenue from a reseller split (again, via Apple). I'm not developing for Yahoo because their terms say that I'm not supposed to compete with their services. That means if I run a game and it is successful then they can copy it and I'm out of business. There's no viable revenue model for those terms of service. A developers' rights doc would be a huge plus. The 'app store' metaphor and central regulation do not necessarily follow, except as part of following the hardware vendor's pattern. Twitter itself is a great vehicle for consensus building and Twitter apps could easily be self regulating. One of the problems of all this speculation, however, is that it doesn't really change anything. Twitter's fortunes will rise or fall on their own strategy and implementation. Whether we participate in that success of failure depends on our respective capacities for risk. In Hollywood (where I've never lived), they have an expression, "If you have to ask, you can't afford it." Chris Babcock
[twitter-dev] Re: Find twitter account from email address?
> Ok, the long answer is "no" too. Here is the long answer: http://www.youtube.com/watch?v=3zNjQecyjE8 Chris Babcock
[twitter-dev] Re: Using Twitter API by Nick Beam
> > Andrew Badera wrote: > > > TEXT AVALANCHE! RUN! > > > On Sep 1, 1:22 am, Chris Babcock wrote: > > Paste Bin - pastebin.com - is our friend. On Mon, 31 Aug 2009 18:49:26 -0700 (PDT) Pj wrote: > Are there any Documentation to refer to? If you are going to send more than one or two lines of sample code then using pastebin or a similar site instead of sending the code by email can help avoid the problem of leaving a brainy mess on the keyboard for our spouses to clean up. I think that a link to pastebin.com is a slightly more constructive, though significantly less cathartic, approach than shouting "TEXT AVALANCHE! RUN!" As for your question... In a Tweet, "docs twitter api php lib - Google Search http://bit.ly/Ww09j " which brings us back to our punchline, "Google is your friend." Chris Babcock
[twitter-dev] Re: Using Twitter API by Nick Beam
Paste Bin - pastebin.com - is our friend.
Chris
On Mon, 31 Aug 2009 16:17:55 -0400
Andrew Badera wrote:
> TEXT AVALANCHE! RUN!
>
> ∞ Andy Badera
> ∞ This email is: [ ] bloggable [x] ask first [ ] private
> ∞ Google me:
> http://www.google.com/search?q=(andrew+badera)+OR+(andy+badera)
>
>
>
> On Mon, Aug 31, 2009 at 3:27 PM, Pj wrote:
> >
> > Can anyone please assist me on how to use/call this API functions
> > with php?
> >
> > I tried
> > >
> > require("new.class.php");
> >
> > $twitter = new Twitter("", "");
> >
> > $msg = $twitter->getMessages("xml");
> >
> > echo "". $msg. "";
> >
> > ?>
> >
> > And something weird displayed..
> > thanks in advance.
> >
> > //new.class.php\\
> > > /**
> > * Twitter interface class
> > * Nov 26 2007 Nick Beam
> > * Bugs, comments, questions: winkerb...@gmail.com
> > * http://rbrw.net -- http://tinydinosaur.com
> > *
> > * This is a simple interface to the Twitter API.
> > * I've tried to keep as close as possible to the real API
> > * calls (some had to be changed due to ambiguity), but all
> > * of the arguments are as they are in the official docs.
> > *
> > * Usage:
> > * $twitter = new Twitter("username", "password");
> > * $public_timeline_xml = $twitter->getPublicTimeline("xml");
> > *
> > * Methods:
> > * getPublicTimeline($format [, $since_id])
> > * getFriendsTimeline($format [, $id [, $since ]])
> > * getUserTimeline($format [, $id [, $count [, $since ]]])
> > * showStatus($format, $id)
> > * updateStatus($status)
> > * destroyStatus($format, $id)
> > * getReplies($format [, $page ])
> > * getFriends($format [, $id ])
> > * getFollowers($format [, $lite ])
> > * getFeatured($format)
> > * showUser($format [, $id [, $email ]])
> > * getMessages($format [, $since [, $since_id [, $page ]]])
> > * getSentMessages($format [, $since [, $since_id [, $page ]]])
> > * newMessage($format, $user, $text)
> > * destroyMessage($format, $id)
> > * createFriendship($format, $id)
> > * destroyFriendship($format, $id)
> > * verifyCredentials([$format])
> > * endSession()
> > * getArchive($format [, $page ])
> > * getFavorites($format [, $id [, $page ]])
> > * createFavorite($format, $id)
> > * destroyFavorite($format, $id)
> > * lastStatusCode()
> > * lastAPICall()
> > */
> >
> > class Twitter {
> > /* Username:password format string */
> > private $credentials;
> >
> > /* Contains the last HTTP status code returned */
> > private $http_status;
> >
> > /* Contains the last API call */
> > private $last_api_call;
> >
> > /* Twitter class constructor */
> > function Twitter($username, $password) {
> > $this->credentials = sprintf("%s:%s", $username,
> > $password); }
> >
> > function getPublicTimeline($format, $since_id = 0) {
> > $api_call =
> > sprintf("http://twitter.com/statuses/public_timeline. %s", $format);
> > if ($since_id > 0) {
> > $api_call .= sprintf("?since_id=%d",
> > $since_id); }
> > return $this->APICall($api_call);
> > }
> >
> > function getFriendsTimeline($format, $id = NULL, $since =
> > NULL) { if ($id != NULL) {
> > $api_call =
> > sprintf("http://twitter.com/statuses/friends_timeline/ %s.%s", $id,
> > $format); }
> > else {
> > $api_call =
> > sprintf("http://twitter.com/statuses/friends_timeline. %s",
> > $format); }
> > if ($since != NULL) {
> > $api_call .= sprintf("?since=%s",
> > urlencode($since)); }
> > return $this->APICall($api_call, true);
> > }
> >
> > function getUserTimeline($format, $id = NULL, $count = 20,
> > $since = NULL) {
> > if ($id != NULL) {
> > $api_call =
> > sprintf("http://twitter.com/statuses/user_timeline/%s. %s", $id,
> > $format); }
> > else {
> > $api_call =
> > sprintf("http://twitter.com/statuses/user_timeline.%s";, $format);
> > }
> > if ($count != 20) {
> > $api_call .= sprintf("?count=%d", $count);
> > }
> > if ($since != NULL) {
> > $api_call .= sprintf("%ssince=%s",
> > (strpos($api_call, "?count=") === false) ? "?" : "&",
> > urlencode($since)); }
> > return $this->APICall($api_call, true);
> > }
> >
> > function showStatus($format, $id) {
> > $api_call =
> > sprintf("http://twitter.com/statuses/show/%d.%s";, $id, $format);
> > return $this->APICall($api_call);
> > }
> >
> > function updateStatus($status) {
> > $status =
> > urlencode(stripslashes(urldecode($status))); $api_call =
> > sprintf("http://twitter.com/statuses/update.xml?stat
[twitter-dev] Re: Installing Modules
On Sat, 29 Aug 2009 23:08:28 -0700 (PDT) Kidd wrote: > > I'm new to python and just want to install the twitter module, but no > one on here explains how, probably because this is a common function > for veterans. > > How do I install this or any module? I've downloaded the tar file to > my downloads folder on my mac. This is your new best friend: http://docs.python.org/install/index.html This is the best place to ask really basic Python questions: http://www.python.org/community/lists/#tutor Best, Chris Babcock
[twitter-dev] Re: OAuth API for Third Party Services
On Mon, 24 Aug 2009 11:14:12 -0700 (PDT) Greg wrote: > When I first started programming Twitter application using OAuth - I > thought that eventually it would open up to allow Third Party API > (TwitPic, TweetPhoto) to start using OAuth tokens to authenticate. > However - its been a while since this has gain any air. Twitter got burned with early adoption and the sesion-fixation vulnerability. Not that their service gat hacked through it, but because they didn't point the finger of blame when they pulled the API. There might be quite a bit of wait and see going on because of that, because of the way SSO has faltered, and because of the general FUD that always surrounds security issues. > Is this something that would should be seeing from third-party > services in the future? Thinking about it - your tokens authenticate > you only for that specific application with the consumer key and > consumer secret - how could it be possible to authenticate you on > another service? By design, the user has to authorize each combination of Consumer and Service Provider separately. Trust me, you wouldn't want the kind of interoperability that you seem to be asking for here. It would either open up tons of man in the middle vulnerabilities or be horridly complicated to implement, which has its own risks. > If not - what's the point of OAuth? You can't integrate with other > Twitter Services without having the user sign in again. OAuth will be gaining traction as part of OpenSocial. There could very well be sites that are waiting for this or waiting for better support infrastructure. I have a game site that I'm looking to let users promote by pushing information about forming games out to as many social media outlets as I can support. Facebook is low on my list because it already has an implementation of the game I offer and, even though the implementation isn't very good, the Facebook API is too involved for me to make a run at share shifting them until I've built more share elsewhere. High on my list are sites that are using Open Social, like Avatars United, or where I only need one or two features of the API, like MeetUps. Twitter is on my list because the API is just simple and well-used enough that it would be worthwhile to write and maintain a library on my own. Seriously, though, if we're busting out of our skulls thinking how this affects us as Consumers, think about how it has to be affecting the service providers with 100's of thousands or 44.5 millions of users. Chris
[twitter-dev] Re: oAuth doubt : do we need get access permission from user every time
On Mon, 24 Aug 2009 22:06:21 +0530 srikanth reddy wrote: > > Sign in with Twitter isn't conceptually compatible with the design > > of OAuth authentication, but it makes an attempt to deliver on what > > the consumer expects from it. > > > i am not sure i get this But from Desktop app point of view it > perfectly makes sense. You do not ask the user to login again rather > you use the stored tokens . For a desktop, the consumer app lives on the same machine that the end user is using. In that case, the only reasons to use OAuth instead of Basic would be that an HTTPS connection cannot be reliably established or the server application has stated that it intends not to support Basic after some time. That's not the target use case for Oauth Authentication, which was designed so that end users could delegate a third party to authenticate as the end user and act on his behalf. Authentication there means allowing the app to authenticate as the user, which makes it a needless complication for a desktop application, and counter intuitive for a Consumer who is expecting "Authenticate the End User to me" instead of "Authenticate me to the Service Provider as the End User." That is why there have been such hacks to get it to work with iPhone and why there are still "open issues." There is acknowledgement in the spec that Service Providers should not trust the Consumer Secret, but good luck educating end users not to approve a token unless they initiate the request. Paradoxically, probably because of the length of the distribution cycle, desktop apps seem to have been among the first to implement OAuth. Chris
[twitter-dev] Re: oAuth doubt : do we need get access permission from user every time
On Mon, 24 Aug 2009 09:53:33 -0700 (PDT) Dewald Pretorius wrote: > That gives me absolute nightmares, when I need to do API calls on user > accounts when the user is not logged in to my site. > > I need the OAuth tokens, which will stored in my database, to remain > valid until the user revokes the access of my app. Meaning, once a > user authorizes my app and until he removes that authorization, there > must be no reason whatsoever for the user to again be physically > involved in any authorization process. > > This is not unique to my app. > > This is required by any app that does batch API calls on Twitter > accounts. Welcome to the wild world of HTTP. HTTP 1.1 defines 38 response codes, only one of which you would accept graciously from a contractor working on your bathroom if you urgently had to go pee. Think, "Two weeks." I'm not being blasé. There are only three things you can count on in an Internet environment - uncertainty, desktop application programmers' having nightmares and system programmers realizing belatedly that they might possibly have been more sensitive - well, two things you can count on. Twitter plainly intends for specific tokens to persist (and they may even do so already), but even so apps need to plan to fail any time a request goes out over the wire. That's a reality of the programming environment that isn't specific to OAuth and Twitter. Chris Babcock
[twitter-dev] Re: oAuth doubt : do we need get access permission from user every time
On Mon, 24 Aug 2009 20:43:57 +0530 srikanth reddy wrote: > just to add you can obtain the user id , screen name along with access > token/secret . You need to cache this. I stopped development on my own API library and decided to use Python for my app when Twython was introduced, so I haven't had a chance to send an OAuth request and examine the returns, which aren't documented. Do you mean to say that the OAuth call returns the user record? That makes sense, but it doesn't explain the pathological obsession with working the verify credentials call into the work flow that I've seen. Chris Babcock
[twitter-dev] Re: oAuth doubt : do we need get access permission from user every time
On Mon, 24 Aug 2009 03:04:52 -0700 (PDT) abhishek sanoujam wrote: > You don't need to get permission everytime from the user if you are > going to store it in a DB. The problem with this is that you will have > to implement another level of authorization in your site/app, kind of > a password for your app, so that when the session times out, or a user > comes back again, he can authorize with your site's password and thus > you can use the initial access token granted behind the scenes. Right, you need your own session management. That can be anything from HTTP Auth to cookies to your own User Database and the authentication routines native to your scripting language or framework. > This way of doing things is against the "Sign in with Twitter" > philosophy, but then I also don't see a way of re-using the access > token if you are going with "Sign in with Twitter" philosophy. You are > going to ask the user everytime (which means a If you use a cookie, > or HTTP Basic Auth with anonymous users.new access token), Sign in with Twitter isn't conceptually compatible with the design of OAuth authentication, but it makes an attempt to deliver on what the consumer expects from it. OAuth authentication allows the Consumer App to use the Service Provider in the place of the user without knowledge of the user name or password. It serves those authentication needs, but as you see it doesn't meet some of the other expectations. That some of these expectations are faulty, isn't of concern to our users, nor should we necessarily expect the service provider to bear the full brunt of building the bridge between the spec and the expectation. Otherwise, what are you getting paid for? :-) > and after getting a new access token, you are going to do > verifyCredentials (to find out who logged in actually)... Everyone assumes that this is something they need to know and that the verify credentials is the only way to find that out. Both assumptions are false, at least as far as the functionality provided by the Twitter API. You don't need to know the user name to use OAuth. Access to API methods using OAuth is as agnostic of usernames as it is passwords. If you do need to know the user name then verify credentials is the easiest and most obvious, but not the best, way to get it. > and verify- > credentials is limited to only 15 requests per 1 hour. This seems like > using "Sign in with Twitter" and not reusing access token, you can > login only 15 times in an hour? I hope this is not correct... but thts > what I understand from > http://apiwiki.twitter.com/Twitter-REST-API-Method:-account%C2%A0verify_credentials... > If my assumptions are correct, 15 wrong verify-credentials requests > from your site will halt your site for at least 1 hour .. and another > 15 wrong requests for another 1 hour... which seems too easy for your > competitors to block your app!! I'd rather add another authorization > level in my app than face this... No, you get 15 verify credentials requests per user regardless of correctness or source. Since OAuth does not know the user, you may get unlimited rejections but only 15 confirmations - shared with all other apps regardless of their authentication method. That is why you can't rely on it. Instead, use http://twitter.com/statuses/user_timeline.xml?count=1 if obtaining the user name is critical. If you are using Twitter accounts to authenticate users on your site for non-Twitter services then remember that screen names can change. Use the user_id instead. Chris Babcock
[twitter-dev] Re: oAuth doubt : do we need get access permission from user every time
On Mon, 24 Aug 2009 05:21:05 -0700 (PDT) "J. Dale" wrote: > I've read the http://apiwiki.twitter.com/Sign-in-with-Twitter FAQ and > they say that access tokens don't expire. However, it appears that > they do. Has anyone else noticed that storing access tokens in the > database doesn't really work? Even if access tokens do not expire, there are other reasons why they may fail to persist. Your algorithm for using a token should include a recovery method in the event that authentication fails. Given the work flow for Sign-in-with-Twitter, that should be a matter of storing the request in a way that the landing page for your app can recover it and direct the user there after re-authenticating. If the user is logged into Twitter and hasn't revoked your App then they won't see anything while the redirection is occuring. Chris Babcock
[twitter-dev] Re: oAuth doubt : do we need get access permission from user every time
> I understand that we can store the access token in DB. > but how do i know the logged in user's screen name after session > timeout? Nowhere in the entire OAuth workflow do you handle users' passwords or their usernames. A benefit is that you do not need the Twitter username to perform any function on the users' behalf with the Twitter API any more than you need the password. If it happens that you need the username for some other business reason then you can call a GET method that returns user profile information to obtain the user name. The account/verify_credentials methods is most common for this purpose, but reliance on this method can make your app subject to DoS because the call has a low, per-user rate limit to protect against brute force password hacking. You can obtain the user id from statuses/user_timeline as well. Send count=1 if you do not need the statuses themselves. Better yet, design your app to not require that you know the username, if possible. Chris Babcock
[twitter-dev] Re: API Version of /friend_requests?
> Is there an API version of http://twitter.com/friend_requests ? I want > to be able to pre-authorize people to follow me so that I don't have > to manually check my email and visit that page every once in a while. Not necessary. Users can follow you without authorization. Chris Babcock
[twitter-dev] Re: oAuth consumer keys, tokens...how sensitive are those keys?
> On Aug 19, 10:26 am, Andriy Ivanov wrote: > > I've written Desktop app that usesoAuthto communicate with twitter. > > All the keys/tokens/pin I save in Settings file in my project > > (.NET). Is it safe to do so or what is the better approach to save > > this kind of data? What if all the tokens get in hand of "evil", > > they can impersonate the user using the tokens, right? Why won't > > tokens expire with Twitter? I am knew to internet protocols, so any > > help would be appreciated. Thanks! > > There was some discussion of this at > http://groups.google.com/group/twitter-development-talk/browse_thread/thread/972b23136fdf9ed8/80d6e999d9dedced?hl=en > > An attacker who knows your consumer key and consumer secret can create > an application that imitates yours. But they can't impersonate a user > unless they have that user's access token and token secret. Right, that takes a social engineering exploit to complete. After obtaining the consumer's keys, the malicious user needs to employ it to impersonate your application so that he can trick your legitimate user into authorizing a new token to replace the existing one. OAuth is written with the implicit understanding that the consumer application lives on a server. In the absence of some scheme for bulk key assignments, distributing your key and secret with the application is the only alternative to running all traffic for your app through your own server. Chris
[twitter-dev] Re: Can I DM via the API with username and password?
On Fri, 21 Aug 2009 06:43:21 -0700 (PDT) mchid wrote: > I need my app to be able to send a direct message to a registered > users - so I know their username and the password they use to log in. > Do I need them to manually authorise this first (using oAuth) or can I > avoid this? I think I understand you. You only need to verify that your user is the account holder for a given Twitter account. You do not need to perform any actions with their account. You want to implement a feature similar to email verification where the user clicks on a link or replies to a message in order to prove that they own that account - in this case the Twitter account rather than an email account. The only problem with this for Twitter is that the user has to be following you in order to get your direct message. The situation is analogous to an email user who's mail acount requires that you be whitelisted first. > For reference (and for my sins) the app is developed in > c#.net :) Say 10 "Hail, Bills" and give $400 to the wealthy. Chris Babcock
[twitter-dev] Re: how can I get user address using Twitter API?
On Sat, 22 Aug 2009 10:01:08 -0400 Dossy Shiobara wrote: > Easy revenue model: sell lookups from email -> twitter ID and twitter > ID -> email. That's a fair response to an earlier thread about looking up the Twitter ID by email address. The message to which you were responding had to do with verify credentials. It's was a fair question as the implications are for more subtle. Here's the real threat model... Provide a service that uses your OAuth key and logs the response to "verify credentials" calls. You obtain valid email addresses and names that people actually use to self-identify. If you use, misuse, abuse or resell these to third parties, it is traced back to Twitter - not you - and you have a very high quality list of names and email addresses that can help your spam mailing score well on some features of some content filters - including the human eye. What makes it work is that, as far as the user knows, your service never asked for an email address. Chris Babcock
[twitter-dev] Re: how can I get user address using Twitter API?
> > > I am trying to integrate Twitter OAuth with my website. Right now > > > I can use this API > > > (https://twitter.com/account/verify_credentials.xml) to get lots > > > of profile information like user ID, screen name, but I didn't > > > any info about the user email address. Is there any API to get > > > email address? Thanks in advance. > > > > Is there any reason twitter doesn't support it? it is so weird. Levity aside, even if the user grants you rights to do everything else possible with his or her Twitter account, that does not absolve Twitter of the right and the responsibility to maintain the privacy of the email address used on the account. There is also the next logical stop after getting an address via the API, which is changing it via the API. Why not allow that too? Well, maybe because it would make using OAuth as insecure as using basic with 3rd party services. Being able to change the email address on an account that offers password recovery services is the same as being able to change the password and lock out the original user. Identifying the email account used to register for a service is not only a Spam concern, but it is also a step towards being able to hi-jack the account. Instead of needing to crack one password to access the account, a hacker can choose one of two. Also, most email users don't control their own mail infrastructure, so passwords shared across acounts and the lack of implementation of secure protocols for services means that doubling the number of services exposed to attack more than doubles the chances of an attack being successful. I'm not saying that Twitter is a secure service, but that publishing the email address given by the user for the service - even to those who provide some credentials or level of trust for the account - presents an additional level of trust that cannot be safely implied from the initial delegation. Chris Babcock
[twitter-dev] Re: how can I get user address using Twitter API?
> > > I am trying to integrate Twitter OAuth with my website. Right now > > > I can use this API > > > (https://twitter.com/account/verify_credentials.xml) to get lots > > > of profile information like user ID, screen name, but I didn't > > > any info about the user email address. Is there any API to get > > > email address? Thanks in advance. > > Is there any reason twitter doesn't support it? it is so weird. App User: Morning, Mail Server: Morning. App User: What have you got? Mail Server: Well, there's egg and bacon, egg sausage and bacon Egg and spam Egg, bacon and spam Egg, bacon, sausage and spam Spam, bacon, sausage and spam Spam, egg, spam, spam, bacon and spam Spam, sausage, spam, spam, spam, bacon, spam tomato and spam Spam, spam, spam, egg and spam Spam, spam, spam, spam, spam, spam, baked beans, spam, spam, spam and spam. (Developers: Spam! Spam! Spam! Spam! Lovely Spam! Lovely Spam!) Or Lobster Thermidor aux crevettes with a mornay sauce served in a provencale manner with shallots and aubergines garnished with truffle pate, brandy and a fried egg on top and spam. Email User: Have you got anything without spam? Mail Server: Well, the spam, eggs, sausage and spam That's not got much spam in it Email User: I don't want any spam! App User: Why can't she have eggs, bacon, spam and sausage? Email User: That's got spam in it! App User: Hasn't got much spam in it as spam, eggs, sausage and spam has it? (Developers: Spam! Spam! Spam!...) Email User: Could you do me eggs, bacon, spam and sausage without the spam, then? Mail Server: Iiiich!! Email User: What do you mean 'Iich'? I don't like spam! (Developers: Lovely spam! Wonderful spam!) Mail Server (to Developers): Shut up! (Developers: Lovely spam! Wonderful spam!) Mail Server: Shut Up! Bloody Developers! You can't have egg, bacon, spam and sausage without the spam. Email User: I don't like spam! App User: Shush dear, don't have a fuss. I'll have your spam. I love it, I'm having spam, spam, spam, spam, spam, spam, spam, baked beans, spam, spam, spam, and spam! (Developers: Spam! Spam! Spam! Spam! Lovely spam! Wonderful spam!) Mail Server: Shut Up!! Baked beans are off. App User: Well, could I have her spam instead of the baked beans then? Mail Server: You mean spam, spam, spam, spam, spam, spam, spam, spam, spam, spam, spam, spam and spam? Developers (intervening): Spam! Spam! Spam! Spam! Lovely spam! Wonderful spam! Spam spa-a-a-a-a-am spam spa-a-a-a-a-am spam. Lovely spam! Lovely spam! Lovely spam! Lovely spam! Spam spam spam spam! Chris Babcock
[twitter-dev] Re: Creating Groups
On Thu, 20 Aug 2009 07:20:28 -0700 (PDT) Ryan Bell wrote: > > Twitter Groups: I am adding the ability to create custom 'groups' of > twitter users to my site. My current approach seems very processor/ > twitter api intensive. Can anyone make a recommendation or refer me > to a link where I can find information on how I might more efficiently > code this feature? > > Any help is appreciated. > > Current Approach: > 1. User can put n users in a group > 2. User clicks their group to view the timeline > 3. Iterate through all 'n' users in the group and get the respective > user's timelines > 4. Merge the timelines into a collection. > 5. Sort the timelines by date > 6. Bind this collection to the display grid. > 7. This timeline is immediately out of date of course so a click of > the 'refresh' button triggers the need to do the entire process again. You need a local data store - at least as a cache even if you don't provide permanent storage. You can take a queue from the Twitter API and cache compiled results so that the user isn't causing your site to poll Twitter more frequently than Twitter is willing to give you fresh results. Don't poll each group member's statuses individually. Poll the user's friends/home timeline in aggregate, remove non-members, then merge in those who are member's of the group that your user is not following. Use the "since_id" parameter to only fetch new statuses. Choose a sort algorithm optimized for a merge of previously sorted data streams. Don't fetch all your streams then sort. Merge your most recent fetch operation while you are executing the next fetch. Find a good book on data access patterns. Best, Chris Babcock
Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)
On Tue, 18 Aug 2009 02:52:24 +0530 srikanth reddy wrote: > << > It's worse than that. You don't even have to intercept the key, just > use the application itself to obtain tokens for other users' accounts. > How are they going to tell the difference between their copy of TweetX > and someone elses' in their auth dialogs?>> > > Sorry. I didn't get this. How are you going to obtain tokens for > *other * users? It's a social engineering attack. If the app contains code to authorize new accounts and all the copies of the app use the same secret key then Twitter will not be able to tell the difference between a legitimate token request and a spoofed request. Send out enough requests and eventually a user will approve your token giving you complete access to their account. Chris Babcock
Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)
On Mon, 17 Aug 2009 23:32:58 +0530 srikanth reddy wrote: > @chris > You cannot ask every user to get new consumer token/secret. > There is no way you can protect a consumer secret. I did have a blind spot operating here. When someone says, "Open Source," I'm usually thinking server software not Joe's ShareWare. Since we were talking about source code distribution, I wasn't even thinking about user binaries. > @Joseph > < server somewhere? that could be trivially intercepted.>> > As far as i know this is the best way to hide the consumer secret. > This will not stop a determined user who try to intercept the keys > but you have the option of changing your key/secret values( for a > consumer) periodically. Other options are obfuscating/encrypting > secrets at client side (again it will not stop a determined user). > But the key management is difficult here as you have to download the > app everytime(or whenever the risk of keys being compromised is high) It's worse than that. You don't even have to intercept the key, just use the application itself to obtain tokens for other users' accounts. How are they going to tell the difference between their copy of TweetX and someone elses' in their auth dialogs? Chris Babcock
Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)
Silly me. I thought someone was talking about distributing source code. Building an enduser distribution is somewhat to entirely different. First, there really isn't any point to using OAuth for a client unless the client code lives on the network. The whole advantage of the scheme is that the user does not have to disclose credentials to one or more third parties. An application that doesn't access a third party network should use basic authentication over HTTPS. If Twitter decides to eliminate basic auth then the correct way (from a security stand point) to implement OAuth would be to obtain a separate key for each client. I don't see the current OAuth spec as being set up to handle bulk key assignments, but you can't distribute a single key to multiple clients outside of your network. Whether or not the app is Open Source is a non-issue; It's complete FUD-rucking to imply that it is any diffent distributing a secret key in a close source app than it would be to do so in an open source app. What happens if you try to use a screwdriver as a hammer? It's the same thing here only someone had to drag Open Source into as if that made any kind of a difference. To top it off, the OP had a complete misunderstanding of the consequences of key disclosure. "A Spammer could use it and get your app banned..." as if that's of any consequence compared to the users' accounts getting hijacked by apps impersonating your client. And what's with keeping score as if Open Auth and basic were a couple of talking tools on Disney Channel having some sort of ludicrous rivalry? Chris Babcock > This is interesting Chris, as I have had the same question. How would > you propose to distribute a usable FLOSS twitter app that uses Oauth > to authenticate itself but doesn't include the app's consumer key and > consumer secret? fetch the key and secret at runtime from a secure > server somewhere? that could be trivially intercepted. > > Joseph Cheek > @cheekdotcom > > Chris Babcock wrote: > > On Sun, 16 Aug 2009 18:49:49 -0400 > > Jason Martin wrote: > > > > > >> On another note, how "Open Source friendly" is OAuth? I'm not sure > >> if people who write open source software want to be giving out > >> their Consumer Secret key in their source code > >> > > > > Reasoning from a faulty premise. > > > > When you know your code is going to be seen you either avoid doing > > stupid things like hard coding credentials or you learn fast that > > configuration data is not code. > > > > (Now where I did leave my virtual haddock?) > > > > Chris Babcock
[twitter-dev] Re: My Issue with the ReTweet API and my solutions
Favorites are like secret ballots. That has its place in society, but it doesn't serve the same needs as standing behind some alpha primate and banging your chest in time to stand behind his message. Favorites mark things for personal consumption. They are contemplative and reflective. It's done for self, so the secondary purpose as a popularity meter is in dissonance with the perceived primary purpose. Using favorites statistically *feels* like an invasion of privacy. The new Retweet is expressive and *feels* like something that should be measured for public consumption. The use is fully in line with consensus building behaviors. Right now "me too" posts are universally lame across all social media as well as an unfortunate reality of human nature. They make some sense for Twitter because of the characteristics of the medium, but there are still some issues with that. The Twitter community deals with this by making retweets value added within the limits of the medium, whereas this functionality deals with the root causes of why the "me too" impulse is contrary to accepted standards of on-line behavior. The data structure is simple, so it will save storage. It exposes a common key value for all retweets of a message, so output *can* be filtered to save network and social bandwidth. It will be simple to execute and the user interface will be interpreted as implicit or explicit approval as needed by the users. It will also be measurable, so the "me too" response is restored to its proper role in democratic/primate behavior as a useful tool for consent building and group behaviors. Don't mistake me for an advocate; I'm dreading how this is going to play out in media where it is less suited. No, what you are seeing here is 100% grudging admiration. The savannah and "Down and Out in the Magic Kingdom" are one step closer together for all of this. Probably it did start out as an optimization, but this thing is going to be hot whether we like it or not. Chris On Mon, 17 Aug 2009 12:36:41 +0100 Paul Kinlan wrote: > Chris, > For sure the, that is what I see happening with the Retweet API, the > fact that there is no status text on > http://twitter.com/statuses/retweet/id.format indicates just that - > which is why I would like to see favourites API drastically enhanced > in tandem. > > Currently this Retweet API serves only as forwarding mechanism, which > is not how a lot of people use it. A lot of people either add > comments, to a retweet or like to have their face on the retweet (I > am retweeting this etc) so from a UX POV their is now a distinct > break in the twitter site, and the RT usage is now forced upon the > users (in my opinion curtailing the evolution of this emergent > behaviour) unless they simply type RT into a reply and add comment - > so now we have two forms of retweet neither quite right. > > Currently this Retweet API seems like a favoriting system, combined > with publishing but there is a favoriting system already in place > which needs some loving and can be used as "vote for" without the > publish. > > I wonder if some of this is an optimisation on Twitters end, so to > save duplicating identical tweet (from a retweet) the status text is > shared amongst all the receivers of retweet. > > Paul > > 2009/8/17 Chris Babcock > > > > > On Mon, 17 Aug 2009 02:43:50 -0700 (PDT) > > janole wrote: > > > > > If you just don't agree with a tweet and want to express it via a > > > retweet, how can you do so with the proposed API? Seems to be > > > impossible or am I missing something? > > > > The new retweet API does not circumvent any of the current methods > > of expression. The only thing that it does is provide a method for > > verbatim retweets that is appropriate on social, semantic and data > > storage levels. It doesn't appear to be designed to handled "value > > added" retweets. There's no reason that it should be. That mode of > > expression is already served well enough by emergent behavior > > surrounding the current API. Value added re-expression is an > > evolving part of the Twitter experience. Codifying the current meme > > for that expression would be counter-productive. This API is not > > attempting to do that. It's only a provision for a meaningful, > > trackable, acceptable "me too" message. > > > > So to discuss a post with which a user disagrees, the retweet > > mechanism would *not* be used. That is a value added expression > > that would be best served by linking or replying, depending on the > > scope of the disagreement. > > > > Chris > > -- USAK now has more active games than any other judge of its kind. This quarter, USAK members contributed over $200. Thank you! Out of pocket cost for the judgekeeper was $95 for this period. Costs for second quarter 2009 are estimated at $262. Your donation is appreciated (opens in PayPal): http://tinyurl.com/USAK-Donate
Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)
> On Aug 17, 6:27 am, Chris Babcock wrote: > > > When you know your code is going to be seen you either avoid doing > > stupid things like hard coding credentials or you learn fast that > > configuration data is not code. > > Fair enough. So how do you do it? How do I distribute a desktop or > mobile device application - open source or closed - that uses my OAuth > credentials in such a way as to protect my credentials from being > discovered? > > Seriously, how do you do that? You don't distribute your credentials with the App. You include a README file that tells implementors how to get and install their own keys. Chris Babcock
[twitter-dev] Re: My Issue with the ReTweet API and my solutions
On Mon, 17 Aug 2009 02:43:50 -0700 (PDT) janole wrote: > If you just don't agree with a tweet and want to express it via a > retweet, how can you do so with the proposed API? Seems to be > impossible or am I missing something? The new retweet API does not circumvent any of the current methods of expression. The only thing that it does is provide a method for verbatim retweets that is appropriate on social, semantic and data storage levels. It doesn't appear to be designed to handled "value added" retweets. There's no reason that it should be. That mode of expression is already served well enough by emergent behavior surrounding the current API. Value added re-expression is an evolving part of the Twitter experience. Codifying the current meme for that expression would be counter-productive. This API is not attempting to do that. It's only a provision for a meaningful, trackable, acceptable "me too" message. So to discuss a post with which a user disagrees, the retweet mechanism would *not* be used. That is a value added expression that would be best served by linking or replying, depending on the scope of the disagreement. Chris
Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)
On Sun, 16 Aug 2009 18:49:49 -0400 Jason Martin wrote: > On another note, how "Open Source friendly" is OAuth? I'm not sure > if people who write open source software want to be giving out their > Consumer Secret key in their source code Reasoning from a faulty premise. When you know your code is going to be seen you either avoid doing stupid things like hard coding credentials or you learn fast that configuration data is not code. (Now where I did leave my virtual haddock?) Chris Babcock
[twitter-dev] Re: Early developer preview: Retweeting API
On Thu, 13 Aug 2009 23:55:44 +0100 (BST) AlisonW wrote: > > The idea is great, but the execution (imho) leaves a lot to be > desired. > > There are two types of retweet in my experience: > > The first is the 'plain' duplication of the original tweet, with just > the "RT @scnreename " on the front, and the proposed API additions > serve this very well. > > But many, indeed I'd argue the majority, of retweets I see are ones > where the original message - often a few words and a link - has been > commented upon by the retweeter, ie it is *not* a duplication. > Sometimes the original is short enough that the commenter can get in > with the character limit, sometimes they 'shorten' the original text > to get in their comment. > > There is far greater "added value" in a retweet when people add their > own comment before sending it on its way. Plain re-transmission just > fills up the screen. Right. And this mechanism will provide a way to differentiate between plain retweets and value added retweets. +1 to the API team. Chris
[twitter-dev] Re: FW: Twitter is Suing me!!!
On Thu, 13 Aug 2009 08:13:12 -0700 (PDT) Mike Langford wrote: > Twitter will also have to inform other existing clients, like > Twiterific and TwitterBerry, to cease and desist as well if it hopes > for a success application. I'm not sure the situation is that set in stone. If Twitter wants an alternative to massive numbers of C&Ds then it can contact developers currently using the Twitter name and offer reasonable terms to license it for their applications. It may or may not be as simple as "return this form signed and use this wording on your product" and there may be business reasons not to take that approach, but my pure and utterly uninformed guess would be that the lawyers are working on that form and that the API team has advocates with the advocates urging them to find a way to make it happen that doesn't require asking for a licensing fee. Chris Babcock
[twitter-dev] Re: FW: Twitter is Suing me!!!
On Wed, 12 Aug 2009 11:50:24 -0700 (PDT) Dewald Pretorius wrote: > It may be an irritation and it may cost you money, but it is NOT spam. > > You opted in to receive the notifications on your phone, and hence it > is NOT spam. If you have an email account sent notices to your IMs when you have email, those notices are not Spam, but the content of the message may be. Twitter's just the protocol. The "you have a follower" message is not Spam, but the act of following itself may be if the intent is to use Twitter's delivery methods to deliver unwelcome content. If a user opts-out of receiving follower notices because of the content of the followers' profiles then Spam has damaged the network infrastructure on which Twitter is based. Chris Babcock
[twitter-dev] Re: FW: Twitter is Suing me!!!
On Wed, 12 Aug 2009 11:17:38 -0600 Bioscience News wrote: > All this stuff about following being equated to spamming is nonsense. First, the act of following someone usually generates a message. When you first join Twitter, it's exciting to get new followers and you look forward to those messages. Then you start checking out the profiles to see if you want to follow back... and you find that you don't because it's a just a BambiBot or some other SpamBot. Soon you stop checking out your followers all together because the noise is too high in that channel. The content of the users' profile and existing Tweets are the payload of the Spam message communicated by following a user. Second, and more importantly, the social graph is part of the signal on Twitter. Part of the value of following a person may be the quality of their other followers. Without the Spam and the Ham in the following, you could browse the followers of those whose insight you appreciate and identify others who share that appreciation. You might even browse those they follow to try to find other users to follow like the one you had in common to begin with. Unless the content of the social graph is hand grown, or at least reasonably filtered, you lose the channel. So, yes, it is possible to have following Spam and it is a real problem for Twitter users. Chris Babcock
Auto-following (WAS: [twitter-dev] Re: FW: Twitter is Suing me!!!)
On Wed, 12 Aug 2009 05:17:27 -0700 Dale Merritt wrote: > What is Twitters real stance on auto following? In there API they > prohibit "mass following" so what does that mean exactly. More than > 1, 100? In my app, I had planned on integrating some meaniful auto > following I'm sure that someone could clarify "stance" if you could clarify "meaningful". :-) I think what's missing from the API here isn't hard limits, but a shared vocabulary for describing social design. We have this in the API TOS: 4. Do not create a bot to promote mass following. Twitter enables users to find and connect with people. Mass following does not help users find interesting connections. Applications found to be promoting valueless mass-following or following-ponzi schemes will be promptly blacklisted. So please, spend your time developing something that helps users find people with interesting connections. It's clear to me that the intent of the rule is an appeal to social design. "What is mass following?" is the wrong question. The right questions would be "What are interesting connections?" and "How do I help people find them?" I'm writing a game application that might auto return follows because it relies on DMs for a communication channel. I don't have any doubts about where this app stands with this rule. Finding other people who play the game definitely helps users find interesting connections. Another app might autofollow those who post on certain topics and retweet posts that are on-topic for the Bot, effectively amplifying certain channels and making it easier to find posts and posters. I think that this is likely an edge case. A bot that doesn't provide any additional filtering or processing over a saved search doesn't really serve any purpose other than promoting a mass following, while an application that adds value to the data stream could develop an immense following because it "helps users find people with interesting connections." Chris Babcock
[twitter-dev] Re: Twitter Update, 8/10 noon PST
On Mon, 10 Aug 2009 22:01:16 -0700 (PDT) hansamann wrote: > Can someone post a link to some online resources explaining more about > geometric back-offs? Did a search, did not find a whole lot. Retry intervals grow in a geometric progression: http://en.wikipedia.org/wiki/Geometric_progression A start value of 1 second that doubles on each subsequent retry is common, as are caps on the length of time to continue attempts. Chris Babcock
[twitter-dev] Re: using oauth - difference between authorize and authenticate URLs?
On Mon, 10 Aug 2009 08:02:33 -0700 (PDT) sasha wrote: > All in all, I agree with Chris - ideally, access and authentication > should be very distinct. Twitter Oauth is still a step in the right > direction vs. basic HTTP auth, but would be nice to have a strictly > authentication-based call that wouldn't require user to grant the > consumer any kind of access to personal data. > > It would be nice to have someone from the team to weigh in here to > understand their rationale for this kind of implementation of > authentication - is it an issue of resource constraints or is it > something else? Twitter is only implementing the OAuth spec. It just happens that the OAuth folks decided that OAuth authentication would be allowing the Consumer (app) to authenticate *as* the user rather than simply authenticating to the consumer that s/he *is* the user. I'll fall back to asking for the user to click on a link in a DM to demonstrate the ownership of a Twitter account. Coincidentally, a decision "not to fix" regarding upgrading read tokens to read/write tokens makes sense in this context. There's no sense burning LOCs on a corner case when there's a work around. If your application changes from read to read/write then see if a change from authorize tokens to authenticate tokens works. Chris Babcock
[twitter-dev] Re: Invalid / used nonce
On Mon, 10 Aug 2009 04:14:43 -0700 (PDT) graceawalker wrote: > I am calling and getting the whole way up to getting the access token > just fine in my app (one im writing myself in c#), but when i try and > call the update status URL im getting an 'Invalid/used nonce' error in > my response data. Im not sure why this is, im calling the update > method in the exact same way that i called request token apart from > the new 'status' parameter in the query string. I call 'verify > credentials' with my access token to ensure that it is working and it > sends me back all of the correct data, but it is erroring when trying > to update my status. Is there any obvious solution to this, or am i > not supposed to be signing and organising the parameters in the same > way that i did before? Im really stuck here guys and need help! Right, the nonce is a "number used once". Its purpose is to prevent replay attacks. If you use the same nonce for more than one call to the API then you *should* be getting an error. Chris
[twitter-dev] Re: using oauth - difference between authorize and authenticate URLs?
> I looked through the API, the online discussion, and wrote test code > to check both the authorize and authenticate methods. I have not been > able to find any difference between the two, apart from the request > URL (and, perhaps, some differences in language between Twitter's > authorize and authenticate pages). > > Are there any differences - or have the two URLs been implemented to > logically separate standard Oauth from "Sign in with Twitter", but are > otherwise identical? > > The reason I am asking is because I expected "authentication" to be > just that - with no rights or privileges to read or write to user's > Twitter account. It appears that when I use "sign in with Twitter", I > effectively gain the same level of privileges as I do via the standard > Oauth authorize flow. This was contrary to my expectations also, but it's in the OAuth specs, "OAuth authentication is the process in which Users grant access to their Protected Resources without sharing their credentials with the Consumer." - http://oauth.net/core/1.0/#anchor9 I'm somewhat disappointed. "Access" is the definition of authorization, not authentication. I would like to be able to differentiate between "prove who you are" and "give me the means to impersonate you." Chris Babcock signature.asc Description: PGP signature
[twitter-dev] Re: [Feature Request] Hiding certain Hashtags
> I think it'd be a nice feature to set posts with certain hashtags to
> "hidden" or something like that.
>
> Just tell me your thoughts - is this nonsense, if so - why? Or does
> this already exist..
I think it's a great idea for third party application.
In fact, I'm writing a Twitter API library for the CRM114 filter
language right now. The language includes not only regex matching
"/football/" but fuzzy regexps "/(football){~3}/" (football, within 3
characters) and learning/classifications with post-Bayesian filtering
algorithms. In other words, if people want to filter out content
containing the football tag that's easy to do with any programming
language - no new API call needed - but if people want to be able to
filter out (or in) content about Football - and have the filter
differentiate between American Football and what the rest of the world
knows as Football - then there are some interesting tools available
that will be just a little more accessible to the Twitter community
soon.
Chris Babcock
libtwitter.crm preview - http://crm.pastebin.com/f186a6e0
signature.asc
Description: PGP signature
[twitter-dev] 200 "errors"
This is what the 200 response is looking like: [u...@cl-t090-563cl bin]$ time curl -Lsim 10 http://twitter.com/account/rate_limit_status.xml HTTP/1.0 200 OK Connection: Close Pragma: no-cache cache-control: no-cache Refresh: 0.1 Content-Type: text/html; charset=iso-8859-1 http://www.w3.org/TR/1999/REC-html401-19991224/strict.dtd";> real0m0.100s user0m0.002s sys 0m0.004s [u...@cl-t090-563cl bin]$ time curl -Lsim 10 http://twitter.com/account/rate_limit_status.xml HTTP/1.1 200 OK Date: Sun, 09 Aug 2009 07:17:05 GMT Server: hi Last-Modified: Sun, 09 Aug 2009 07:17:05 GMT Status: 200 OK ETag: "d3498c2414150299df3cc1f6bb73b92c" Pragma: no-cache Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0 Content-Type: application/xml; charset=utf-8 Content-Length: 302 Expires: Tue, 31 Mar 1981 05:00:00 GMT X-Revision: 5a9a0d1ff0ba64c181510974278cfccc10e77d0b X-Transaction: 1249802225-83448-6420 Set-Cookie: _twitter_sess=BAh7BzoHaWQiJWVkNjk5Njk2YWNhNjQ3ZjgyOGQzNzdjNTAzMTE3ZjBmIgpm%250AbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAG%250AOgpAdXNlZHsA--639086f2287f85ef9e07f98d16adcce416b79e8d; domain=.twitter.com; path=/ Vary: Accept-Encoding Connection: close 150 150 1249805825 2009-08-09T08:17:05+00:00 real0m0.184s user0m0.002s sys 0m0.003s In a browser that would be functionally the same as a 302, but I'm not using a browser so the semantics are kind of important. It *seems* to happen whenever I hit the API with a cold request. Pure speculation. If I think of a way to test it, I will do so. Chris Babcock
[twitter-dev] Re: How do I handle 302 redirects with curl?
> Hmm, it shouldn't be spitting back HTML. How often are you seeing > this? I've seen it a couple times tonight and I'm not even doing any real testing, just trying a few variations manually to see if I might fine tune some of the calls in the library that I'm writing. Chris Babcock
[twitter-dev] Re: 302s are NOT the solution
On Sat, 8 Aug 2009 16:11:29 -0700 (PDT) Fawkes wrote: > They can, but apparently they don't, otherwise Twitter wouldn't have > used it as a tactic. They're going through a very difficult time, we > need to be patient and supportive of them! In order for an attacker to respond to a 302, they have to receive it. In order to receive it, they have to be giving their real IP address when they connect. If every legitimate app handled the 302 properly then those spoofing IP addresses would stand out very clearly. Even if attackers monitored the IP addresses that they were spoofing in order to try to escape detection by following the 302 responses, they still behave differently than legitimate users. The difference is that now security personel can identify repeated connections from the IP addresses that are being monitored by the attackers and tarpit those connections. Supplying a valid IP address from the attacking machines still slows down the attacker even if that IP address is not the actual point of origin for the attack. The moral of the story is "Apps that are good netizens contribute to the stability of the server." Chris Babcock
[twitter-dev] Re: DDoS Status Update
On Fri, 7 Aug 2009 11:05:32 -0700 Ryan Sarver wrote: > I wanted to send everyone an update to let you know what has been > happening, the known issues, some suggestions on how to resolve them > and some idea of how to move forward. This was really appreciated. When the dust clears, maybe one more suggestion? An API to check on the network status? I think infrastucture attacks aren't going away anytime soon. We've got a diversity of applications here, some of which can chew up the bandwidth pretty well and some of those just don't make sense to run if other users can't get on-line. Instead of answering, "Is it OK to restart my cron jobs?" the cron jobs could shut themselves down for increments of so many hours. Chris Babcock PS - Of course it could be misused, but I think the benefit is net. signature.asc Description: PGP signature
[twitter-dev] Re: Account Verify Credentials
On Thu, 6 Aug 2009 12:01:14 -0400 Robert Fishel wrote: > I too thought that one should call verify credentials with Oauth. How > are you suggesting we verify that the token is still active, another > call to oauth_authenicate/authorize? The oauth_authenicate and oauth_authorize calls are not rate limited. They can't be used to hack user credentials, so they don't need to be. Authentication is a once per session event. Once authenticated, a user remains authenticated to your app until your own session controls expire. This is independent of the user's Twitter session, except that the user needs to be authenticated with Twitter in order for Twitter to authenticate the user to your app. This happens once, at the beginning of the user's session with your app and it is not subject to a DoS attack on the account/verify_credentials service. It may be useful to verify that an authorization token has been activated, but checking authorization before a call that will fail if the authorization is not available is wasted bandwidth. You should check after the call to see if the action succeeded. It's more reliable and lower bandwidth. Chris Babcock
[twitter-dev] Re: Sign in with Twitter
On Thu, 6 Aug 2009 08:50:05 -0700 (PDT) Dewald Pretorius wrote: > If I understand you correctly, you're saying one should login for the > user in the OAuth process? Wouldn't that involve scraping the Twitter > web interface? Or am I outside the ballpark with my understanding? I'm saying that, for those who are more worried about losing users with an OAuth login than they are worried about losing them by asking for their Twitter password, it is still possible and desirable to use OAuth. There is a complexity cost, but you can pay it in the back end instead of passing it on to the user interface. The benefits are that the application isn't subject to the verify credentials DoS attack and the app will already be using OAuth if/when basic is discontinued. With OAuth, you authenticate the user, but you never use the verify credentials service to do so. Even if you set up a gateway so that you can use Ajax to log the user into Twitter and verify your own token, you don't verify credentials so much as use them. The API documentation is saying that the OAuth calls aren't rate limited. They don't need to be for security, but they may need to be limited by IP address for performance. The main point is that a user outside of your service can't trip the limit in order to run a DoS attack on your users. Chris Babcock
[twitter-dev] Re: Sign in with Twitter
On Thu, 6 Aug 2009 05:09:48 -0700 (PDT) Dewald Pretorius wrote: > Amen to that. > > When one does customer support for long enough, you quickly realize > that: > > a) People do not read instructions, and > > b) Many people are not as computer literate as you'd wish them to be. > > If you send people all over the place, many go, "WTF," and abandon the > process out of fear or ignorance. > > With Basic Auth the process is very simple. Enter the username and > password on your site, and click the save button. It shouldn't be any > more involved or complicated with OAuth. The problem with Basic Auth is that it doesn't know the difference between Authentication and Authorization. It's an oversimplification. The only way to do something *for* someone is to *be* that someone as far as the target system is concerned. A system that is as smart as it needs to be is going to be a little more complicated and involved than that. You can still do a little animated "authorize this" screen just like Facebook with OAuth. Just set up a gateway on your server and Ajax the whole work flow through the gateway. There's no need to complicate the UX. The complications can go in the back end so that you can get your authenticalization in one click. Chris Babcock signature.asc Description: PGP signature
[twitter-dev] Re: Account Verify Credentials
On Aug 5, 10:15 pm, Jesse Stay wrote: > On Wed, Aug 5, 2009 at 3:04 AM, Chris Babcock > wrote: > > > > > I would strongly recommend OAuth for verifying users, or at least > > making it an option, as there is a DoS attack possible against service > > providers who rely on this API for access to their app. > > > Chris Babcock > > I'm not sure how OAuth helps, as the problem still exists, even with OAuth > users. Even with OAuth, it is still 15 requests per user per hour on > verify_credentials. Of course, you probably don't have to run > verify_credentials as often with OAuth, but the problem still exists, and > there are cases where I can see this could become an issue. > > Jesse No, you *never* use verify_credentials with OAuth because you never handle user passwords. Take for example those users whose accounts are being slammed by SpamBots. They can still log into Twitter, just not those services that rely on verify_credentials service. Because they can still log in on the Twitter site, they could still authorize OAuth tokens. You will know that they have valid credentials on Twitter if the token has been authorized when they return to your site. It's not necessary for your app to obtain and verify the credentials directly. Your app can completely bypass the rate limited service with its DoS potential. Chris Babcock
[twitter-dev] Re: Account Verify Credentials
On Tue, 4 Aug 2009 16:40:27 -0400 Bob Fishel wrote: > On Tue, Aug 4, 2009 at 1:45 AM, Bob Fishel > wrote: > > From the api documentation: > > > > "Because this method can be a vector for a brute force dictionary > > attack to determine a user's password, it is limited to 15 requests > > per 60 minute period (starting from your first request)." > > > > Is this per user? > > > > ie: if my server queries user A and gets credentials verified ok > > after 14 other users verify am I locked out or is it just after 15 > > tries for the same user? The former would seem illogical but I just > > want to make sure... > > > > Thanks, > > > > Bob > > > > I hate to "bump" this as it were but does anyone have any insight? > > Thanks, > > Bob > The actual behavior is 15 requests, regardless of success, per username. I tested it by using curl with one account until I got an error then I tried it with a different account - successfully - and retried the first account to make sure the block was still in place. I also changed the source IP address in curl to verify that access is not tracked by IP Address. I would strongly recommend OAuth for verifying users, or at least making it an option, as there is a DoS attack possible against service providers who rely on this API for access to their app. Chris Babcock signature.asc Description: PGP signature
[twitter-dev] Re: Account Verify Credentials
On Tue, 4 Aug 2009 16:40:27 -0400 Bob Fishel wrote: > On Tue, Aug 4, 2009 at 1:45 AM, Bob Fishel > wrote: > > From the api documentation: > > > > "Because this method can be a vector for a brute force dictionary > > attack to determine a user's password, it is limited to 15 requests > > per 60 minute period (starting from your first request)." > > > > Is this per user? > > > > ie: if my server queries user A and gets credentials verified ok > > after 14 other users verify am I locked out or is it just after 15 > > tries for the same user? The former would seem illogical but I just > > want to make sure... > > > > Thanks, > > > > Bob > > > > I hate to "bump" this as it were but does anyone have any insight? > > Thanks, > > Bob > The actual behavior is 15 requests, regardless of success, per username. I tested it by using curl with one account until I got an error then I tried it with a different account - successfully - and retried the first account to make sure the block was still in place. I also changed the source IP address in curl to verify that access is not tracked by IP Address. I would strongly recommend OAuth for verifying users, or at least making it an option, as there is a DoS attack possible against service providers who rely on this API for access to their app. Chris Babcock signature.asc Description: PGP signature
[twitter-dev] "Something is technically wrong" with Create Block
[u...@cl-t090-563cl twitter]$ curl --basic --user UserName:Password -d screen_name=SpammerJane http://twitter.com/blocks/create.xml ... Something is technically wrong. Thanks for noticing—we're going to fix it up and have things back to normal soon. ... I'm building a library of curl calls for use with the CRM114 filter language (as in Spam filtering). It appears that this syntax should be expected to succeed, but fails due to a transient error. I would like to know whether my assessment of that is correct and, if so, how transient. Some volatility is expected with the API under active development. If this syntax is preferred, 'curl --basic --user UserName:Password -d "" http://twitter.com/blocks/create/SpammerJane.xml' (which worked) then I can refactor my code to use the preferred syntax. Alternatively, I can build the library with redundant API calls if warranted. A retry mechanism is probably in order once working calls are in place. What would you recommend for a retry interval? My first thought is to start at 10 seconds and double it each attempt for four days. On a related note, what does a call to the Create Block API return if the user being blocked no longer exists? Chris Babcock
