[twitter-dev] Re: A new permission level
On May 19, 5:11 pm, TheGuru jsort...@gmail.com wrote: I'm not sure I was aware of the fact there were 2 OAuth login flows, web flow versus sign in with Twitter. Same here. Looks like I was using /authorize already though. What are the implications / reasons for using one method over the other? They seem to essentially do the same exact thing / accomplish the same exact goal. Yeah. --- Jef -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
[twitter-dev] Re: consistency and ecosystem opportunities
On Mar 16, 10:56 pm, jwinkle jameswin...@gmail.com wrote: For Facebook...network people together to share pics and relationship status. You could probably make facebook server code OSS...it's the existing network in-place that keeps people there...it was first and it has a brand. Actually the only reason Diaspora is getting any traction at all as a Facebook replacement is that Facebook management consistently act like dickheads. Twitter take note. -- 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: consistency and ecosystem opportunities
I have a set of apps that basically just reproduces the official Twitter user experience, exactly what Twitter says we should not do. However, I add value by running on a platform that Twitter does not support and is unlikely to ever support. I believe this should be allowed and encouraged and would appreciate a statement to that effect. Furthermore, this is probably not the only exception to the don't just reproduce Twitter rule. Please consider that there may be entire areas of innovation that you have not thought of - that's why it's called innovation. -- 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: consistency and ecosystem opportunities
On my Android phone I have both the official Twitter client and Twidroid installed. If they had more or less the same functionailty and useability I would prefer to use the official client. However I only use Twidroid, because Twitter's official app is inferior. I could explain why in detail if anyone is interested, but it's not a subtle matter, it's gross and obvious. Twitter apparently believes that no one should bother making a plain old timeline-displaying client because Twitter's official ones are all you need. And yet even with Twidroid's prior example to copy from, Twitter's official Android client is still unusable. I say this one example shows that the new policy Ryan posted is at best premature. -- 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: consistency and ecosystem opportunities
On Mar 13, 2:23 pm, Raffi Krikorian ra...@twitter.com wrote: if you are building a regular timeline client, we're going to be holding you to a higher bar. That is reasonable. However we have to wonder if Twitter's people will/can be fair in applying this standard to 3rd party clients whose selling point is 'like Twitter's but improved'. I gave Twidroid as an example. Here's another one. The Twitter web interface for direct messages is completely worthless - again I would be happy to dissect it in detail if requested. I have considered deploying my own web interface that is as close as possible to Twitter's except with a working DM UI. -- 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] #newtwitter direct message UI
The #newtwitter direct message UI sucks. - There's no indication on the main UI that you have an unread message. If you miss the email notification you will never notice the message. - On the DM page, there's no indication of which conversations have unread messages, or even the most recent messages. The conversations are presented in random order. - When a conversation is displayed, again there is no indication of which messages are unread or which is the most recent. Again they are displayed in random order. So. Are there plans to improve it? Has anyone written their own improved version? Anyone want to collaborate on writing one? --- Jef -- 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] Twitter for Android app OAuth
Twitter's official Android app is obviously using OAuth, since it still works. So why does it ask for my password? Isn't it supposed to send me to a web page where I can click Ok? What is going on behind the scenes here? Maybe just some leftover Basic Auth code that hasn't been deleted yet? If so, delete it! -- 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?hl=en
[twitter-dev] Re: Twitter for Android app OAuth
On Aug 31, 12:46 pm, Matt Harris thematthar...@twitter.com wrote: Like many mobile applications Twitter for Android uses xAuth. In this mode the user enters their username and password which is then sent to Twitter for the OAuth credentials. Part of the agreement of granting access to xAuth is that the application must not store the username and password. Ah hah! Ok, thanks, good to know. A lot of folks are tweeting right now about the end of password-based authentication. Maybe someone should tell them not quite. -- 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?hl=en
[twitter-dev] Re: How is this a solution?
On Aug 9, 7:44 am, Tom allerleiga...@gmail.com wrote: If you use some kind of server-side proxy, you still have the same issue, because you also have to identify your application to your own server - which anyone can do, no matter how good the encryption is. Yes, anyone who uses your application gets identified as using your application. This is not a problem.
[twitter-dev] Re: How is this a solution?
On Aug 7, 10:52 am, @epc epcoste...@gmail.com wrote: What's the approved open source solution to this problem? You don't have to make it a full-fledged web app as Ed Borasky says. You can also use a server-side proxy that holds your API keysecret and signs API calls. Of course this means all of your application's traffic will funnel through your server instead of going direct to twitter, which is obviously not good. And I'll also repeat what Julio Biason said, that this is not actually an open source vs. closed source issue. Closed source desktop mobile applications also have their app keysecret built into the app. Anyone with a debugger can extract them. OAuth is a web authentication protocol. It was not designed to authenticate desktop and mobile apps, and should not be used for that.
[twitter-dev] oauth_sign - simple C code to generate an OAuth signature
Last week I finished converting my homebrew Twitter apps to OAuth. There were four parts to this effort, one of which includes a significant new piece of OAuth software. I'll talk about each part in turn. Part 0: Deciding to do it. My apps are command-line based and call Twitter using my equivalents of curl, called http_get and http_post. These are simple command-line programs that make an HTTP call. What I needed was a simple command-line program to make an OAuth-signed HTTP call. Did that already exist? Sort of - there was Marcel Molina's twurl: http://github.com/marcel/twurl Only problem is that it's written in Ruby, which I do not have installed and am not really intrerested in installing. For those of us who want to stick with plain old C or possibly C++, the only available OAuth code is liboauth: http://liboauth.sourceforge.net/ This includes code to link with libcurl and make signed HTTP calls. It's pretty huge - 1.6 megabytes of source. I tried it anyway. Unfortunately I couldn't get to work on my system. So I was kind of stuck, and decided to roll my own. Part 1: Generating OAuth signatures. I figured that instead of writing a program to make signed HTTP calls directly, I would write something that generates the signature header, and then use that with my existing HTTP callers. I worked my way through RFC5849 for a few weeks and came up with this, which is the main reason for this message: http://acme.com/software/oauth_sign/ There's both a library call and a command-line program. Written in C, 20 KB of source, Berkeley-style license. It interoperates with Twitter, and I checked it for memory leaks - clean. The only library it depends on is OpenSSL's libcrypto, which should be present on any modern system. If you try it, please let me know about any portability issues, for example srandomdev() probably doesn't exist on non-FreeBSD systems. Part 2: Getting OAuth tokens. Once I had the signature generator working, this part took about a day to set up. You can see it here: http://acme.com/twitter/ - one HTML/JavaScript page that calls a few CGIs. Feel free to run through the authorization process if you like, and/or read the .js file. Even though this was relatively easy, I feel I should not have needed to do it. Rather than making every app developer write pretty much the same thing, Twitter should provide, as an option, a generic authorization page that works for any app. Given that, writing simple command-line Twitter apps would once again be nice and easy. Part 3: Adapting my apps to use the new code. This part was trivial. Where they used to call http_get/http_post, now they first call oauth_sign and then pass the signature header to http_get/http_post. It's literally just a couple extra lines of code. However, my app's consumer token secret have to be built into the code, therefore I can no longer distribute these apps for others to use. Supposedly Twitter has a solution in the works for open-source apps like this. When that becomes available I'll check it out and see if it solves this. --- Jef Jef Poskanzer j...@mail.acme.com http://acme.com/jef/
[twitter-dev] Re: oauth_sign - simple C code to generate an OAuth signature
On Jul 5, 10:52 am, Decklin Foster deck...@red-bean.com wrote: There is also Curlicue, which I've written: http://github.com/decklin/curlicue Ooo a sh script! Very nice.
[twitter-dev] Re: Streaming stocktwits
On Jul 2, 6:59 am, John Kalucki j...@twitter.com wrote: FWIW: They are tweets. A twit is something else. So why isn't the company app called Tweeter?
[twitter-dev] Re: secure key - desktop applications?
You're right in theory that requests after the initial authentication step should not really need the app's credentials, a single authentication token secret ought to suffice and the service (twitter) should remember which app each token came from. But shrug, that's just not the way OAuth works. It's not twitter's fault, they are just following the spec. I can't even say it's particularly unreasoinable - flickr's similar three-party authentication protocol is much simpler than OAuth but it still uses the app key on every request. As for embedding the app secret in desktop and mobile executables and trusting that it will be just too difficult for miscreants to extract, I say don't do it. The OAuth RFC says so too. Keeping the secret in a server-side proxy is probably the best solution.
[twitter-dev] Which OAuth URLs are right?
My app page at http://twitter.com/oauth_clients/details/n says I should use: http://twitter.com/oauth/request_token http://twitter.com/oauth/access_token http://twitter.com/oauth/authorize However the OAuth at Twitter page at http://dev.twitter.com/pages/auth#at-twitter says to use https instead of http and api.twitter.com instead of twitter.com: https://api.twitter.com/oauth/request_token https://api.twitter.com/oauth/access_token https://api.twitter.com/oauth/authorize Which should I believe? I'm sure all combinations of http/https twitter.com/api.twitter.com work, at least for now, but the dev page seems pretty emphatic that I should use its version. If it's that important, shouldn't the official app page get changed to give the same URLs? --- Jef
[twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
Yeah, what Ryan said. Also, On Jun 13, 1:40 pm, segphault ryankp...@gmail.com wrote: Facebook and Google Buzz both offer desktop-appropriate OAuth authentication flows which do not require a consumer secret key and do not require the user to go through a complicated copy/paste process. I'm curious what they are doing. Do they give up on identifying the application and just identify the user?
[twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
I don't understand why you are suggesting this only for open source programs. Were you thinking that an attacker would be incapable of decompiling an executable and extracting the secret?
[twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
obfuscate your code (compiling, or intentional obfuscation) So OAuth's security is based on obscurity? That's pretty lame.
[twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
On Jun 12, 10:16 am, Taylor Singletary taylorsinglet...@twitter.com wrote: (This is the other side of the coin.. on one side of the coin you have the advantage that OAuth applications keep working even if the user changes their password (YAY!) and then you have on the side of the coin that OAuth applications keep working even if the user changes their password and they have no idea that they've granted an OAuth access token without their explicit permission (BOO!) ) The apps still show up in http://twitter.com/settings/connections don't they? And the access can be revoked there?
[twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
On Jun 12, 11:49 am, Bernd Stramm bernd.str...@gmail.com wrote: secure against what? The threat that OAuth's security-through-obscurity fails to protect against is rogue-app B doing something bad while using legit-app A's stolen credentials. The author of app A gets blamed for app B's bad behavior and app A gets shut down. In other words, it's a denial of service attack against applications, not against users. Application authors are being asked to devote substantial resources to the OAuth conversion, but OAuth provides no security for application authors!
[twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
You know, it's right there in the OAuth RFC. http://tools.ietf.org/html/rfc5849#section-4.6 4.6. Secrecy of the Client Credentials In many cases, the client application will be under the control of potentially untrusted parties. For example, if the client is a desktop application with freely available source code or an executable binary, an attacker may be able to download a copy for analysis. In such cases, attackers will be able to recover the client credentials. Accordingly, servers should not use the client credentials alone to verify the identity of the client.
[twitter-dev] Re: Basic authentication
For my command-line twitter applications there is no third party, just the end-user and twitter. Basic Auth + https would be just fine for that.
[twitter-dev] Basic authentication
Have you considered keeping basic auth enabled, but only for https? This would be secure against packet sniffing and would probably use less resources than OAuth.
[twitter-dev] Re: Announcing Twurl: OAuth-enabled curl for the Twitter API
Twurl is just what I need, a command-line OAuth getter. Except it's written in a language I don't have so it's useless to me. Before turning off basic auth twitter needs to provide their own official implementation of a CLI OAuth getter, written in plain old C.
[twitter-dev] Twitpocalypse II: this time it's unsigned
So how long until status ids reach 4294967296, breaking the apps that were fixed today by changing signed to unsigned? Taking twitter's growth rate into account I think it's less than a year away. --- Jef
[twitter-dev] Re: Twitpocalypse Announcement
On Jun 12, 2:05 pm, J. Adam Moore jadammo...@gmail.com wrote: Got it. Use Java's BigInteger class for all the ID fields and don't look back. :) Actually the easiest solution is to leave the status ids as strings. That's what I do in my three homebrew twitter clients and they are working just fine.
