Re: [twitter-dev] user stream best practices
I understand. There's lots of sausage making going on behind the scenes. You make it the best you can. Often for reasons that I cannot hope to understand. ;-) Let me stop being metaphysical and boil this down to a simple bug report: There is no documentation of how to get from the schema of the User Stream API to the schema of the REST API. Here's why this is a problem: The REST API divides and filters data, sometimes in some non-obvious ways. User streams divide the data less. It's the clients job to fetch backfill from one API, stream from the other, and display the result such that the display is consistent no matter which API the tweets came from. In practice when I compare the clients that use streams, they're all falling down in a few places. Here's an example 1: I retweet a tweet from my Home timeline. In Twitter.com it does NOT appear In Client A it DOES appear (but not if fetched from backfill) In Client B it does NOT appear. And example 2: I retweet a tweet from a list that is not in my Home timeline. In Twitter.com it DOES appear In Client A it DOES appear In Client B it does NOT appear. (but does if fetched from backfill) So, it looks to me like twitter.com seems to be de-duplicating the original tweets of retweets. Client A de-duplicates only regular tweets letting all retweets through. Client B remove all retweets that i create. Both clients have different behavior for streaming than they do for backfill. * Client A is my client (Kiwi), Client B is a very popular streaming client on the Mac. I have not been able to find any client that behaves consistently between backfill and streaming. All fail on at least one corner case that I'm aware of. There are subtle behaviors, some undocumented, that each developer must find, analyze and implement. It's difficult. We're not doing so well. In order to make bug-free clients we need Twitter to make the schema the same, or (if that sausage is too expensive) document how they differ. isaiah http://twitter.com/isaiah On Dec 18, 2010, at 7:48 AM, John Kalucki wrote: Yes, our model does externalize some development and hosting costs onto clients. But, we tend to only externalize cost when issues would be far cheaper, in aggregate, to solve on the client, or would be intractable to solve on our end and might otherwise prevent the launch of the feature. We try to balance this cost externalization very carefully and with all due concern for everyone's time. Our resources are limited, and our reasoning may not always be immediately obvious, but we're trying to get you as much data as possible, as efficiently as possible for everyone. -John Kalucki http://twitter.com/jkalucki Twitter, Inc. On Tue, Dec 14, 2010 at 2:07 PM, Isaiah Carew isa...@me.com wrote: In other words, if I want to disambiguate the stream, I have to filter it myself. Well, humph… Not impossible, just a pain in the butt. From an information organization standpoint, it seems odd: The REST API is broken out into separate calls. The stream has everything glommed together. It would be no big deal if you only needed one or the other, but you have to do backfill with the REST API, so you always need both. The REST API has hierarchy in the endpoints. The Stream API has hierarchy in the schema. Why not make the hierarchies (at least roughly) the same? You don't have to answer, I'm just mouthing off. I'll get back to work writing a track-term to nspredicate converter. ;-) isaiah http://twitter.com/isaiah On Dec 13, 2010, at 9:30 AM, John Kalucki wrote: Roughly: If the tweet is from a following, place it in the home timeline. If the tweet refers to the user (to or from), or contains the @screenname place it in mentions If it's a message - messages. What remains is probably a track term. -John Kalucki http://twitter.com/jkalucki Twitter, Inc. On Fri, Dec 10, 2010 at 5:58 PM, isaiah isa...@mac.com wrote: Hi, I'm implementing user streams in my client and looking for some advice on best practices. My client supports viewing multiple timelines at the same time, so it's quite possible to, for example: view a saved search, the user's own home timeline, and another user's recent tweets. Of course, I'd love to implement these in user streams. My concern is that if each of these timelines were to open a separate stream simultaneously, then the user could easily cross over their limit of active streams. Another potential solution seems to be adding the search and the second user as tracking parameters to a single user stream. That works fine and the track parameter limitations seem to be similar to the limitations of the UI/UX of my app, so it seemed like a good fit. The challenge is that once track parameters are added to the stream I get a whole bunch of new statuses returned but i can't tell which are associated with each parameter
Re: [twitter-dev] user stream best practices
In other words, if I want to disambiguate the stream, I have to filter it myself. Well, humph… Not impossible, just a pain in the butt. From an information organization standpoint, it seems odd: The REST API is broken out into separate calls. The stream has everything glommed together. It would be no big deal if you only needed one or the other, but you have to do backfill with the REST API, so you always need both. The REST API has hierarchy in the endpoints. The Stream API has hierarchy in the schema. Why not make the hierarchies (at least roughly) the same? You don't have to answer, I'm just mouthing off. I'll get back to work writing a track-term to nspredicate converter. ;-) isaiah http://twitter.com/isaiah On Dec 13, 2010, at 9:30 AM, John Kalucki wrote: Roughly: If the tweet is from a following, place it in the home timeline. If the tweet refers to the user (to or from), or contains the @screenname place it in mentions If it's a message - messages. What remains is probably a track term. -John Kalucki http://twitter.com/jkalucki Twitter, Inc. On Fri, Dec 10, 2010 at 5:58 PM, isaiah isa...@mac.com wrote: Hi, I'm implementing user streams in my client and looking for some advice on best practices. My client supports viewing multiple timelines at the same time, so it's quite possible to, for example: view a saved search, the user's own home timeline, and another user's recent tweets. Of course, I'd love to implement these in user streams. My concern is that if each of these timelines were to open a separate stream simultaneously, then the user could easily cross over their limit of active streams. Another potential solution seems to be adding the search and the second user as tracking parameters to a single user stream. That works fine and the track parameter limitations seem to be similar to the limitations of the UI/UX of my app, so it seemed like a good fit. The challenge is that once track parameters are added to the stream I get a whole bunch of new statuses returned but i can't tell which are associated with each parameter. Or, well, I couldn't figure out how to tell short of building a regex for each of my track parameters and trying to sort the items by hand (yuck!). So my question: 1. Is there some way to disambiguate statuses returned as a specific track parameter from those returned for other reasons? 2. Is there some other way to skin this cat that I'm missing? Thanks, Isaiah -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] YFrog/ImageShack and invalid username or verification url error
Did you ever get to the bottom of this? I've been getting this same response from yFrog -- but all of the other oAuth Echo supporting services seem to be working just fine. isaiah http://twitter.com/isaiah On Jul 20, 2010, at 4:21 PM, DWF wrote: Anyone else seeing this? We're implementing OAuth Echo for uploading photos. We've knocked down Posterous TwitPic with few issues. So we know our signing is working. We now have an ImageShack API key and when we attempt to upload we get this response: ?xml version=1.0 encoding=UTF-8? rsp stat=fail err code=1001 msg= Invalid username or verification URL specified/ /rsp There's one comment on their Google Group with someone else getting this suddenly after having successful code for a while. Thoughts? --dwf
Re: [twitter-dev] YFrog/ImageShack and invalid username or verification url error
Oh, never mind. I've answered my own question. It looks like yFrog only supports XML for the https://api.twitter.com/1/account/verify_credentials.xml In other words, they don't accept https://api.twitter.com/1/account/verify_credentials.json At least that's my understanding from their docs. Someone correct me if I'm wrong here. So, I've dropped 'em for now from Kiwi. Just too much pain all around. For those interested I've had really good luck with TwitPic, TwitrPix, and TwitGoo -- all seem to support echo well. I've implemented support using both my own OBJ-C and on the iPhone using Aral's X-Auth libs on GitHub. isaiah http://twitter.com/isaiah On Jul 26, 2010, at 4:49 PM, Isaiah Carew wrote: Did you ever get to the bottom of this? I've been getting this same response from yFrog -- but all of the other oAuth Echo supporting services seem to be working just fine. isaiah http://twitter.com/isaiah On Jul 20, 2010, at 4:21 PM, DWF wrote: Anyone else seeing this? We're implementing OAuth Echo for uploading photos. We've knocked down Posterous TwitPic with few issues. So we know our signing is working. We now have an ImageShack API key and when we attempt to upload we get this response: ?xml version=1.0 encoding=UTF-8? rsp stat=fail err code=1001 msg= Invalid username or verification URL specified/ /rsp There's one comment on their Google Group with someone else getting this suddenly after having successful code for a while. Thoughts? --dwf
[twitter-dev] xauth token exchange failing
Hi, I'm seeing across the board failure of xAuth token exchange for my app, Kiwi. The app has not changed for months and is in use by thousands of users. So I don't think it's something I've done recently. Is it related to what I'm seeing on status.twitter.com? Is there a way to tell whether the problem is: twitter, my IP, my app, or my accounts? Is there something in the HTTP response tea leaves that can tell me more info? Currently I'm getting: Status = 500 Internal Server Error; isaiah http://twitter.com/isaiah
Re: [twitter-dev] xauth token exchange failing
The status page at: dev.twitter.com/status says things are all go -- but I'm still getting 500s during token exchange. Any updates? isaiah http://twitter.com/isaiah On Jul 19, 2010, at 12:55 PM, Taylor Singletary wrote: Hi Isaiah, This is related to the same issue you see on status.twitter.com -- it's effecting many user-related write operations (including, for instance, instantiating an access token on behalf of a user). We are working to resolve the issue. Taylor On Mon, Jul 19, 2010 at 12:10 PM, Isaiah Carew isa...@me.com wrote: Hi, I'm seeing across the board failure of xAuth token exchange for my app, Kiwi. The app has not changed for months and is in use by thousands of users. So I don't think it's something I've done recently. Is it related to what I'm seeing on status.twitter.com? Is there a way to tell whether the problem is: twitter, my IP, my app, or my accounts? Is there something in the HTTP response tea leaves that can tell me more info? Currently I'm getting: Status = 500 Internal Server Error; isaiah http://twitter.com/isaiah
Re: [twitter-dev] Re: xauth token exchange failing
OK, good to know. Just want to make sure it's not just me. Misery loves company, I guess. :-P isaiah http://twitter.com/isaiah On Jul 19, 2010, at 2:54 PM, Tim Davies wrote: Im getting the same isalah. Twitter are aware of the issue. its during handshake for creating new tokens and maybe linked to several other OAuth issues that came to attention this morning. Im hoping it will be fixed shortly!
Re: [twitter-dev] Re: Rate limits should be resetting now
Great news. I'm crossing my fingers too. isaiah http://twitter.com/isaiah On Jul 7, 2010, at 8:32 PM, Raffi Krikorian wrote: we are currently sitting at 100% - so 350 calls/hour on oauth, and 150 calls/hour on basic auth. fingers crossed! On Wed, Jul 7, 2010 at 6:42 PM, isaiah isa...@mac.com wrote: Does this mean a return to previous rate limits as well? Or are we still getting the squeeze? Isaiah On Jul 7, 5:54 pm, themattharris thematthar...@twitter.com wrote: Hey everyone, We've been working on the rate limit issue which has been affecting many of you and believe we now have it fixed. As the issue affected people in different ways we want to be check your applications are working again. If your rate limit is still not resetting please email a...@twitter.com the following information: * The IP of the computer which is making the requests * A username you are making requests for * The time you tried to make the request * The request you were trying to make * Any response headers you received Thanks, Matt -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
[twitter-dev] lockouts are the new black
Lockouts are now common and frequent for everyday users doing normal things. I have dozens of reports from my users being locked out. And I've noticed that nearly every Twitter client developer has posted about this in a blog or Tweet. Several in just the last 24 hours. I know that the goal is to improve the latency and failures (i.e. whales) that you guys were seeing during the world cup. But creating lockouts to reduce failures is cutting off your nose to spite your face. Failures, lagging, and latency are frustrating but at least *feel* egalitarian. Service disruption is nothing new -- we understand it whether it's ATT, temporary power failures, or whatever. Lockouts feel punitive and targeted. Users really really don't like it. I think it's safe to say that this is now *the* critical issue. All other twitter concerns seem dwarfed by this massive problem. isaiah http://twitter.com/isaiah
Re: [twitter-dev] lockouts are the new black
John, Do you measure the number of lockouts? Or maybe a better question is: do you have metrics on how reducing rate limits is impacting users? isaiah http://twitter.com/isaiah On Jul 6, 2010, at 9:10 AM, John Kalucki wrote: These lockouts are almost certainly due to a performance optimization intended to reduce network utilization by increasing physical reference locality in a multi-level loosely-coordinated best-effort distributed cache. Not easy to get right, and the engineers involved are working to resolve the issue. There's absolutely no intention to lock people out. -John Kalucki http://twitter.com/jkalucki Infrastructure, Twitter Inc. On Tue, Jul 6, 2010 at 9:00 AM, Isaiah Carew isa...@me.com wrote: Lockouts are now common and frequent for everyday users doing normal things. I have dozens of reports from my users being locked out. And I've noticed that nearly every Twitter client developer has posted about this in a blog or Tweet. Several in just the last 24 hours. I know that the goal is to improve the latency and failures (i.e. whales) that you guys were seeing during the world cup. But creating lockouts to reduce failures is cutting off your nose to spite your face. Failures, lagging, and latency are frustrating but at least *feel* egalitarian. Service disruption is nothing new -- we understand it whether it's ATT, temporary power failures, or whatever. Lockouts feel punitive and targeted. Users really really don't like it. I think it's safe to say that this is now *the* critical issue. All other twitter concerns seem dwarfed by this massive problem. isaiah http://twitter.com/isaiah
Re: [twitter-dev] xAuth Approval?
On Apr 26, 2010, at 8:54 PM, Raffi Krikorian wrote: xAuth is a method for which to exchange usernames and passwords for those tokens, without send the user through the workflow. this is for two reasons: 1. mobile/desktop application authors have complained that it makes their UX fugly when they bring up a web browser (i'll hold my opinions on this); and 2. web applications that have been storing usernames and passwords need a method to bulk convert all their users over to oauth tokens. and 3. Browserless environments. I'm pretty sure that was one of the initial motivators way back when the crud was flying. Yeah ... but I *like* having the browser involved. +1 ! It's so tempting to respond in kind to that sort of professionalism. Isaiah -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
Re: [twitter-dev] User Stream's API usage
Any chance on getting access to a beta of these from outside chirp? I had to
come home this afternoon and didn't get to play too much while i was there, but
would be really interested in playing more. I understand it's not ready for
roll out. Just looking to start the development process.
isaiah
http://twitter.com/isaiah
On Apr 14, 2010, at 9:26 PM, John Kalucki wrote:
I should have encouraged folks to understand the Streaming API first. You can
read up on all the details here:
http://apiwiki.twitter.com/Streaming-API-Documentation
But, for a prototype, just dive right in.
-John
On Wed, Apr 14, 2010 at 9:15 PM, Mark McBride mmcbr...@twitter.com wrote:
Some sample APIs...
curl -uyouruser:yourpass http://chirpstream.twitter.com/2b/user.json
Will give you a stream of your home timeline, social activity from your
friends, and direct messages.
curl -uyouruser:yourpass
http://chirpstream.twitter.com/2b/user.json?track=#chirp;
Will give you all of the above, plus any tweets matching #chirp
Does that clear it up? If not, I'm currently near The Coop.
---Mark
http://twitter.com/mccv
On Wed, Apr 14, 2010 at 6:37 PM, Kovas Boguts kovas.bog...@gmail.com wrote:
Hi,
Is there any description of how to use this? I don't understand how to use
track with this or what is generally available for hack day. Thanks!
On Apr 14, 2010, at 4:17 PM, John Kalucki j...@twitter.com wrote:
Email me your account name. You are in, but not getting data. Also, is this
account following anyone?
Typos by iPhone.
On Apr 14, 2010, at 4:11 PM, Jud jvale...@gmail.com wrote:
I'm in the chrip conference IP address range, but
http://chirpstream.twitter.com/2b/user.json usage isn't clear.
- the follow predicate in a POST doesn't work (should it?)
- track as a predicate gets accepted, but no data comes through (I get
a single '{friends:[]}', but that's it)
- am I supposed to be tracking userids or names or keywords?
is the resource simply not turned on until later at/on the hackathon's
network?
--
To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] What's happening with Tweetie for Mac
Crystal clear. 1. You're decimating the client market on every platform but Windows. 2. You're killing any potential for innovation or investment. 3. You have no clear (public) plan for any innovation yourself. What marketing genius... Oh never mind. It's not worth the breath. Good luck with that. Anyone want a chirp ticket? isaiah http://twitter.com/isaiah On Apr 12, 2010, at 7:40 AM, Ryan Sarver wrote: One more from me. People have been asking for specific details around Tweetie for Mac and I wanted to make sure we clearly message our plans as we know it. To be clear, Tweetie for the iPhone and it's developer, Loren Brichter, were the focus of our acquisition, but as part of the deal we also got Tweetie for Mac. Loren had been hard at work on a new version of Tweetie for Mac that he was going to release soon. Our plan is to still release the new version and it will continue to be called Tweetie (not renamed to Twitter). We will also discontinue the paid version. Hope that's clear. Please let me know if you have any questions. Best, Ryan -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] What's happening with Tweetie for Mac
sorry for being cranky, but i just spent a year building a tweetie competitor. you can't fault a guy for saying ouch while your knife is still sticking out of his back, right? isaiah http://twitter.com/isaiah On Apr 12, 2010, at 9:10 AM, Jesse Stay wrote: I think it's great that Twitter is finally being more transparent about all this. I could argue they need to be more transparent (where do they plan to go in the analytics and enterprise spaces?), but it's about time. They've finally drawn the line in the sand - now we need to adapt. Yes, it's frustrating, but then again, 90% of businesses fail - it's the risk all of us took. We either compete, or quit, and move on. I don't get all the complaints - this is nothing new. I've had half my features replaced by Twitter over the last few years (quite literally - just read my blog - I'm the chief complainer). By now I realize that's either part of life (note: it's the same on Facebook, too - there's no escaping it), or I change my focus to where Twitter is not my core and I instead use Twitter to strengthen my new core. That's where Twitter (and Fred Thompson) have made it clear they want us to go. Finally, some clarity. I'm appreciative of it, regardless of how frustrating it can be. Time for all of us to take this constructively and adapt. Just my $.02 FWIW... Jesse On Mon, Apr 12, 2010 at 9:54 AM, Isaiah Carew isa...@me.com wrote: Crystal clear. 1. You're decimating the client market on every platform but Windows. 2. You're killing any potential for innovation or investment. 3. You have no clear (public) plan for any innovation yourself. What marketing genius... Oh never mind. It's not worth the breath. Good luck with that. Anyone want a chirp ticket? isaiah http://twitter.com/isaiah On Apr 12, 2010, at 7:40 AM, Ryan Sarver wrote: One more from me. People have been asking for specific details around Tweetie for Mac and I wanted to make sure we clearly message our plans as we know it. To be clear, Tweetie for the iPhone and it's developer, Loren Brichter, were the focus of our acquisition, but as part of the deal we also got Tweetie for Mac. Loren had been hard at work on a new version of Tweetie for Mac that he was going to release soon. Our plan is to still release the new version and it will continue to be called Tweetie (not renamed to Twitter). We will also discontinue the paid version. Hope that's clear. Please let me know if you have any questions. Best, Ryan -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] What's happening with Tweetie for Mac
hey look, i'm not looking for a flame war here. what twitter did just seemed a bit less than nice to me, that's all. this is the forum for developer feedback, if i'm not mistaken. i was feeding back. you've got a lot of valid points, and maybe a few stretched analogies, too. if you'd like my thoughts on this i posted a nicer, more thought out article: http://yourhead.tumblr.com/post/516626319/le-roi-est-mort-vive-le-roi i'd be happy to continue to debate via email or at chirp (yes, i'm going, i'm a glutton for punishment, shoot me). see you guys tomorrow, isaiah http://twitter.com/isaiah On Apr 12, 2010, at 6:08 PM, TjL wrote: On Mon, Apr 12, 2010 at 11:54 AM, Isaiah Carew isa...@me.com wrote: 1. You're decimating the client market on every platform but Windows. The iPhone and Mac versions of Tweetie have been a) dominant and b) free (ad-supported). If your app was set to compete with Tweetie 2 on the Mac and iPhone before this, it still is. If it wasn't, it still isn't. Also, you've had a LOT of time to compete against Tweetie on the Mac. If you missed the window, well, sorry. 2. You're killing any potential for innovation or investment. Oh, baloney. Ask BareBones how BBEdit has done competing against the free version of TextEdit. In 2010, you are going to compete with free. That sucks, but it's the reality of the situation. You'd better have a plan in place for it. I'm still giving EchoFon for Mac and iPhone a serious look. Why? Because it has features Tweetie doesn't. I'd start with looking at what Tweetie doesn't offer. What does it make too difficult? really wish i knew why so many twitter clients are against keyboard navigation and proper highlighting http://twitter.com/bynkii/status/12026843737 (21 hours ago… Via Tweetie) Tweetie breaks several Mac UI principles (click to select a word comes to mind). A good UI for filtering tweets based on strings (SXSW comes to mind). Sync between Mac and iPhone. Push notifications for mentions. Push notifications for mentions only for people who follow you. Push notifications for mentions only for people you follow. Push notifications of new posts by only a select group of people (like SMS notifications, but without SMS). I'm still waiting for someone to build a big enough database to get relationship data in-app (x person is also followed by these people you follow, as one example). There are a half-dozen ideas off the top of my head. 3. You have no clear (public) plan for any innovation yourself. Have you published your plan for innovation somewhere? I'm under the impression that *most* companies keep their future plans a fairly well guarded secret. (Well, except for Microsoft, who tell you what they are going to do and then do 1/100th of it 4 years later.) TjL -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] api stability vs. risk
we strive to do everything we possibly can to keep everything as backwards compatible as possible -- in fact, we jump through many hoops to do it. maybe it's just me, but backwards compatible seems like a liability rather than a benefit. attempting backwards compatibility constrains your innovation without providing any real insulation from changes to customers. however: we will change things. backwards compatibility requires that you all have -good- XML and JSON parsers that can accept the addition of new parameters without breaking. agreed. and my anecdotal situation could have been resolved if my library didn't have that bug. yep. you're right. ... but you've also missed the point. the point is that as the number of users of your API grows, EVERY change you make WILL stimulate SOME bug. it just doesn't matter how careful you are, i am, or how great my libraries are. the only hope that we have of keeping those bugs from reaching real customers is to test the changes before deploying. step back for a moment. think of the user. they don't experience the API and the client and the backend as separate entities. they just see Twitter as a single whole. changes to the API are making revisions to that whole. it seems wise that we have some way to do integration testing with the other parts before letting the customer see the changes. right now, you're introducing changes to a complex system without testing their real world results on your customers. it pains me to hear that you all think that talking to us is like talking to a brick wall each time i post to this list you respond in this way. i'm not sure what i'm doing to provoke this feeling, but i assure you it's not what I think at all. you guys are whatever the opposite of a brick wall is. i apologize, i must have a gruff tone. i'm not angry. in fact i enjoy the back and forth that we have with the API team. but i'll see if i can't just tone it down a notch. :-P Isaiah -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Obj-C xAuth Demo
Hi guys, For those looking to implement xAuth for Mac OS X, I've set up a complete working demo app. It uses MGTwitterEngine and the OAConsumer libs to do the dirty work and just adds enough to implement the new xAuth flow. I've tried to keep the code as simple to understand as possible, but it does the basics: - Adds the required parameters to the access token request - Overloads the request method in MGTwitterEngine with a signed request. - Shows how to store the access key in the Mac OS X Keychain. - Performs a basic tweet post and fetches the home timeline. It's just meant to help people get going and see a complete solution in action or a as a resource to compare their own solution. I did one of these for OAuth last summer and it was pretty popular, so I figured I'd just keep the ball rolling. You can see the github repo here: http://github.com/yourhead/xAuth_ObjC_Test_App And if you're not approved for xAuth you can download a complete Mac OS X binary that was compiled with working keys -- in case you just need something simple to TCP dump. You can download the binary here: http://github.com/yourhead/xAuth_ObjC_Test_App/downloads I'd be pleased with any sort of feedback, about the code, about the app, or just ways that it could be made more approachable for people new to the topic. isaiah http://twitter.com/isaiah/ http://twitter.com/kiwi-app/
Re: [twitter-dev] Re: xAuth
Try passing in nil as the token. The access token request should be similar to how you used to perform the request token request. The best explanation (and they one that helped me) is from Steve Reynolds: http://ke-we.net/7u isaiah http://twitter.com/isaiah On Mar 1, 2010, at 1:26 PM, Berto wrote: Hey Isaiah, What do you mean by default token? I'm working on getting xAuth implemented, but I seem to get a 401 even though I received an email I was approved. I've tried using a token I get from request_token (which from your reply, doesn't seem like I need to be doing) and not passing a token at all. On Feb 27, 1:45 pm, Isaiah Carew isa...@me.com wrote: i did manage to get xauth working this morning thanks to @SteveReynolds. the big epiphany (Steve's, not mine) was that there is no token exchange at all. in fact you don't even seem to need to acquire a request token ever. you simply jump directly to the auth token request and pass in your default token. it seems to make sense to me now, it was just a leap that i didn't make on my own. i just thought i'd post this in case anyone else out there is stuck too. when it's a bit more cleaned up, i'll post my results to github. isaiahhttp://twitter.com/isaiah On Feb 27, 2010, at 9:37 AM, Aral Balkan wrote: Like a n00b, I didn't include the id of my app in my original support request (I hadn't registered it since I wasn't using oAuth previously) and so it looks like I've missed the initial boat :( Got a message back asking for my app id so I registered Feathers and got back to the ticket but apparently the Twitter helpdesk/zendesk is down (http://help.twitter.com) so not sure if my ticket was updated. Would really appreciate it if anyone can look into the ticket (Ticket #863920) Thanks :) Aral On Sat, Feb 27, 2010 at 6:47 AM, Isaiah Carew isa...@me.com wrote: So, I received the xAuth green light. Yeah!!! Unfortunately, the email was not very detailed about which app was enabled (I have 3). (and for the record I was very detailed in my request about which one I was requesting access for). snip
[twitter-dev] missing tweets
Several users are reporting missing tweets over the past 8 hours. The problem exists even on twitter.com. One of my accounts is also affected. Even though @kiwi_app and @isaiah follow many of the same people, the @isaiah account is empty for the past 8 hours except for it's own tweets. I haven't seen anything new on http://status.twitter.com about this, so I thought I'd post it. isaiah http://twitter.com/isaiah
[twitter-dev] xAuth
So, I received the xAuth green light. Yeah!!! Unfortunately, the email was not very detailed about which app was enabled (I have 3). (and for the record I was very detailed in my request about which one I was requesting access for). So I gave it a shot. No dice. Seems to behave the same way as yesterday. So, now I've tried all three of my registered app credentials, just in case. Same 401 result. I've tried changing all the switches on the Twitter App configuration page. Then on all thee apps. Nope. Nope. Nope. Should the xauth parms be included in the base string for generating the signature? My guess is yes, but I couldn't find anything very conclusive after scouring the oauth spec and the xauth paper. I've tried both -- with all my apps -- with all the switches. Nope ^ 4. The number of ambiguous variables is pretty large here. Would anyone on the api team like to throw me a bone and tell me: - which app they enabled? - if there are specific settings on the App page that should be set or not set? (Client or Web? Login with Twitter?) - i'd really love to know the specifics about the xauth params and the signature. i'm sure it's in some doc somewhere -- a link to a page in a doc would be super. Just nailing down a few of those combinations will make the debug process a lot smoother. Currently I'm using an implementation that works very well pre-xauxth and is successfully getting request tokens without any problems. If I switch it over to PIN mode things seem to work well for all three apps of my Twitter apps. It generates the required headers, and exchanges request tokens for oauth tokens reliably. Unfortunately the error messages aren't very interesting: 401: Unauthorized. feel free to email for more techy details. i've got loads. ;-) isaiah http://twitter.com/isaiah
Re: [twitter-dev] xAuth
i did manage to get xauth working this morning thanks to @SteveReynolds. the big epiphany (Steve's, not mine) was that there is no token exchange at all. in fact you don't even seem to need to acquire a request token ever. you simply jump directly to the auth token request and pass in your default token. it seems to make sense to me now, it was just a leap that i didn't make on my own. i just thought i'd post this in case anyone else out there is stuck too. when it's a bit more cleaned up, i'll post my results to github. isaiah http://twitter.com/isaiah On Feb 27, 2010, at 9:37 AM, Aral Balkan wrote: Like a n00b, I didn't include the id of my app in my original support request (I hadn't registered it since I wasn't using oAuth previously) and so it looks like I've missed the initial boat :( Got a message back asking for my app id so I registered Feathers and got back to the ticket but apparently the Twitter helpdesk/zendesk is down (http://help.twitter.com) so not sure if my ticket was updated. Would really appreciate it if anyone can look into the ticket (Ticket #863920) Thanks :) Aral On Sat, Feb 27, 2010 at 6:47 AM, Isaiah Carew isa...@me.com wrote: So, I received the xAuth green light. Yeah!!! Unfortunately, the email was not very detailed about which app was enabled (I have 3). (and for the record I was very detailed in my request about which one I was requesting access for). snip
Re: [twitter-dev] Which api url to use?
i'm bound to forget this in about an hour. is this old/new versioned/not listed somewhere in the API docs? On Feb 22, 2010, at 9:42 AM, Ryan Alford wrote: Yes, those are the ones I am talking about. Ryan On Mon, Feb 22, 2010 at 12:41 PM, Raffi Krikorian ra...@twitter.com wrote: hi ryan. yup - those are the original update methods, right? like http://twitter.com/statuses/update.xml http://twitter.com/statuses/update.json we haven't set a deprecation date for those yet - but developers should plan on it. please start to migrate to the api.twitter.com/1/ URLs. On Mon, Feb 22, 2010 at 9:26 AM, Ryan Alford ryanalford...@gmail.com wrote: Raffi, Just so you know, http://twitter.com/statuses/update.format; also works. That's what I have been using in my app until today(moved to the versioning). Ryan On Mon, Feb 22, 2010 at 12:23 PM, Raffi Krikorian ra...@twitter.com wrote: yeah - please use the /1 URLs. if api.twitter.com works without /1, then that's inadvertent, and we'll probably fix that. On Mon, Feb 22, 2010 at 9:18 AM, Ryan Alford ryanalford...@gmail.com wrote: I *believe* Twitter is moving to versioning the API(which is what the /1/ means..it's version 1). So I would use the URL with the /1/, since the other way be deprecated in the future. Ryan On Mon, Feb 22, 2010 at 11:19 AM, Dmitri Snytkine d.snytk...@gmail.com wrote: Is there a difference between using http://api.twitter.com/1/statuses/update.format and http://api.twitter.com/statuses/update.format (without the /1/)? -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Which api url to use?
the docs wiki pages list the end-point URLs such as: http://search.twitter.com/search.format and http://api.twitter.com/1/statuses/home_timeline.format but it doesn't say much about the 1 being a version number, or about why some endpoints (e.g. search) have a different base URL than others, or why they were recently changed, or if/when we should change our apps, or if the old endpoints are depreciated. or more than likely, it probably does say all those things, i just missed it and was hoping the list could help me locate the docs. thanks, isaiah On Feb 22, 2010, at 11:02 AM, Ryan Alford wrote: Its actually listed on all of the twitter api method pages, except for the OAuth methods. Ryan Sent from my DROID On Feb 22, 2010 1:58 PM, Isaiah Carew isa...@mac.com wrote: i'm bound to forget this in about an hour. is this old/new versioned/not listed somewhere in the API docs? On Feb 22, 2010, at 9:42 AM, Ryan Alford wrote: Yes, those are the ones I am talking about. ...
Re: [twitter-dev] Introduce yourself!
hi, my name is isaiah ( @isaiah ). i'm a indie Mac/iPhone developer. my latest creation is Kiwi, a Mac Twitter client: http://kiwi-app.net/ i do lots of other fun stuff too: open source OAuth stuff: http://github.com/yourhead website layout tools: http://yourhead.com/ i tried to figure out when i started using twitter and the twitter api, but i'm not certain. more than a couple years, i'd guess. i joined this list to post about the challenges of the OAuth user experience on the desktop. and that's what the vast majority of my posts have been about. i'm very excited about xauth, i think it's going to be huge. i just wish that @twitterapi would switch it on, already. ;-) if Twitter would grant me one API wish it would be: a switch that worked on every API command that would enable extremely verbose output, error messages with detailed reasons for the error, and rate-limit details. i'd love to see which rate limit i was bumping into, what OAuth parameter i've screwed up, and exactly which parts of my request were not URL encoded correctly. i'll definitely be at chirp. you'll be able to find me at the after-party, i'll be the guy in the corner wearing a black t-shirt who's had one too many beers. you can count on it. isaiah http://twitter.com/isaiah
Re: [twitter-dev] Re: What's up with OAuth?
so excited about xAuth. i think this is really going to change the landscape in a big way. can't wait to get going. sent a message to a...@twitter.com -- that's all that's necessary to get going right? thanks again, isaiah On Feb 12, 2010, at 9:04 AM, tsmango wrote: Yep, I meant mobile native applications. This is really a wonderful idea! Very, very happy about this! On Feb 12, 11:15 am, Raffi Krikorian ra...@twitter.com wrote: if, of course, you mean a mobile native application, and not a mobile web application. mobile web applications still need to send their users through the regular oauth workflow. On Fri, Feb 12, 2010 at 8:15 AM, Raffi Krikorian ra...@twitter.com wrote: yup! that's the plan. sorry if it wasn't clear in the e-mail blast. On Fri, Feb 12, 2010 at 6:14 AM, tsmango tsma...@gmail.com wrote: Just to clarify, xauth will be available to mobile applications (who apply) going forward to authenticate users, not just a one time way to exchange stored usernames and passwords? On Feb 11, 10:18 pm, Raffi Krikorian ra...@twitter.com wrote: hi all. this is a long overdue e-mail, but i wanted to tease out some of the directions that Twitter is going with OAuth. i want to touch upon four topics: delegation, OAuth WRAP/2.0, username/password OAuth token exchange, and basic authentication deprecation. *DELEGATION - OAuth Echo* twitter users love posting media on third-party sites, and delegation in identity verification is one of the major hurdles for an OAuth-enabled twitter client to succeed. i started a series of blog posts around the following problem: You're an OAuth enabled Twitter client, and you've already authorized your user. Your user wants to use a media providing service like TwitPic. TwitPic, currently, asks for the username and password of your user so it can store the photo on behalf of the Twitter user. You don't have that username and password, so how do you give the ability to TwitPic to verify the identity of your user? check out the proposal for what we're calling OAuth Echo athttp:// mehack.com/OAuth-echo-delegation-in-identity-verificatio. please feel free to comment there, or on the twitter development talk mailing listhttp://groups.google.com/group/twitter-development-talk(or, even just reach out to me directly). i think this experiment in engaging the community around designing this security/identity workflow has been definitely a success, and i feel we're rapidly converging on a solution for identity verification delegation. in parallel, we're going to start the process to engage our media providers in the conversation as well, and we're hopeful we can move this forward quickly. *OAUTH WRAP/2.0* OAuth is evolving, and we at Twitter are keeping up with it. that being said, we're keeping our eyes on OAuth WRAP and OAuth 2.0http://wiki.oauth.net/OAuth-WRAP. we like a lot about it: - it requires the use of SSL; - there is no custom signing mechanism -- you simply pass us a token, and that token is secured by SSL; and - it formalizes a bunch of profiles that we've been actively thinking about (e.g. a username/password exchange) in general, we really like WRAP/2.0 because it's just *so* easy to implement from the client side. there are no longer questions around creating the proper signature base string, etc. we're sure that developers will like it as well. we've started work on an internal implementation of OAuth WRAP and we envision that we'll simultaneously support both OAuth 1.0a and WRAP/2.0 for a while. our hope is to get WRAP out the door soon (and before we finally deprecate basic authentication). *USERNAME/PASSWORD TO OAUTH TOKEN EXCHANGE - xAuth* @rsarver and @noradio announced that we are going to support a mechanism where a username and a password can be directly exchanged for an OAuth token and secret -- we're calling this xAuth. if you've been watching the mailing list, Seesmic Look http://seesmic.com/look has been a beta partner in testing xAuth exchange (and @abraham has already detailed how it works http://the.hackerconundrum.com/2010/02/sneak-peek-at-twitters-browser.. .). because we're moving everybody off basic authentication, we originally envisioned this as a mechanism for developers to exchange all the username and passwords they have in their databases for OAuth tokens en masse. that's still one of our use cases. another use case is around environments where software can't bring up a web browser (e.g. set top boxes, game consoles, embedded devices). we want to support those as well. you're going to have to apply to get access to this exchange mechanism (by sending e-mail to a...@twitter.com), but, in general, all applications except web applications will get access. we feel that the xAuth exchange allows for the best mix of security and user experience for desktop and possibly
Re: [twitter-dev] Re: Seesmic Look and the Source parameter
I check this topic about 10 times a day hoping for an update. To say I'm excited about this, doesn't really come close. I have my code prepped and ready for whenever this lands. But I think we can all wait Raffi to get better. Health trumps all things. And rightly so. @raffi Take it easy. Get better man. We can wait. isaiah http://twitter.com/isaiah On Feb 9, 2010, at 9:42 AM, Ryan Sarver wrote: Raffi, has walking pneumonia so we're giving him a few days slack time and we're afraid of what he would write while on meds :) On Tue, Feb 9, 2010 at 8:48 AM, Raffi Krikorian ra...@twitter.com wrote: in progress :P On Tue, Feb 9, 2010 at 12:18 AM, mynetx myne...@googlemail.com wrote: And where’s the announced post by Raffi? http://groups.google.com/group/twitter-development-talk/msg/56cd59f6d5a57db9 On Feb 8, 6:39 pm, Dewald Pretorius dpr...@gmail.com wrote: The info you're looking for is in this thread: http://groups.google.com/group/twitter-development-talk/browse_thread... On Feb 8, 2:45 am, mynetx myne...@googlemail.com wrote: How can Seesmic Look display its Source in the tweet metadata, when it asks for my user name and password? It would be interesting to know how Seesmic Look gets the Twitter API to return an OAuth Access Token and its secret from a user name / password API request input. Look is connecting to Twitter via the Dimebrain TweetSharp Library for C#, but as Seesmic's class is using obfuscated .NET IL code, I have not yet found out. Any insight appreciated. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: Source parameter request for mobile Twitter app ignored (and issues with Twitter's policy toward oAuth on mobile/desktop)
How so? What do you think will be the significance of chirp for desktop OAuth? Was there an announcement that I missed? isaiah http://twitter.com/isaiah On Feb 2, 2010, at 10:30 AM, M. Edward (Ed) Borasky wrote: Actually, we'll know the answers at Chirp or before. Chirp is the watershed for Twitter and the developer ecosystem. Time as we know it will be reckoned B.C. (Before Chirp) and A.D. (After Disclosures). ;-) On Tue, Feb 2, 2010 at 9:16 AM, Isaiah Carew isa...@me.com wrote: Leveling the playing field is elephant in the room easy: Immediately ignore the source parameter on all Basic Auth calls. Right now. It's a 5-second coding job. Twitter has announced plans (see @ev's announcement in Dec.) to do almost exactly that come June. Not quite instant gratification, but June is sooner than you think. But two big questions remain: 1. Will Twitter add OAuth additions that allow for alternative credential exchange? (in plain English: username/password on desktop) Raffi has hinted at this previously (source: details ), but few details have emerged. 2. Will Twitter overlook less-than-perfect implementations that improve UX? (i.e. screen scraping the PIN, internal browsers, etc.) So far these practices seem to be flying under the radar in a few clients, but will that change when the big guys enter the game? We'll know the answers in June. It should be fun to watch and make for some lively forum threads. Bring popcorn and stand clear of the flames. ;-) isaiah http://twitter.com/isaiah -- M. Edward (Ed) Borasky http://borasky-research.net I've always regarded nature as the clothing of God. ~Alan Hovhaness
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
Ironically all of these massive threads talking about impersonating applications is probably just making more crackers aware that they can do this. :-/ You're right! Openness about security is really going to hurt us all! Everyone, quick, sh! The bad guys are stupid and will never figure it out if we just keep quiet! OK, sorry, I couldn't resist the bait. ;-) Especially coming from someone that I know appreciates openness. No, I don't actually feel that way. I do actually see your point, but I think the value of discussing threats, so long as the discussions remain unspecific, are probably more valuable than they are detrimental. Also, I think you have it right, that distribution of the source sans keys and the binary with keys is the way to go. I completely agree that it's the obvious practical solution. It's the one that took myself for my OSS OAuth code. However, it also misses the point. The point is that the keys not kept safe in any desktop app, and the challenges are double in open source apps. Up until this point they've probably been safe enough because there have been few targets worth the effort of cracking. I suspect that will change when the clients with many users enter the picture. With many more users there are many more reasons why someone might want to spoof as a specific client. I'd say its a pretty reasonable bet that one of the major desktop clients will be compromised within a year or so of implementing OAuth -- and will probably result in a lot of user frustration. It seems like their will be ample motivation and little to prevent them. Only time will tell, you're free to come and laugh at me if it doesn't happen. Bookmark this email, we'll check back in 18 months. ;-) Isaiah
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
So, in simple language: Twitter's policy is that every user of every open source client register as a new twitter application? Or, have I misinterpreted something? And if so, could you explain further what mean? Thanks, Isaiah what i would do is just make it clear to people who are using your open source client that they need to register their downloaded application with Twitter -- send them to http://twitter.com/apps/new, instruct them to fill out the form, and build a simple wizard that they can cut and paste the consumer token and secret into. isaiah http://twitter.com/isaiah On Jan 30, 2010, at 11:22 AM, Raffi Krikorian wrote: what i would do is just make it clear to people who are using your open source client that they need to register their downloaded application with Twitter -- send them to http://twitter.com/apps/new, instruct them to fill out the form, and build a simple wizard that they can cut and paste the consumer token and secret into. On Sat, Jan 30, 2010 at 12:29 AM, ShellEx Well 5h3l...@gmail.com wrote: Some project (like dabr) put key and secret in config files. But I think it really suck for users who want to use my client with OAuth. Because they have to get a pair of key/secret and do configure themselves, and the this is not convenience for users. So I doubt that is it a good way to use OAuth in Desktop Client. On Jan 30, 1:35 am, Raffi Krikorian ra...@twitter.com wrote: the leak of a consumer secret will not result in the compromising of user accounts (the consumer secret is needed to get user secrets, but to get user secrets require the user's intervention). however - do not put the consumer key and secret in the source of your code and distribute it. instead, make it possible for your source to read the consumer key and secret from a configuration, and distribute, with your source code, a sample configuration file or a README that details how to create one. hope that helps. On Fri, Jan 29, 2010 at 7:57 AM, ShellEx Well 5h3l...@gmail.com wrote: if a twitter App's Consumer key and secret were leak out, is it possible to gain a user's access token without a user authentication process ? I am writing a opensource desktop client and has implemented OAuth for it. However, I don't know is it suitable to put my key and secret in the source? Are there any risks if i do that? Thx :) -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] OAuth best practice
Although you can find many instances of popular applications that do exactly this, and the precise reasons for it being verboten are definitely arguable and murky at best, the reaction that you'll receive from the OAuth community is likely to be crystal clear, and very negative. I posted an open source app that did this and received this from a founding member of the OAuth committee: ...this approach is specifically one that OAuth is trying to protect users from. The problem is that your app does not (and can not) give users any trust that you (or more importantly, an attacker) are not storing their Twitter credentials without informing them... My personal feelings about the veracity of this statement aside, the tone is pretty clear: you shouldn't do this. isaiah http://twitter.com/isaiah On Jan 17, 2010, at 8:50 AM, eco_bach wrote: I'd like to embed the Twitter OAuth authorization-sign in window WITHIN my application. Is this considered a best practice, or is it always recommended to send the user to a new browser window for the service provider(Twitter in this case) OAuth authentication process?
Re: [twitter-dev] Reinstate 'from app' for Basic Auth desktop apps until OAuth is fixed
The OAuth discussion and call for uses cases has been asked for before by the API team. Specifically 11 months ago by Alex. Here's the link to that discussion: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/629b03475a3d78a1/655a8425e1e5e045?show_docid=655a8425e1e5e045 It's a good thread that deserves reading as it has contributions from Loren, Blaine, Chris Messina, and Alex. It's pretty much the who's who of desktop/auth/twitter-api. Many of the things that people have put in this thread are some of the same things that were discussed then. Also note that Alex specifically asked for the the community to set up a Wiki about this topic to collect feedback: http://groups.google.com/group/twitter-development-talk/msg/afda4fdf52f78fe3?dmode=source Loren did that and here it is: http://twitter.pbworks.com/oauth-desktop-discussion Just thought I'd post it to this discussion in case someone forgot. isaiah http://twitter.com/isaiah On Jan 11, 2010, at 11:01 PM, Raffi Krikorian wrote: As it stands, developers who have relatively new desktop apps are penalized by having updates from their app say 'from web'. Older Basic Auth desktop clients continue to enjoy a link back to the client web site with a 'from app' link. ... I understand Twitter is trying to force people to use OAuth, but that won't happen in a meaningful way until OAuth is reliable, has a truly usable workflow (PIN method isn't it), and can work well with other services (Twitpic, yfrog, etc). We aren't there yet. i'm trying to gather use cases around OAuth to help it make sense for more people to use it -- as it stands, we are not going to allow the source parameter to be set in new applications unless they come from OAuth. so, please help me out! is the reliability of OAuth an actual concern? do you have a suggestion as to what you would like to see other than the PIN workflow? additionally, we're actively working on a delegation method for integration with other services. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] oAuth new stuff?
i think i've failed to connect and instead i've offended you. i'm sorry, it wasn't my intention. i feel there is a lack of user education going on to explain to users why oauth is actually better for the use i'm just not sure how this is pertinent to anything i wrote. as i said, i want to use oAuth -- i think we all do. you're preaching to the converted. :-) additionally, i understand that simply putting up a dialog box with two text input fields is easier to code than writing software that manipulates a browser, and that is why a lot of applications do that. as i said, i've already gone through the trouble of releasing an open source implementation of oAuth for Mac OS X -- so your hyperbole kind of misses the mark. myself and others have already done the hard work and released open source to help make it easier for the rest to come along. i don't think it's the required effort that is preventing desktop apps from migrating -- it's just the user experience. let me start again. i wanted to show that the current oAuth flow for desktop apps is preventing many desktop apps from moving to oAuth. i did this because your offhand I don't know, response seemed to indicate that the announced changes were not getting much priority in the api. i wanted to help you see the importance of these changes for desktop clients. i'm really excited about the changes. i'm dying to start working on them. i'm committed to releasing an open source solution to them as soon as they come out. i hope you're as excited as i am. if it's unclear on exactly which changes i'm talking about. it's the ones that you mentioned in this post: http://groups.google.com/group/twitter-development-talk/msg/18b38db599f6ad98?hl=en thanks, isaiah On Dec 30, 2009, at 5:53 AM, Raffi Krikorian wrote: i understand that you have to tow the line. i agree with it — at least in principle. i like oauth. i understand it. i *want* to put it in my app. aside from my desktop client, i released an open source oAuth solution: http://thurly.net//5nl yet, of the prominent mac clients (tweetie, twitteriffic, socialite, beak, bluebird, kiwi) only one is currently using oAuth. the reasons are painfully obvious and have been discussed here and elsewhere ad nauseum: http://groups.google.com/group/twitter-development-talk/search?hl=engroup=twitter-development-talkq=oauth+desktopqt_g=Search+this+group honestly, i actually resent the i understand that you have to tow the line statement. i feel there is a lack of user education going on to explain to users why oauth is actually better for the user -- for a list of said reasons, please see http://apiwiki.twitter.com/OAuth+Example+-+Ruby . additionally, i understand that simply putting up a dialog box with two text input fields is easier to code than writing software that manipulates a browser, and that is why a lot of applications do that. as i see it, and having written software against the Twitter APIs (ate our own dogfood), what's missing are the following two things (please add to the list): • when using oauth, a good way to integrate with third party services that also use twitter credentials (yfrog, twitpic, URL shorteners, etc.) -- this is delegation • http://groups.google.com/group/twitter-development-talk/browse_thread/thread/ac563255efcb/951ee32ec9cea3a8?lnk=gstq=delegation#951ee32ec9cea3a8 • http://twitter.com/twitterapi/status/6743938510 • a good workflow for desktop apps -- specifically, desktop applications that have access to a browser. i am -not- talking about rich environments that do not have access to a general purpose browser (set top boxes, game consoles, etc.) what i would rather see, and what i'm interested in fixing, are those two. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Ambiguity with 401 error response code
Are there other error conditions that are similarly ganged up into 401? Or are these two the complete list? Are there other codes that have similarly ganged up error conditions that can only be distinguished by the response text? Are the expected responses (not just the codes) for different conditions documented somewhere? Also, off topic: Any news on when we can expect the new oAuth with username/password flow to make its way into the API? If you can't let me know, or you don't know, I understand, but it would be good to hear whatever the case. Thanks, Isaiah On Dec 29, 2009, at 9:45 AM, Raffi Krikorian wrote: hi eric. yup - you've hit it right on the head. one of the main initiatives in us starting to version our API is so that we can really consolidate and make our error codes consistent. unfortunately, for legacy compatibility reasons, we can't change the second case to have a 402 error and we will have to keep it as a 401. what you could do is parse the response that comes back in the 401, however. in the case that your password is wrong, the error should be Could not authenticate you. for basic auth and OAuth. the second case has an error of Not authorized On Mon, Dec 28, 2009 at 3:38 PM, Eric Marcoullier @ Gnip e...@marcoullier.com wrote: We're trying to build some logic into our data collector and we've been fighting with an issue for a while involving the 401 Unauthorized error code. There are two instances where I can get this response 1) Bad credentials. I try to log in with an invalid username or password. 2) I don't have access to a specific user's private account. The former can be a real problem for a user. I changed my password a few weeks ago and forgot that I was using it for whitelisted REST API access. Querying three times in rapid succession with a bad password causes a temporary lockdown of a user's account. I was querying once per second and locked the account for a five days. This is an account- level issue and the proper way to deal with this from our perspective is to immediately sleep the poller for 30 minutes and send an alert about bad credentials. This is completely different than if someone I'm following has taken their account private. In this case, sleeping for 30 minutes (or any amount of time, really) is overkill. Unless I'm querying for a single person over and over, there's no reason to pause before moving onto the next rule that I'm querying for. Unfortunately, we have no way to disambiguate between the two 401s and we're forced to either lock someone's account (ignoring 401s) or severely reduce their polling efficiency (acting on 401s). Best case would be to break these two error conditions out into separate error codes. Perhaps a 401 for bad credentials and a 402 for lack of authorization for a specific piece of content. Please let know if I've overlooked something that would help me disambiguate the use cases in the current system. Thanks! Eric -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
[twitter-dev] oAuth new stuff?
and how 'bout that off topic question? a non-silent-treatment sort of answer would be really great -- even if it's i can't tell you or i don't know or that's on a need to know basis and you don't need to know. or you want the truth, you can't handle the truth! or whatever. my biggest concern is that it won't come before the deprecation of oAuth -- and I'll have to implement a pin bases solution in the interim, then rip that out, then implement the new flow if/when it's finally included in the twitter api. if that's the case, then i'm going to need to budget some more $$ for this effort. i'm just looking at what sort of effort and money i'm going to have to spend on this in the next six months. thanks, isaiah On Dec 29, 2009, at 1:06 PM, Raffi Krikorian wrote: Also, off topic: Any news on when we can expect the new oAuth with username/password flow to make its way into the API? If you can't let me know, or you don't know, I understand, but it would be good to hear whatever the case. Thanks, Isaiah
Re: [twitter-dev] oAuth new stuff?
bummer. i don't mean to be rude, but it sure feels like there is a large gap between the PR announcement a couple weeks ago and the reality on the ground. i'm trying to be patient in letting the info trickle down. i guess i'll ask again in a couple weeks? twiddling thumbs waiting hmmm hmm hmmm until then, my app is limping along with basic auth without attribution. isaiah On Dec 29, 2009, at 1:30 PM, Raffi Krikorian wrote: i don't know. sorry that i forgot to address your question. On Tue, Dec 29, 2009 at 1:18 PM, Isaiah Carew isa...@mac.com wrote: and how 'bout that off topic question? a non-silent-treatment sort of answer would be really great -- even if it's i can't tell you or i don't know or that's on a need to know basis and you don't need to know. or you want the truth, you can't handle the truth! or whatever. my biggest concern is that it won't come before the deprecation of oAuth -- and I'll have to implement a pin bases solution in the interim, then rip that out, then implement the new flow if/when it's finally included in the twitter api. if that's the case, then i'm going to need to budget some more $$ for this effort. i'm just looking at what sort of effort and money i'm going to have to spend on this in the next six months. thanks, isaiah On Dec 29, 2009, at 1:06 PM, Raffi Krikorian wrote: Also, off topic: Any news on when we can expect the new oAuth with username/password flow to make its way into the API? If you can't let me know, or you don't know, I understand, but it would be good to hear whatever the case. Thanks, Isaiah -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
[twitter-dev] Announcements
From the announcement I read here: http://www.techcrunch.com/2009/12/09/twitter-le-web-2009/ 3) Anyone making OAuth requests to Twitter is soon getting an increased rate limit (10x) – about to launch API for browser-less apps, and starting Basic Auth decprecation in June 2010. Is there more info about this available. I'd love to know more about the API for browser-less apps -- specifically: 1) Will this be appropriate for desktop clients? 2) When? Thanks, isaiah http://twitter.com/isaiah
[twitter-dev] Re: Use Twitter for login oauth/authenticate method
I'm still not sure I understand the option. Is there any reason why someone would choose NOT to check this box currently? Also, if you are in the process of redesigning the auth page, could I make a request: Could there be a super-lightweight version for mobile? No images, no scripts, inline css, fluid width, etc. Maybe it already exists and I'm doing something wrong. Feel free to point me in the right direction too. ;-) Isaiah On Jul 1, 2009, at 7:50 AM, Matt Sanford wrote: Hi Arnaud, That option during application creation is really more trouble that it is worth. Right now applications that have that option checked include an extra sentence to tell users the application will be using twitter for login, that's all. In the future we may restrict the /oauth/authenticate call to applications that have specifically chosen the option, so I recommend that any application using 'Sing in with Twitter' check the check box. We're also working on redesigning the authorization page and might do more with that value then. We will announce before hand if we make any changes, like requiring that value to use the authenticate method. It's not something we'll definitely do but it is something that may come up in the medium term you should be aware of. Thanks; – Matt Sanford / @mzsanford Twitter Dev On Jul 1, 2009, at 4:26 AM, Arnaud wrote: Hello, I’m using the oauth/authenticate method (one click login) and I was wondering if I had to check the Use Twitter for login option in my application options. The application is Browser based (using a callback URL) . I’m quite confused with this option as I don’t really understand what it is standing for? All the best, Arnaud.
[twitter-dev] Re: off topic
yep, just me, thanks, isaiah p.s. subject changed to protect the on-topic folks. @isaiah for more. ;-) On Jul 1, 2009, at 12:27 PM, Neil Ellis wrote: On a completely separate note, your website is stunning, did you design it yourself? If not may I ask who were your designers. All the best Neil http://www.peepwl.com On 1 Jul 2009, at 20:22, Support wrote: Matt, Thanks for weighing in and hopefully taming this snarl. As the person who might have posed the question originally, I figured I at least owed a bit of constructive critique. What can we change about OAuth that would make this better? 1) User experience - it's been echoed a number of times in this board, so i won't beat the dead horse... much...but basic auth *is* much simpler for the user. The reason is obvious: oauth requires a browser. In many platforms (especially mobile) that's a painful burden. The PIN code seems to be ignoring the elephant in the room. It solves some problems, but at a further cost to the user experience, giving an even larger advantage to existing basic-auth apps. You've made the pill even more effective, but so bitter that your patients can't swallow it. Providing a scheme that does not require a browser is an obvious way to cut this gordian knot. 2) Application authentication - if your goal is to *identify* each open source application in a *trusted* way, then I think you could be in for an uphill battle. There are obvious technical challenges, however the larger problem is that in OSS there is no way to define each application. There will be many binaries for different platforms and people will fork it on github just because they can. You cannot identify each of these variants as the same when they could be different. And that places a burden on the user experience. When a user grants access to application x -- what does that mean exactly? Just that binary? Just this release? Only from a specific trusted company? How do you explain to the user where this subtle line is drawn in a box he'll click through in less than a second? I personally don't see an obvious solution to this problem. It seems to be a UI challenge and a technical challenge. In cases like that it seems prudent to question your goals and check feasibility. Isaiah YourHead Software supp...@yourhead.com http://www.yourhead.com On Jul 1, 2009, at 9:46 AM, Matt Sanford wrote: Hello again, I do not recommend having individual end users register for consumer keys/secrets [1] under any circumstances. So, with that out of the way, let us focus the discussion a bit more. What can we change about OAuth that would make this better? A complete technical [2][3] discussion on what we could add that would make this better is welcomed. More than welcome, it's pretty much required before we can help. The PIN flow was the first addition to address the inherent insecurity of the consumer key/secret all desktop applications [3]. This stopped applications from being able to collect tokens by using the consumer key/secret and a confidence scam (phishing like GoodApp needs you to re-approve us). It sounds like there is a fervent need for something more … what do people suggest? We're working hard on the problem but many of you are working from the consumer standpoint and probably have great feedback. Please, take your time and write a well thought out reply. One- line snarky comments, while fun to write and sometimes to read, steal time from everyone reading the list, including all of the Twitter API engineers. They also make the list look less inviting to new comers. Thanks; – Matt Sanford / @mzsanford Twitter Dev [1] - People installing an instance of your server-side app are not 'end users', but other developers [2] - Not open-source hand waving. [3] - Closed source desktop apps have the same problem. Reverse engineering is not stopped when you don't include the source. On Jul 1, 2009, at 9:33 AM, DWRoelands wrote: Actually, since Twitter has said that Basic Auth will eventually go away, OAuth is going to be the only choice for authentication. Twitter has forced the choice by implementing OAuth in the way that they did. Why should a user who chooses to support open source by using an open- source Twitter client be punished by having to go through extra hoops that users of closed-source clients don't have to endure? Forcing users of open source Twitter clients to register their individual installations as Twitter applications is not a viable solution. Matt Sanford has even said so. No one is asking for easy. I just want open source Twitter desktop clients to be able to compete with closed-source versions when it comes to security. Right now, that's not possible because of Twitter's implementation of OAuth. Regards, Duane On Jul 1, 11:23 am, Andrew Badera and...@badera.us wrote: But that's the
