[twitter-dev] Streaming API and Oauth
The Oauth Overview page http://dev.twitter.com/pages/auth_overview has sections for three APIs: REST, Search, and Streaming. The bottom of the page displays a ribbon stating that The @twitterapi team will be shutting of basic authentication for the Twitter API. Does this mean all of the Twitter APIs (REST, Search, and Streaming)? or just the REST API? Most specifically, while I know that the Streaming API end-point now supports OAuth, I do not know if Streaming will require OAuth come August 16th... can someone please clarify. TIA.
[twitter-dev] How can I search Twitter for tweets containing an exact phrase
I need to search Twitter for tweets containing the phrase $T (T being the trading symbol for ATT). When I perform a search for this, I get back oodles of results where $t is not a complete phrase, but the characters in some larger phrase, which isn't what I want. Alas, $t is quite common in 1337 (leet) phraseology. The Web interface for search.twitter.com advanced offers an entry for This exact phrase but I can't get that to work. I have tried specifying spaces on either side of the $t text, as in: http://search.twitter.com/search?phrase=%20%24t%20 But the search engine ignores the spaces and returns non-exact phrase matches. Is there any way to inform the search engine that I want exact-exact matches, or whole-word matches?
[twitter-dev] Re: Retrieving older tweets from less-active accounts
On Jun 14, 5:04 pm, Matt Harris mhar...@twitter.com wrote: Search only includes Tweets for the last ~7 days. This makes sense with what I'm experiencing... but then I wonder: Why does the Web interface for search.twitter.com/advanced have controls to input a Since this date date? btw: my question regards searching for a term, not a source. Also: is it possible to use some API query to search for older tweets?
[twitter-dev] Re: parsing out entities from tweets (a.k.a. parsing out hashtags is hard!)
+1 for it being optional as well -- keep the bandwidth to a minimum for scenarios where it's not needed. +1 for having short URLs' original (long) URL provided (perhaps also an option?)
[twitter-dev] Re: How to set 'source' when update status
On May 2, 6:00 pm, Ernandes Jr. ernan...@gmail.com wrote: Please, read this:http://dev.twitter.com/pages/api_faq#attribution The referenced text recommends the use of OAuth (We now recommend developers use OAuth...) I suggest that someone from the Twitter doc team revise the faq to correlate with the soon required use of OAuth.
[twitter-dev] What is the correct OAuth API endpoint
What is the correct API end-point for OAuth authenticated, *documented* API calls? http(s)://twitter.com http(s)://api.twitter.com http(s)://api.twitter.com/1
[twitter-dev] Authorize page for desk-top apps
When I invoke the authorize URL with a oauth_token, the Allow/Deny page comes up. My app is a desk-top app, not a Web site. Most of the text seems to reflect this, except on the right side, where it says: Twitter takes your privacy very seriously. Please ensure that you trust this website with your information before proceeding! I think that second line should refer to app not website. Twitter folks: Is this something that can be tweaked for apps?
[twitter-dev] Re: Introduce yourself!
Hey fellow Twitter developers, I'm Stuart Malin (@zhami). I'm developing a Mac/Cocoa desk-top app for interacting with Twitter. I've been working on it for a year now (slow pace of development). It has a unique (and rather cool, if I may say so) U/X, unlike anything out there. I am presently adapting the app for OAuth, which is starting to fall into place. I am registered for Chirp, and hope to meet some of you there. Presently I live in southeast Florida, but have called the Bay Area home for years, and so will enjoy a visit to SF. The one feature request that stands out for me now would be to have the ability to attach a single line of meta-data to a status update, and to for there to be a managed namespace for using this meta data field. Then we app/Web developers could populate that field with interesting items and we could parse for those that we want to adopt into our individual apps/Web sites. --Stu/art
[twitter-dev] Re: oauth request token failing
On Feb 17, 10:47 pm, Ryan Alford ryanalford...@gmail.com wrote: You order all parameters EXCEPT the signature, then create the signature, then append the signature to the end. All other parameters should be in order. I am under the impression that sorting is only required to generate the Signature Base String. I haven't seen anything in the OAuth spec to suggest that Query parameters must be ordered. If I have missed something, lease let me know where. I also believe that ordering is *not* required in the Authorization header because the example shown in the spec is not ordered [1] [1] OAuth Core 1.0a section 5.4.1 Authorization Header; http://oauth.net/core/1.0a/#auth_header
[twitter-dev] Re: OAuth wed desktop feedback
As a a software and Web site user, I consider my desktop apps mine and Web sites theirs. I am sure that this is the mindset of most people. We visit Web sites, and we give information to them. Yes, they do things for us in return. Even when providing SaaS, I am still on their site. On the other hand, when I use a desktop app, I am using my software on my computer and it is likely that I have other desktop apps to which I have given passwords and keys. In fact, I may even have my Browser remember passwords for Web sites I frequent as well as keep other personal information. As a consequence of this distinction, while I consider OAuth a fine architecture in the context of Web workflow, it is (presently) not optimally suited for the desktop experience. As a user, I control my apps (well, presuming they are not malicious), and can turn them off or uninstall them at my discretion. A Web site is (very) different in that I have no real authority over it. btw: I think it is quite important to realize just how atypical/novel Twitter is in assessing the needs of a desktop solution: Twitter isn't really a Web site (though it has a Web site) -- Twitter is a messaging infrastructure, and client apps are end-points. In this regard, think of it more like email. The UX I want for users of my app is what I want when they use an email client: they'll use a Preferences/Wizard approach to add account (s), and thereafter the app provides functionality. Although users have the option of visiting Twitter's Web site to interact with Twitter, it is my goal (as I suspect it is for most clients), to over time obviate the need for users to go there. In this context, I see the needs for a desktop solution as: 1) don't ever send the user's password in the clear over an unencrypted transaction, even if obfuscated (e.g., Base64). 2) in spite of #1, don't require use of SSL/TLS for every transaction (that requires user authentication). 3) client apps should be uniquely identified, and Twitter should have the control to withdraw a client's access to Twitter's service. 4) empower a user to terminate an issued token (whether because the app turns out to be malicious, or because the token has been compromised). On Oct 12, 10:02 pm, JDG ghil...@gmail.com wrote: But it completely subverts the point of OAuth, because it lets a third party have your password. Why even use OAuth in that case? On Mon, Oct 12, 2009 at 19:01, Zhami stu...@zhameesha.com wrote: On Oct 12, 5:44 pm, Sebastian sdelm...@gmail.com wrote: The solution for OAuth on Mobile and Desktop is easy: snip Let me rewrite this in plain english: let the app ask for login/ password and pass it to twitter. snip All we need is a simple API call where we can trade a login and password for an oauth access token, bypassing the browser. I think this is a grand idea, and wanted to acknowledge it. This solution removes the password from being bandied about endlessly with Basic Auth, but is appropriate for the world of desktop apps where users are comfortable providing their password because applications often ask for access restricted information. -- Internets. Serious business.
[twitter-dev] Re: OAuth wed desktop feedback
On Oct 12, 5:44 pm, Sebastian sdelm...@gmail.com wrote: The solution for OAuth on Mobile and Desktop is easy: snip Let me rewrite this in plain english: let the app ask for login/ password and pass it to twitter. snip All we need is a simple API call where we can trade a login and password for an oauth access token, bypassing the browser. I think this is a grand idea, and wanted to acknowledge it. This solution removes the password from being bandied about endlessly with Basic Auth, but is appropriate for the world of desktop apps where users are comfortable providing their password because applications often ask for access restricted information.
