[twitter-dev] Site Streams: Work Locally / 401 Unauthorized From EC2 (/cc @jkalucki)
I've been working on a site stream implementation for the past week or so from my local environment without any issues. However, I just setup a new EC2 instance this morning and I'm unable to connect from it (I receive 401 Unauthorized). I've tried a few attempts over the course of several hours. I'm using @frflyapp and I've tried both my development oauth app and my production oauth app (both of which work locally) with the same result. My last failed attempt was at: Tue Oct 12 20:08:17 + 2010 I received the following response: HTTP/1.1 401 Unauthorized WWW-Authenticate: Basic realm=Firehose Cache-Control: must-revalidate,no-cache,no-store Content-Type: text/html; charset=iso-8859-1 Content-Length: 1286 Server: Jetty(6.1.25) My EC2 instance is at: stream1.frf.ly 174.129.10.194 With the default security group on EC2, I don't think it's possible to ping the instance and I'm not sure if that's related or not. Thanks, in advance, for any help you can provide. -- Thomas Mango tsma...@gmail.com -- 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-dev] Re: Search Twitter replies
When #newtwitter was launched, this was added. The API method isn't documented yet so they're saying it could change, but the the method is: GET /1/related_results/show/:id - also worth noting the authenticated user must have access to #newtwitter. Checkin here for more details: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/cdc34ae78a2350b8 On Sep 29, 7:21 am, jparicka jpari...@gmail.com wrote: Hi there, Quick question - is it possible to search for replies for a tweet id? Why not? Thanks, Jan -- Thomas Mango tsma...@gmail.com -- 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-dev] Re: Site Streams - Unfollow Events?
Hey, John. There are a few reasons I'm interested in unfollow events in Site Streams, but Tim got to the real point: it would make it extremely easy to keep the relationship info up to date. * My service shows you the latest tweet, matching specific criteria, from each person you follow. Currently, unless I manually check the REST API every so often, I wouldn't know to stop showing you a tweet from someone you stopped following. With unfollow events in the Site Stream, this would be trivial and wouldn't require me to run a background process against the REST API. * I have a system in place to retrieve the relationship information between two people using my service. This currently hits the REST API to check whether or not you're following that requested person. I then cache that relationship information to my database and expire it after a certain amount of time. With only access to the REST API, there's always a chance my cache is out of date. Site Streams already deliver the full list of people being followed by each person the stream follows in addition to new follow events. Unfortunately, this isn't enough for me to stop using the REST API and expiring relationship details from my cache. I could keep the cache semi-updated based on new follow events, but I'd still need to expire that information and fallback to the REST API after some time. If Site Streams delivered unfollow events, there wouldn't be any need to fallback on the REST API because I'd have the full list of people being followed when the stream was opened and then each follow and unfollow event thereafter. My local cache would always be up to date and I wouldn't need to hit the REST API or expire any details locally. * Although I currently use a messaging type architecture for the main part of my service, there are certain features I'd like to implement that would require joining across a friendships table to find all tweets, matching specific criteria, by everyone being followed by the current user (I can't use my messaging tables because those only contain information for you after you start using the service and would prevent you from seeing any older tweets we already have matching that criteria). Manually keeping a user's full social graph synced up is wasteful and I've disabled the features in my site that currently require it. However, if Site Streams delivered unfollow events in addition to the list of people being followed by someone at the start of a stream as well as new follow events after the stream was open, keeping the user's social graph updated would be very efficient. For me, getting unfollow events delivered in the Site Stream means I would no longer have to hit the REST API for relationship details. Everything would be up to date and nothing in my cache would have to expire (unless a Site Stream was restarted, in which case I would clear the currently cached relationship details for each user being followed by that stream and set them up again). I hope this clarifies the different situations where I'd find unfollow events useful. Thanks! On Sep 29, 11:42 pm, John Kalucki j...@twitter.com wrote: Please describe your use case for unfollows on Site Streams... -John Kaluckihttp://twitter.com/jkalucki Twitter, Inc. On Wed, Sep 29, 2010 at 5:09 PM, tsmango tsma...@gmail.com wrote: Ah I wasn't able to find that. It's a shame if true. Thanks for the information. On Sep 29, 6:05 pm, Tim Haines tmhai...@gmail.com wrote: Seen this answered about 1 - 2 weeks ago. Answer is no. On Thu, Sep 30, 2010 at 6:23 AM, tsmango tsma...@gmail.com wrote: I was hoping for some clarification on the social events delivered to a Site Stream. The documentation (http://dev.twitter.com/pages/ site_streams) doesn't specifically mention unfollow events and I'm not seeing them. I am seeing follow events, as expected. User Streams, however, are said to support both follow and unfollow events. Are the plans to add unfollow events to Site Streams? Thanks, in advance! - @tsmango By the way, Home Timelines being delivered through Site Streams is really incredible. I can't wait to get this stuff into my production environment. Thanks, again! -- 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 - @tsmango -- 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 - Thomas Mango @tsmango -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via
[twitter-dev] Re: Site Streams - Unfollow Events?
Hi, Ed. Block and unblock events are already being delivered in the Site Stream. Very useful! On Sep 30, 12:30 pm, M. Edward (Ed) Borasky zn...@borasky- research.net wrote: As long as we're wishing, I'd like to get a notification when someone blocks me. ;-) -- M. Edward (Ed) Boraskyhttp://borasky-research.nethttp://twitter.com/znmeb A mathematician is a device for turning coffee into theorems. - Paul Erdos - Thomas Mango @tsmango -- 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-dev] Re: Site Streams - Unfollow Events?
Ah, I apologize. I missed that. I saw block/unblock events come in during my tests, I didn't realize they were directed at the source rather than the target. On Sep 30, 12:59 pm, Mark McBride mmcbr...@twitter.com wrote: Note that block/unblock events are delivered to the person creating or destroying the block (the source of the action), *not* the target of the action. ---Mark http://twitter.com/mccv On Thu, Sep 30, 2010 at 9:31 AM, tsmango tsma...@gmail.com wrote: Hi, Ed. Block and unblock events are already being delivered in the Site Stream. Very useful! On Sep 30, 12:30 pm, M. Edward (Ed) Borasky zn...@borasky- research.net wrote: As long as we're wishing, I'd like to get a notification when someone blocks me. ;-) -- M. Edward (Ed) Boraskyhttp://borasky-research.nethttp://twitter.com/znmeb A mathematician is a device for turning coffee into theorems. - Paul Erdos - Thomas Mango @tsmango -- 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-dev] Site Streams - Unfollow Events?
I was hoping for some clarification on the social events delivered to a Site Stream. The documentation (http://dev.twitter.com/pages/ site_streams) doesn't specifically mention unfollow events and I'm not seeing them. I am seeing follow events, as expected. User Streams, however, are said to support both follow and unfollow events. Are the plans to add unfollow events to Site Streams? Thanks, in advance! - @tsmango By the way, Home Timelines being delivered through Site Streams is really incredible. I can't wait to get this stuff into my production environment. Thanks, again! -- 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-dev] Re: Site Streams - Unfollow Events?
Ah I wasn't able to find that. It's a shame if true. Thanks for the information. On Sep 29, 6:05 pm, Tim Haines tmhai...@gmail.com wrote: Seen this answered about 1 - 2 weeks ago. Answer is no. On Thu, Sep 30, 2010 at 6:23 AM, tsmango tsma...@gmail.com wrote: I was hoping for some clarification on the social events delivered to a Site Stream. The documentation (http://dev.twitter.com/pages/ site_streams) doesn't specifically mention unfollow events and I'm not seeing them. I am seeing follow events, as expected. User Streams, however, are said to support both follow and unfollow events. Are the plans to add unfollow events to Site Streams? Thanks, in advance! - @tsmango By the way, Home Timelines being delivered through Site Streams is really incredible. I can't wait to get this stuff into my production environment. Thanks, again! -- 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 - @tsmango -- 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-dev] Re: is it possible to search replies from a certain status_id?
Unfortunately, there isn't a single API method that allows this. From the FAQ: http://dev.twitter.com/pages/api_faq#replies Q: How do I get all replies to a particular status? A: For now, there's not a great way to do this. We've heard the requests, though, and we'll be providing a solution for it before too long. On Jul 21, 8:15 am, arian arianpasqu...@gmail.com wrote: hi guys, I need monitor replies from certain status. I would like to use search api, but according to search api doc it's impossible. I only ask you to know for sure. for example, I would like to be able ask for search api for replies from a status providing in_reply_to_status_id value. the only way I found is to ask for user timeline and check manually the in_reply_to_status_id attribute. is it the better way? tks in advance Arian
[twitter-dev] Re: Recent Places-related API enhancements more to come...
Just to answer my own question in case others were wondering, what I found was that: If you use geo/reverse_geocode, you can specify the granularity as either 'city' or 'neighborhood'. The default is 'neighborhood'. Places are never returned. The documentation states that this endpoint will deliver generalized results about geography. If you use geo/search, you can specify the granularity as either 'city', 'neighborhood' or 'poi' (not actually documented). The default is 'neighborhood'. The documentation for this method states that this is the preferred method for allowing users to select a place to attach to their tweet. Anyhow, probably should have waited until the geo services were turned back on the other day before posting my questions. Sorry for the trouble and hope the granularity option of poi helps others. On Jun 15, 5:31 pm, tsmango tsma...@gmail.com wrote: I can't really test this right now because geo services are currently disabled, but does this mean that the geo/reverse_geocode and geo/ search api methods both return places in addition to neighborhoods and cities now? I understand they are all technically places but I mean business entities alongside neighborhoods and cities. Are they all mixed together now? If so, is there a way to get either business listings *or* geographic regions? I understand you guys now own GeoAPI so you're probably coming from a similar point of view and I realize that their entities are nested, as in a business is contained within some geographic region, yet both are considered entities. Anyhow, as you said, the documentation is kind of light for geo/search so I'm just a bit confused as to the data that's actually returned. Unfortunately, the application and service I work on has been using geo/reverse_geocode for a while now to attach cities (specifically cities) to tweets that run through our service and we've been planning to submit our app to Apple tomorrow. Thank you very much, in advance. On Jun 14, 7:43 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Developers, Today we're launching some of the functionality around Places that we announced at Chirp. You can read more about the feature here:http://blog.twitter.com/2010/06/twitter-places-more-context-for-your The launch comes with a batch of API enhancements, with a number of further API additions just around the corner (like creating and updating places, obviously a crucial component for many implementors). The documentation in this area is a honestly a bit light at the moment, but we'll be offering some more comprehensive documentation going over suggested use cases, flows, and more in the coming days. What matters most for you: - GET geo/nearby_places is now GET geo/search, with some added functionality. This is a companion to GET geo/reverse_geocode, that's ideal for using in conjunction with a place selection UI. Read all about it at :http://bit.ly/dvNmYB - A query parameter called query lets you do textual matching when trying to find a place - A query parameter called ip lets you do a lookup based on an IP address - You can fine tune results with granularity, accuracy, and the contained_within parameter, which allows you to identify a place_id (matching something like a city), and only search for places within that place. - place tags in XML output, place attribute in JSON output: Tweets that have a place_id associated with them can now contain some additional information not available in the past, including some attributes that further describe the location. Some common place/attributes you might start seeing: - name - street_address - locality - region - phone - postal_code - twitter (a twitter account associated with the place) - cross_streets Attribute key names can be variant. These are just some of the attribute keys you will see, with much more to come. Here's a quick XML representation of a status with a place: status created_atMon Jun 14 23:30:14 + 2010/created_at id16184038366/id textI'm testing out places integrations. Can you hear me Planet Houston? I'm at the Epicenter. (psyche)/text sourceweb/source truncatedfalse/truncated in_reply_to_status_id/in_reply_to_status_id in_reply_to_user_id/in_reply_to_user_id favoritedfalse/favorited in_reply_to_screen_name/in_reply_to_screen_name user id819797/id nameTaylor Singletary/name screen_nameepisod/screen_name locationiPhone: 37.778181,-122.397971/location descriptionReality Technician, Developer Advocate at Twitter, displeased at Planet Houston/description profile_image_urlhttp://a1.twimg.com/profile_images/989643540/zod_normal.jpg /profile_image_url urlhttp://bit.ly/5w7P88/url protectedfalse
[twitter-dev] Re: Recent Places-related API enhancements more to come...
I can't really test this right now because geo services are currently disabled, but does this mean that the geo/reverse_geocode and geo/ search api methods both return places in addition to neighborhoods and cities now? I understand they are all technically places but I mean business entities alongside neighborhoods and cities. Are they all mixed together now? If so, is there a way to get either business listings *or* geographic regions? I understand you guys now own GeoAPI so you're probably coming from a similar point of view and I realize that their entities are nested, as in a business is contained within some geographic region, yet both are considered entities. Anyhow, as you said, the documentation is kind of light for geo/search so I'm just a bit confused as to the data that's actually returned. Unfortunately, the application and service I work on has been using geo/reverse_geocode for a while now to attach cities (specifically cities) to tweets that run through our service and we've been planning to submit our app to Apple tomorrow. Thank you very much, in advance. On Jun 14, 7:43 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Developers, Today we're launching some of the functionality around Places that we announced at Chirp. You can read more about the feature here:http://blog.twitter.com/2010/06/twitter-places-more-context-for-your The launch comes with a batch of API enhancements, with a number of further API additions just around the corner (like creating and updating places, obviously a crucial component for many implementors). The documentation in this area is a honestly a bit light at the moment, but we'll be offering some more comprehensive documentation going over suggested use cases, flows, and more in the coming days. What matters most for you: - GET geo/nearby_places is now GET geo/search, with some added functionality. This is a companion to GET geo/reverse_geocode, that's ideal for using in conjunction with a place selection UI. Read all about it at :http://bit.ly/dvNmYB - A query parameter called query lets you do textual matching when trying to find a place - A query parameter called ip lets you do a lookup based on an IP address - You can fine tune results with granularity, accuracy, and the contained_within parameter, which allows you to identify a place_id (matching something like a city), and only search for places within that place. - place tags in XML output, place attribute in JSON output: Tweets that have a place_id associated with them can now contain some additional information not available in the past, including some attributes that further describe the location. Some common place/attributes you might start seeing: - name - street_address - locality - region - phone - postal_code - twitter (a twitter account associated with the place) - cross_streets Attribute key names can be variant. These are just some of the attribute keys you will see, with much more to come. Here's a quick XML representation of a status with a place: status created_atMon Jun 14 23:30:14 + 2010/created_at id16184038366/id textI'm testing out places integrations. Can you hear me Planet Houston? I'm at the Epicenter. (psyche)/text sourceweb/source truncatedfalse/truncated in_reply_to_status_id/in_reply_to_status_id in_reply_to_user_id/in_reply_to_user_id favoritedfalse/favorited in_reply_to_screen_name/in_reply_to_screen_name user id819797/id nameTaylor Singletary/name screen_nameepisod/screen_name locationiPhone: 37.778181,-122.397971/location descriptionReality Technician, Developer Advocate at Twitter, displeased at Planet Houston/description profile_image_urlhttp://a1.twimg.com/profile_images/989643540/zod_normal.jpg /profile_image_url urlhttp://bit.ly/5w7P88/url protectedfalse/protected followers_count1461/followers_count profile_background_color00/profile_background_color profile_text_color00/profile_text_color profile_link_color731673/profile_link_color profile_sidebar_fill_color007ffe/profile_sidebar_fill_color profile_sidebar_border_colorbb0e79/profile_sidebar_border_color friends_count1420/friends_count created_atWed Mar 07 22:23:19 + 2007/created_at favourites_count254/favourites_count utc_offset-28800/utc_offset time_zonePacific Time (US amp; Canada)/time_zone profile_background_image_urlhttp://a3.twimg.com/profile_background_images/19651315/fiberoptics.jpg /profile_background_image_url profile_background_tiletrue/profile_background_tile notificationsfalse/notifications geo_enabledtrue/geo_enabled verifiedfalse/verified followingfalse/following
[twitter-dev] Passing OAuth Access Key/Secrets between Our Mobile Web Apps?
I'd like to run something past everyone to make sure I'm not missing something obvious that would make what I'm thinking of doing insecure. I'm working on a web application with an iPhone app that goes along with it (we haven't launched yet). Our web application provides an API that the iPhone application uses. Our iPhone application is approved for and successfully using xAuth for signing users in. Once xAuth comes back, the iPhone application only stores the OAuth key/secret pair for the user. Our web application is only using standard OAuth for signing in - it doesn't accept usernames and passwords directly from users. I'd like to offer a simple and secure way for the iPhone application to not only authorize itself with our API, but identify the user making the request. Would it be wrong or insecure for the iPhone application to pass along the access key and access secret for the user on each API call to our web application? This would sufficiently identify the user and, if I'm understanding correctly, wouldn't be able to be used by anyone if intercepted because they wouldn't have our application's consumer key/ secret. Again, I could very well be missing something here in terms of how secure this approach would be, that's why I'm asking first. I appreciate any feedback on this plan. Thank you, in advance. -- Thomas Mango
[twitter-dev] Re: Passing OAuth Access Key/Secrets between Our Mobile Web Apps?
Taylor, Thanks for the quick reply! It will definitely be obvious that the iPhone app and the web application go hand in hand and we will always use the non-xAuth flow in the web application. Otherwise thank you for the suggestion about additionally signing requests coming from the iPhone application. I'll be sure to work that out. Being able to pass the access key/secrets to identify the user will be a huge help. Thanks again! On May 12, 3:26 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: There's really not much concern about this, Thomas, as long as the consumer keys and secrets remain secure and are never transmitted over the wire. The caveat here is just not to surprise your users -- if they distinctly think of the twitter integration in your web application and your mobile application as two separate, distinct things, then they may be a bit surprised when the web application already knows about Twitter and vice-versa. But it would seem in the description you provide below that this is likely not a concern and would best serve your users. As long as you continue using the non-xAuth flow in your web application, you should be on the good side of the law. I would recommend that you implement a signing mechanism of some sort between your iPhone app and your web server as well so that you can be assured that when you receive an access token from outside, it in fact came from your iPhone application and not some other party. Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod On Wed, May 12, 2010 at 12:12 PM, tsmango tsma...@gmail.com wrote: I'd like to run something past everyone to make sure I'm not missing something obvious that would make what I'm thinking of doing insecure. I'm working on a web application with an iPhone app that goes along with it (we haven't launched yet). Our web application provides an API that the iPhone application uses. Our iPhone application is approved for and successfully using xAuth for signing users in. Once xAuth comes back, the iPhone application only stores the OAuth key/secret pair for the user. Our web application is only using standard OAuth for signing in - it doesn't accept usernames and passwords directly from users. I'd like to offer a simple and secure way for the iPhone application to not only authorize itself with our API, but identify the user making the request. Would it be wrong or insecure for the iPhone application to pass along the access key and access secret for the user on each API call to our web application? This would sufficiently identify the user and, if I'm understanding correctly, wouldn't be able to be used by anyone if intercepted because they wouldn't have our application's consumer key/ secret. Again, I could very well be missing something here in terms of how secure this approach would be, that's why I'm asking first. I appreciate any feedback on this plan. Thank you, in advance. -- Thomas Mango
[twitter-dev] Re: Profile Image URL
The problem most people run into is that the image_name part changes if someone uploads a new profile image so if you're pulling that out of some older data, the profile image can break easily. Joe Stump created a great service called http://tweetimag.es to help with this problem. On Mar 15, 11:00 am, Cristian Petroaca cristian.petro...@gmail.com wrote: Hi , As far as I saw , for each user profile , there are 3 types of profile images : url../image_name_bigger.jpg - biggest url../image_name_normal.jpg url/image_name_mini.jpg - smallest Can you tell me if this naming and size convention is written somewhere in the API documetation? I want to use it and I want to know if this is a stable convention , if I can rely on the name of the images and on their sizes from now on. Thanks, Cristian
[twitter-dev] Re: What's up with OAuth?
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 workshttp://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 mobile applications. web applications will simply have to use OAuth as it was designed, and send their users through the web flow. *BASIC AUTHENTICATION DEPRECATION* yup - it's still happening. we're targeting June 2010. everybody, including legacy applications, will have to move over. for those who are building new applications, use OAuth. save yourself the transition time later, and start thinking about it now. for those who have applications already out there, it would be really beneficial to start thinking about a migration path right now and we're here to help. if you need it, please feel free to reach out to us and we'll help you figure out what you need to do. to help entice you over, as you know: - we have increased rate limits on api.twitter.com to those who are using OAuth (350 calls to the REST API per hour -- and increasing towards
[twitter-dev] Re: What's up with OAuth?
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 mobile applications. web applications will simply have to use OAuth as it was designed, and send their users through the web flow
