[twitter-dev] Two apps one set of tolkens
Just a quick questron, would two applications login in at the same time (via the same credencals, to the same account) cause twitter to have issues? I have a desktop client and background service that use the same database to tweet RSS feeds to twitter and am experances some strange issues which this may be the cause of... Sent using BlackBerry® from Orange
Re: [twitter-dev] Source parameter request for mobile Twitter app ignored (and issues with Twitter's policy toward oAuth on mobile/desktop)
No two ways about it oAuth on desktop's sucks and I imagan it's even worse on mobiles. Twitter can add new source prams to their database for non-oAuth users however when I tryed they where unable to do so. I'm currently developing a different .net desktop app (think Hootsuite for desktops) and am useing oAuth, and makeing it clear just why the user has to enter a PIN number into a textbox. The way I figure it if we developers explain to our users why the login sucks maybe they will pester twitter for us, and since a social network (like twitter) lives or dies by it's users then that will force their hand... Well I can hope... Sent using BlackBerry® from Orange -Original Message- From: Aral Balkan aralbal...@gmail.com Date: Mon, 1 Feb 2010 20:29:18 To: twitter-development-talk@googlegroups.com Subject: Re: [twitter-dev] Source parameter request for mobile Twitter app ignored (and issues with Twitter's policy toward oAuth on mobile/desktop) Raffi, Would you mind engaging me on this part of my email: I really don't understand Twitter's current strategy toward mobile and desktop apps. Are you guys actually_trying_ to say to developers: don't build new mobile/desktop apps because you won't be able to compete with existing ones? What I mean by that is this: Existing desktop and mobile apps do_not_ have to use oAuth_and_ get to keep their source parameter. The source parameter is probably the best means of organic marketing a Twitter app could have. OTOH, since these apps aren't using oAuth they don't have to worry about giving their apps a UX handicap (try setting up multiple Twitter accounts in a mobile/desktop app with oAuth, or using picture upload services and delegating your token... there are problems that haven't been solved yet.) Even though oAuth is not ready for mobile/desktop, Twitter is penalizing mobile/desktop applications that don't use it for UX reasons by not letting them take advantage of the organic marketing provided by the source parameter. I find this hugely unfair. I would really love to have a comment on from you guys for the blog post I'm writing: is Twitter actively discouraging the creation of new mobile and desktop apps? Personally, I am_not_ going to implement oAuth in my mobile app. This is not because I lack the skills to do so or an understanding of exactly how oAuth works and what it brings to the table. It's because I will not sacrifice the UX of my iPhone application by sending people to a barely legible, unusable, and not-optimized-for-iPhone oAuth page on Twitter.com as part of their flow (the other objections I listed – which are harder to tackle than making a mobile-friendly version of the oAuth page, which I cannot believe Twitter still hasn't done – do not apply to my application.) Sending a user to Twitter's oAuth page after having slaved over every pixel in your iPhone app is like giving someone a ride in a Ferrari and then throwing them in a mud puddle before pulling them back in for the remainder of their ride. I_really_ hope you can reconsider this as I see no logic whatsoever behind this policy. Regardless, my app goes to Apple tomorrow; source parameter or no. All the best, Aral On Mon, Feb 1, 2010 at 8:14 PM, Raffi Krikorian ra...@twitter.com wrote: hey aral. sorry you didn't get an e-mail back yet! however, like it has been mentioned before on the mailing list, documented on the faq on our wiki, etc., we're unfortunately not allowing new registrations of source parameters. sorry. it too has been all over the list, but i'm actively taking comments, etc. on how we can try to improve the oauth experience - just drop me a line personally. On Mon, Feb 1, 2010 at 12:04 PM, Aral Balkan aralbal...@gmail.com wrote: Dear Twitter peeps, I sent you an email 13 days ago to ask for a source parameter/token for the mobile Twitter app that I'm developing for the iPhone. Since that time I've had no response whatsoever to my email (which I'm including at the end of this one). Not even a auto-response to say, hey, we got your email – we'll get back to you or even, no way, Jose! I really don't understand Twitter's current strategy toward mobile and desktop apps. Are you guys actually_trying_ to say to developers: don't build new mobile/desktop apps because you won't be able to compete with existing ones? What I mean by that is this: Existing desktop and mobile apps do_not_ have to use oAuth_and_ get to keep their source parameter. The source parameter is probably the best means of organic marketing a Twitter app could have. OTOH, since these apps aren't using oAuth they don't have to worry about giving their apps a UX handicap (try setting up multiple Twitter accounts in a mobile/desktop app with oAuth, or using picture upload services and delegating your token... there are problems that haven't been solved yet.) Even though oAuth is not ready for mobile/desktop, Twitter is
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
I 100% agree. But another idea just struck me, why not put the OAuth part of your app in a DLL (at lest the authentication and communication with twitter part) and hard code it their. You lose some of the open source nature of the app but it will be secure. Sent using BlackBerry® from Orange -Original Message- From: Cameron Kaiser spec...@floodgap.com Date: Sat, 30 Jan 2010 23:02:18 To: twitter-development-talk@googlegroups.com Subject: Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client OAuth as-is just wasn't designed for desktop apps, period. Square peg, round hole. If Twitter is insisting on it, I'd rather this was portrayed as a trade-off for increased user security, than a solvable problem -- I don't think it is. +1 -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- I'd love to go out with you, but I'm in perpetual denial.
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
Why not check for the presence of the keys on start-up, if they are missing re-direct the user (open a browser window) to the new apps page and/or a step-by-step guide on you site. then store the keys as normal Sent using BlackBerry® from Orange -Original Message- From: Raffi Krikorian ra...@twitter.com Date: Sat, 30 Jan 2010 11:22:13 To: twitter-development-talktwitter-development-talk@googlegroups.com Subject: Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client 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] What tools do you use?
TwitterVB - a .net framework for twitter and PHP - custom written code to pull the public time line and users timelimes Sent using BlackBerry® from Orange -Original Message- From: M. Edward (Ed) Borasky zzn...@gmail.com Date: Sat, 30 Jan 2010 13:17:09 To: twitter-development-talk@googlegroups.com Subject: Re: [twitter-dev] What tools do you use? I do most of my Twitter API development in Perl, with some of it in Ruby. I use Komodo IDE for that. http://www.activestate.com/komodo/ The Perl Net::Twitter library: http://search.cpan.org/dist/Net-Twitter/ The Ruby tweetstream gem: http://intridea.com/2009/9/22/tweetstream-ruby-access-to-the-twitter-streaming-api PostgreSQL as a database for large collections of tweets: http://www.postgresql.org/ and of course, my own appliance, sm...@znmeb: http://borasky-research.net/2009/10/26/coming-soon-smartznmeb-0-5/ On Sat, Jan 30, 2010 at 11:55 AM, Abraham Williams 4bra...@gmail.com wrote: Lets collect an awesome list of tools and applications we use to help develop with the Twitter API. I'll start the list with a couple that I use: Charles Proxy - @charlesproxy - http://www.charlesproxy.com/ Charles is an HTTP proxy / HTTP monitor / Reverse Proxy that enables a developer to view all of the HTTP and SSL / HTTPS traffic between their machine and the Internet. This includes requests, responses and the HTTP headers (which contain the cookies and caching information) Hurl - @hurlit - http://hurl.it/ Hurl makes HTTP requests. Enter a URL, set some headers, view the response, then share it with others. Perfect for demoing and debugging APIs. Hurl is also open source - http://defunkt.github.com/hurl/ TwitterOAuth PHP Library - @oauthlib - http://github.com/abraham/twitteroauth The first PHP Library to support OAuth for Twitter's REST API. MIT licensed. GitHub - @github - https://github.com/ GitHub is the easiest (and prettiest) way to participate in that collaboration: fork projects, send pull requests, monitor development, all with ease. What tools do you use while developing with the Twitter API? -- Abraham Williams | Community Advocate | http://abrah.am Project | Out Loud | http://outloud.labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private. Sent from Seattle, WA, United States -- M. Edward (Ed) Borasky http://borasky-research.net I've always regarded nature as the clothing of God. ~Alan Hovhaness
