Re: [twitter-dev] Tell me more about OAuth
That also requires browser. Probably you meant this (which is not supported yet) http://groups.google.co.in/group/twitter-development-talk/browse_thread/thread/a0db34ea68c20792/508f1de916fa7f7d#508f1de916fa7f7d On Sun, Jan 31, 2010 at 12:48 AM, Raffi Krikorian ra...@twitter.com wrote: we currently have a PIN based workflow for this purpose - http://apiwiki.twitter.com/Authentication On Fri, Jan 29, 2010 at 11:21 PM, popoffka popof...@gmail.com wrote: Hello everybody! I want to develop twitter client for a special system, but there's a problem - this system don't have a web browser. Does that mean that I can't use OAuth for authentication in my app? -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
Using a proxy to handle all requests is not that simple. You need both consumer and access secrets to sign the request. http://groups.google.co.in/group/twitter-development-talk/browse_thread/thread/a195ea9b9952e297/851d9b34ecc9126f?q=#851d9b34ecc9126f You have to handle the burden of securely mapping user request from your desktop app to get his access token with in the proxy. I would rather prefer distributing them either as obfuscated or through secure proxy (just to fetch consumer key/secret once). None of them is 100% safe but it is slightly better than simply giving away your keys in plain text. On Sun, Jan 31, 2010 at 8:07 AM, ShellEx Well 5h3l...@gmail.com wrote: I have considered this matter. But to use a proxy handle all request is not my intention... I will go to write a online version if i have to do that :D. What I want to know is that: in my distributed version, should I include the key/secret in the config file(or hardcode in source, it doesn't matter)? On Jan 31, 8:42 am, Josh Roesslein jroessl...@gmail.com wrote: I suppose the only other way to make the UX good and to keep the consumer secret absolutely hidden is to proxy all requests through a hosted server. This does come as a cost of having to pay for a server to perform the proxy work. But it's really the only option at the moment I can think of that's 100% safe. Josh On Sat, Jan 30, 2010 at 6:35 PM, funkatron funkat...@gmail.com wrote: Not to be a complete pill, but that is a terrible, terrible initial experience for the average desktop app user. There is no way I would or could reasonably ask one of my users to register an app themselves, then fill in obscure hashes. The OAuth secret is simply impossible to use securely with open source, end-user-oriented applications. My only option with Spaz, when Twitter decides to take away basic auth, is to pray someone doesn't decide to steal my secret hash. Compiling does make getting the key more difficult, but assuming that desktop apps are compiled isn't a good idea -- Spaz isn't, for example. I could obscure the code for the end user, I suppose, but doing so seems contrary to open source philosophy, and probably just presents a challenge. 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. On Jan 30, 2:22 pm, Raffi Krikorian ra...@twitter.com 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 tohttp://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 Teamhttp://twitter.com/raffi
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
On 01/30/2010 02:43 PM, Isaiah Carew wrote: 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? If that were the case, then it would be the requirement for all desktop apps. Open source just makes it easier to grab the key; if you stick your keys in your Air or .NET app, they can still be grabbed. Basically, if you're doing a desktop app (of any kind) with OAuth, there is a risk that your consumer key will be misappropriated. The OAuth spec explicitly acknowledges this, stating that the consumer key/secret is cannot necessarily be trusted to securely identify the consumer. - Michael -- mouse, n: A device for pointing at the xterm in which you want to type. Confused by the strange files? I cryptographically sign my messages. For more information see http://www.elehack.net/resources/gpg. signature.asc Description: OpenPGP digital signature
Re: [twitter-dev] Re: Possibility to link to the user page not by the name but by the id.
If user is no longer the same user as the one that posted status id , then the link http://twitter.com//statuses/ would no longer be valid (as the NEW user is not the owner of the status id). On Jan 30, 2010, at 11:40 PM, Ivan Glushkov gli.w...@gmail.com wrote: Actually i can't. For example, i get some link like http://twitter.com/AAA/statuses/11, for the message that was posted month ago. I can't be sure if the current user AAA has the same guid as the AAA month ago. If i had the link like http://twitter.com/redirect?id=111status=222 i would be sure that it's the same user and the same status for that user. Ivan. On Sun, Jan 31, 2010 at 9:36 AM, Michael Ivey michael.i...@gmail.com wrote: You could do this internally in your application, using statuses/ show to make sure you have the correct user info before redirecting. -- ivey On Sat, Jan 30, 2010 at 4:06 AM, Ivan Glushkov gli.w...@gmail.com wrote: Oh, thanks, Abraham! That's great! But why isn't it documented anywhere? And is there any way to redirect to some status of this user? I mean smth like http://twitter.com/account/redirect_by_id?id=9436992status=3 ??? Thanks once more, Ivan. On Fri, Jan 29, 2010 at 11:37 PM, Abraham Williams 4bra...@gmail.com wrote: Actually Twitter does support it. http://twitter.com/account/redirect_by_id?id=9436992 Abraham On Wed, Jan 27, 2010 at 06:42, Ivan gli.w...@gmail.com wrote: Hi. I don't need an application that is able to handle this. Instead i need changes in the twitter API so i can refer to the users and their statuses using the user id, not the username. This is a problem for the aggregator, and there users (so it become also a problem for the twitter users). Is there any plan in this direction? Ivan. On 21 янв, 06:03, Abraham Williams 4bra...@gmail.com wrote: I remember this topic coming up before and it seems like someone built an application that handled this but I can't find any references to it. Maybe somebody else can? Abraham On Wed, Jan 20, 2010 at 06:29, Ivan gli.w...@gmail.com wrote: Hi. I tried to find the similar question here (in google groups), in the FAQ and in the API, but couldn't find anything. The problem: Cross-posting the links to the user page and to some his statuses in the web become more and more popular. But, as i understood, you can't guarantee that this links not long after would not change the logical destination. For example I create some post about some twitter- user aaa and give the link twitter.com/aaa After that user “aaa” changed name to bbb and user dd d changed name to aaa. So my old link now points to the different person. This problem becomes more serious for the aggregators that don't know what content they might approve after a while. The simplest decision would be providing the possibility to link to the user not by name but also by id. That pages might be just redirections to the original user pages, it doesn't matter. For example if the user “aaa” have id 11, the following two link s should point to the same page: twitter.com/aaa and twitter.com/id/11 This mechanism should also be applied for the statuses: twitter.com/id/11/statuses/22 Ivan. -- Abraham Williams | Moved to Seattle | May cause email delays Project | Intersect |http://intersect.labs.poseurtech.com Hacker |http://abrah.am|http://twitter.com/abraham This email is: [ ] shareable [x] ask first [ ] private. Sent from Seattle, WA, United States -- Abraham Williams | Moved to Seattle | May cause email delays Project | Out Loud | http://outloud.labs.poseurtech.com Hacker | http://abrah.am | http://twitter.com/abraham This email is: [ ] shareable [x] ask first [ ] private. Sent from Seattle, WA, United States
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
I wonder if Twitter could provide developers with an URL for dynamically generating additional consumer tokens for their applications. When the user installs a new application it will contact the developer's server to download its own consumer key/secret. The developer's server will use its master consumer key/secret to post to the Twitter URL to fetch a new consumer key/secret. The consumer pair will then be sent to the application via a secure channel (HTTPS?) to prevent man in the middle attacks. The application will then use this new consumer pair to perform all signing of requests. Another option is to package the dynamically generated consumer pair in the application download package. Each new download will have its own unique consumer pair ready for use once the user has downloaded the application. This still requires the developer maintain a server to perform the consumer pair generation, but it does keep the master pair secure and each application gets its own pair. But applications that are willing to make this trade off can keep the UX good, control what application instances can authorize on the application's behalf, and the master pair is never shared. You can always still distribute the master pair with each application if these security gains are not that important to you. Or you can require your users to generate their own consumer pair if UX is not much of an issue (example: distributed server applications) where an advance users is at the wheel and won't have issues figuring this out. Josh
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
I wonder if Twitter could provide developers with an URL for dynamically generating additional consumer tokens for their applications. When the user installs a new application it will contact the developer's server to download its own consumer key/secret. The developer's server will use its master consumer key/secret to post to the Twitter URL to fetch a new consumer key/secret. The consumer pair will then be sent to the application via a secure channel (HTTPS?) to prevent man in the middle attacks. The application will then use this new consumer pair to perform all signing of requests. Another option is to package the dynamically generated consumer pair in the application download package. Each new download will have its own unique consumer pair ready for use once the user has downloaded the application. I like those ideas. They match up maintaining a consistent application identity with better key security. The first one seems more workable. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- I couldn't care less about apathy. -
Re: [twitter-dev] DMs are automatically tweeted (not what I want!) :)
don't give your passwords to applications that are not using oauth :P On Sat, Jan 30, 2010 at 7:58 PM, Jesse Stay jesses...@gmail.com wrote: Except that the largest culprit of these (not going to name names) doesn't use OAuth. On Fri, Jan 29, 2010 at 8:25 PM, Kevin Marshall falico...@gmail.comwrote: Also check what apps you've granted access to: https://twitter.com/account/connections and remove any that you no longer want to have access... - Kevin http://wow.ly On Fri, Jan 29, 2010 at 10:23 PM, Abraham Williams 4bra...@gmail.com wrote: Change your password. Abraham On Tue, Jan 26, 2010 at 08:50, SDF wordpressblogsi...@gmail.com wrote: I can't find an answer to how or why this is happening nor can I figure out how to stop the madness :) Since testing a tweet this on a client's site (or so I can narrow down) my DM's are automatically becoming tweets. This is happening for auto-dms and personal dms. So if I receive a dm such as: abcuser: hi there thanks for the follow then the tweet that gets posted within 8 hours is: [abcuser] hi there thanks for the follow via api I cannot delete it via tweetdeck but I can from ubertwitter on my blackberry. How can I stop it from auto-tweeting my dms? Is there something in the API that I triggered somehow? Any help would be appreciated. Thanks! -- 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 -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Twitter Search with HTTP Referrer and User Agent
http://www.google.com/search?sourceid=chromeie=UTF-8q=setting+the+user+agent+PHP seems to return some useful stuff. On Sat, Jan 30, 2010 at 11:24 PM, marc mctob...@gmail.com wrote: I'm a novice programmer. I found this statement to be confusing Applications must have a meaningful and unique User Agent when using this method. A HTTP Referrer is expected but not required. I would like to not run into any limits even though my app is fairly small. How does one set this information? I am using PHP with JSON to make the calls to twitter if that makes any difference. Thank you! Marc -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
this is an interesting idea -- what twitter could do is keep key hierarchies mapping a master consumer key to subsidiary consumer keys...? On Sun, Jan 31, 2010 at 8:04 AM, Josh Roesslein jroessl...@gmail.comwrote: I wonder if Twitter could provide developers with an URL for dynamically generating additional consumer tokens for their applications. When the user installs a new application it will contact the developer's server to download its own consumer key/secret. The developer's server will use its master consumer key/secret to post to the Twitter URL to fetch a new consumer key/secret. The consumer pair will then be sent to the application via a secure channel (HTTPS?) to prevent man in the middle attacks. The application will then use this new consumer pair to perform all signing of requests. Another option is to package the dynamically generated consumer pair in the application download package. Each new download will have its own unique consumer pair ready for use once the user has downloaded the application. This still requires the developer maintain a server to perform the consumer pair generation, but it does keep the master pair secure and each application gets its own pair. But applications that are willing to make this trade off can keep the UX good, control what application instances can authorize on the application's behalf, and the master pair is never shared. You can always still distribute the master pair with each application if these security gains are not that important to you. Or you can require your users to generate their own consumer pair if UX is not much of an issue (example: distributed server applications) where an advance users is at the wheel and won't have issues figuring this out. Josh -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
Yeah basically twitter can allow developers to generate children keys from their master key they received during application registration. The developer is then free to delegate the generated children to whom ever they wish. This gives us freedom to then pick who can sign requests using our application name. We can be very open with this (basically a hidden, public API for the desktop applications) or restrictive (password/secret guarded API) on our end. Josh On Sun, Jan 31, 2010 at 10:45 AM, Raffi Krikorian ra...@twitter.com wrote: this is an interesting idea -- what twitter could do is keep key hierarchies mapping a master consumer key to subsidiary consumer keys...? On Sun, Jan 31, 2010 at 8:04 AM, Josh Roesslein jroessl...@gmail.com wrote: I wonder if Twitter could provide developers with an URL for dynamically generating additional consumer tokens for their applications. When the user installs a new application it will contact the developer's server to download its own consumer key/secret. The developer's server will use its master consumer key/secret to post to the Twitter URL to fetch a new consumer key/secret. The consumer pair will then be sent to the application via a secure channel (HTTPS?) to prevent man in the middle attacks. The application will then use this new consumer pair to perform all signing of requests. Another option is to package the dynamically generated consumer pair in the application download package. Each new download will have its own unique consumer pair ready for use once the user has downloaded the application. This still requires the developer maintain a server to perform the consumer pair generation, but it does keep the master pair secure and each application gets its own pair. But applications that are willing to make this trade off can keep the UX good, control what application instances can authorize on the application's behalf, and the master pair is never shared. You can always still distribute the master pair with each application if these security gains are not that important to you. Or you can require your users to generate their own consumer pair if UX is not much of an issue (example: distributed server applications) where an advance users is at the wheel and won't have issues figuring this out. Josh -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Search API domain
Yes I have been using the search.twitter.com domain for all the search methods in my library. It was just brought up in a ticket that some of the search methods do work on api.twitter.com. This does appear to be true after some testing, so I thought maybe Twitter was finally merging the two API's together. Thank you for clearing this up. I will continue using the two separate domains search.* and api.* in my library. Josh On Sun, Jan 31, 2010 at 10:41 AM, Raffi Krikorian ra...@twitter.com wrote: please check out http://apiwiki.twitter.com/Twitter-API-Documentation - it lists the full domain and URL you should be using for all calls. in general, all the timeline, status, user related methods are on api.twitter.com, and search related methods are on search.twitter.com. the exception comes with trends: the trends api which has local trends and global trends is on api.twitter.com; the original trends information (global trends, daily global trends, weekly global trends) are on search twitter.com. On Sat, Jan 30, 2010 at 2:05 PM, Josh Roesslein jroessl...@gmail.com wrote: Hello, I have discovered that the search methods search and trends seem to work okay with the domain api.twitter.com. But the methods trends/current, trends/daily, and trends/weekly return 401's. They only appear to work correctly on the search.twitter.com. I have opened an issue here [1]. Will all search methods eventually work on the api.twitter.com domain? Thanks. Josh [1] http://code.google.com/p/twitter-api/issues/detail?id=1413 -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Search API domain
merging the two is still high on the list -- we're unfortunately not there yet... On Sun, Jan 31, 2010 at 8:57 AM, Josh Roesslein jroessl...@gmail.comwrote: Yes I have been using the search.twitter.com domain for all the search methods in my library. It was just brought up in a ticket that some of the search methods do work on api.twitter.com. This does appear to be true after some testing, so I thought maybe Twitter was finally merging the two API's together. Thank you for clearing this up. I will continue using the two separate domains search.* and api.* in my library. Josh On Sun, Jan 31, 2010 at 10:41 AM, Raffi Krikorian ra...@twitter.com wrote: please check out http://apiwiki.twitter.com/Twitter-API-Documentation - it lists the full domain and URL you should be using for all calls. in general, all the timeline, status, user related methods are on api.twitter.com, and search related methods are on search.twitter.com. the exception comes with trends: the trends api which has local trends and global trends is on api.twitter.com; the original trends information (global trends, daily global trends, weekly global trends) are on search twitter.com. On Sat, Jan 30, 2010 at 2:05 PM, Josh Roesslein jroessl...@gmail.com wrote: Hello, I have discovered that the search methods search and trends seem to work okay with the domain api.twitter.com. But the methods trends/current, trends/daily, and trends/weekly return 401's. They only appear to work correctly on the search.twitter.com. I have opened an issue here [1]. Will all search methods eventually work on the api.twitter.com domain? Thanks. Josh [1] http://code.google.com/p/twitter-api/issues/detail?id=1413 -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
[twitter-dev] OAuth Application Registration
If you have an OAuth application, remember to register apps with all the variations of your app name, i.e., AppName, AppName.com, www.AppName.com, etc. You're only going to use one of them. The rest of them are to prevent someone else from registering the name and impersonating your app. Twitter: Can you please build in better verification that it is the actual owner of the app that is registering the app? Something like the email domain of the registering Twitter account must be the same as the domain in the app's URL, and then send a confirmation email to that email address to activate the registration. Or reasonable facsimilee thereof. Twitter folks, can you please delete the SocialOomph app entry so that I can register it in my @socialoomph Twitter account and use it for implementing OAuth on my site.
Re: [twitter-dev] Re: Possibility to link to the user page not by the name but by the id.
Oh, no! I haven't found it! I added comment in my issue that it's duplicate, but i don't know how to close it. On Sun, Jan 31, 2010 at 3:44 AM, Andy Freeman ana...@earthlink.net wrote: Argh! I opened such a feature request late last November AND you commented on it late last December. See http://code.google.com/p/twitter-api/issues/detail?id=1242 . On Jan 30, 11:17 am, Abraham Williams 4bra...@gmail.com wrote: There does not appear to be. You could open an feature request and maybe Twitter will augment ithttp://code.google.com/p/twitter-api/issues/entry. Abraham On Sat, Jan 30, 2010 at 02:06, Ivan Glushkov gli.w...@gmail.com wrote: Oh, thanks, Abraham! That's great! But why isn't it documented anywhere? And is there any way to redirect to some status of this user? I mean smth like http://twitter.com/account/redirect_by_id?id=9436992status=3 ??? Thanks once more, Ivan. On Fri, Jan 29, 2010 at 11:37 PM, Abraham Williams 4bra...@gmail.com wrote: Actually Twitter does support it. http://twitter.com/account/redirect_by_id?id=9436992 Abraham On Wed, Jan 27, 2010 at 06:42, Ivan gli.w...@gmail.com wrote: Hi. I don't need an application that is able to handle this. Instead i need changes in the twitter API so i can refer to the users and their statuses using the user id, not the username. This is a problem for the aggregator, and there users (so it become also a problem for the twitter users). Is there any plan in this direction? Ivan. On 21 янв, 06:03, Abraham Williams 4bra...@gmail.com wrote: I remember this topic coming up before and it seems like someone built an application that handled this but I can't find any references to it. Maybe somebody else can? Abraham On Wed, Jan 20, 2010 at 06:29, Ivan gli.w...@gmail.com wrote: Hi. I tried to find the similar question here (in google groups), in the FAQ and in the API, but couldn't find anything. The problem: Cross-posting the links to the user page and to some his statuses in the web become more and more popular. But, as i understood, you can't guarantee that this links not long after would not change the logical destination. For example I create some post about some twitter-user aaa and give the link twitter.com/aaa After that user “aaa” changed name to bbb and user ddd changed name to aaa. So my old link now points to the different person. This problem becomes more serious for the aggregators that don't know what content they might approve after a while. The simplest decision would be providing the possibility to link to the user not by name but also by id. That pages might be just redirections to the original user pages, it doesn't matter. For example if the user “aaa” have id 11, the following two links should point to the same page: twitter.com/aaa and twitter.com/id/11 This mechanism should also be applied for the statuses: twitter.com/id/11/statuses/22 Ivan. -- Abraham Williams | Moved to Seattle | May cause email delays Project | Intersect |http://intersect.labs.poseurtech.com Hacker |http://abrah.am|http://twitter.com/abraham This email is: [ ] shareable [x] ask first [ ] private. Sent from Seattle, WA, United States -- Abraham Williams | Moved to Seattle | May cause email delays Project | Out Loud |http://outloud.labs.poseurtech.com Hacker |http://abrah.am|http://twitter.com/abraham This email is: [ ] shareable [x] ask first [ ] private. Sent from Seattle, WA, United States -- 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- Hide quoted text - - Show quoted text -
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] Twitter Search with HTTP Referrer and User Agent
You're most likely using cURL with PHP so you want to look into cURL options to set headers...on a very generic level it will be something like: $headers = User-Agent: YourAppName; curl_setopt($ch, CURLOPT_HTTPHEADER, $headers); - Kevin http://friendstat.us On Sun, Jan 31, 2010 at 2:24 AM, marc mctob...@gmail.com wrote: I'm a novice programmer. I found this statement to be confusing Applications must have a meaningful and unique User Agent when using this method. A HTTP Referrer is expected but not required. I would like to not run into any limits even though my app is fairly small. How does one set this information? I am using PHP with JSON to make the calls to twitter if that makes any difference. Thank you! Marc
Re: [twitter-dev] What tools do you use?
Abraham Williams 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://twitter.com/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://twitter.com/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://twitter.com/oauthlib - http://github.com/abraham/twitteroauth The first PHP Library to support OAuth for Twitter's REST API. MIT licensed. GitHub - @github http://twitter.com/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 NetBeans 6.8 IDE, it's free and so far the best (free cross-platform) IDE I've found for Linux. They are finally starting to add some good support for RoR -- Kind Regards, Rajinder Yadav | http://DevMentor.org | Do Good! - Share Freely
[twitter-dev] I attach my new app to the wrong twitter account: how to change that
It's the first time I register an app, I was connected to a wrong twitter account, my app is not validated yet, would like to know how I can change the account. Thanks.
Re: [twitter-dev] Re: Possibility to link to the user page not by the name but by the id.
I would also argue that, at the time of status whomever owned the account was the one that actually made the post...so it doesn't really matter who is controlling right now...they are associated with the history of the account, because, well it's a history. As an aside though, is there really that much username changing going on? I would think it's more likely an account goes idle or dead than gets transferred to another user...and for the most part this feels like a discussion about designing a system to scale to handle a kabillion users when it's not even clear yet if 10 users would actually use the service... Don't sweat the edge cases so much, fear will paralyze you...it's better to be 'completely broken' for a small percentage of people than to not exist for anyone... Just my two cents ;-) - Kevin On Sun, Jan 31, 2010 at 10:41 AM, Michael Steuer mste...@gmail.com wrote: If user is no longer the same user as the one that posted status id , then the link http://twitter.com//statuses/ would no longer be valid (as the NEW user is not the owner of the status id). On Jan 30, 2010, at 11:40 PM, Ivan Glushkov gli.w...@gmail.com wrote: Actually i can't. For example, i get some link like http://twitter.com/AAA/statuses/11, for the message that was posted month ago. I can't be sure if the current user AAA has the same guid as the AAA month ago. If i had the link like http://twitter.com/redirect?id=111status=222 i would be sure that it's the same user and the same status for that user. Ivan. On Sun, Jan 31, 2010 at 9:36 AM, Michael Ivey michael.i...@gmail.com wrote: You could do this internally in your application, using statuses/show to make sure you have the correct user info before redirecting. -- ivey On Sat, Jan 30, 2010 at 4:06 AM, Ivan Glushkov gli.w...@gmail.com wrote: Oh, thanks, Abraham! That's great! But why isn't it documented anywhere? And is there any way to redirect to some status of this user? I mean smth like http://twitter.com/account/redirect_by_id?id=9436992status=3 ??? Thanks once more, Ivan. On Fri, Jan 29, 2010 at 11:37 PM, Abraham Williams 4bra...@gmail.com wrote: Actually Twitter does support it. http://twitter.com/account/redirect_by_id?id=9436992 Abraham On Wed, Jan 27, 2010 at 06:42, Ivan gli.w...@gmail.com wrote: Hi. I don't need an application that is able to handle this. Instead i need changes in the twitter API so i can refer to the users and their statuses using the user id, not the username. This is a problem for the aggregator, and there users (so it become also a problem for the twitter users). Is there any plan in this direction? Ivan. On 21 янв, 06:03, Abraham Williams 4bra...@gmail.com wrote: I remember this topic coming up before and it seems like someone built an application that handled this but I can't find any references to it. Maybe somebody else can? Abraham On Wed, Jan 20, 2010 at 06:29, Ivan gli.w...@gmail.com wrote: Hi. I tried to find the similar question here (in google groups), in the FAQ and in the API, but couldn't find anything. The problem: Cross-posting the links to the user page and to some his statuses in the web become more and more popular. But, as i understood, you can't guarantee that this links not long after would not change the logical destination. For example I create some post about some twitter-user aaa and give the link twitter.com/aaa After that user “aaa” changed name to bbb and user ddd changed name to aaa. So my old link now points to the different person. This problem becomes more serious for the aggregators that don't know what content they might approve after a while. The simplest decision would be providing the possibility to link to the user not by name but also by id. That pages might be just redirections to the original user pages, it doesn't matter. For example if the user “aaa” have id 11, the following two links should point to the same page: twitter.com/aaa and twitter.com/id/11 This mechanism should also be applied for the statuses: twitter.com/id/11/statuses/22 Ivan. -- Abraham Williams | Moved to Seattle | May cause email delays Project | Intersect |http://intersect.labs.poseurtech.com Hacker |http://abrah.am|http://twitter.com/abraham This email is: [ ] shareable [x] ask first [ ] private. Sent from Seattle, WA, United States -- Abraham Williams | Moved to Seattle | May cause email delays Project | Out Loud | http://outloud.labs.poseurtech.com Hacker | http://abrah.am | http://twitter.com/abraham This email is: [ ] shareable [x] ask first [ ] private. Sent from Seattle, WA, United States
Re: [twitter-dev] Re: Possibility to link to the user page not by the name but by the id.
Yeap. But. 1. I have incorrect URL, that i can't use immediately. I mean for the every URL i can't be sure that guid is not changed for this username, so i can't be sure that every URL is correct. So for each URL 2. I have to find out the correct link with the help of 3. One or several request to the twitter API 4. If that URL is already in my database, i have to replace it with the new one, or better search for all records with this URL and replace old URL with the new one. It's unacceptable price for the absence of just one additional (and very chip for the twitter) functionality in the API. Ivan. On Sun, Jan 31, 2010 at 6:41 PM, Michael Steuer mste...@gmail.com wrote: If user is no longer the same user as the one that posted status id , then the link http://twitter.com//statuses/ would no longer be valid (as the NEW user is not the owner of the status id). On Jan 30, 2010, at 11:40 PM, Ivan Glushkov gli.w...@gmail.com wrote: Actually i can't. For example, i get some link like http://twitter.com/AAA/statuses/11, for the message that was posted month ago. I can't be sure if the current user AAA has the same guid as the AAA month ago. If i had the link like http://twitter.com/redirect?id=111status=222 i would be sure that it's the same user and the same status for that user. Ivan. On Sun, Jan 31, 2010 at 9:36 AM, Michael Ivey michael.i...@gmail.com wrote: You could do this internally in your application, using statuses/show to make sure you have the correct user info before redirecting. -- ivey On Sat, Jan 30, 2010 at 4:06 AM, Ivan Glushkov gli.w...@gmail.com wrote: Oh, thanks, Abraham! That's great! But why isn't it documented anywhere? And is there any way to redirect to some status of this user? I mean smth like http://twitter.com/account/redirect_by_id?id=9436992status=3 ??? Thanks once more, Ivan. On Fri, Jan 29, 2010 at 11:37 PM, Abraham Williams 4bra...@gmail.com wrote: Actually Twitter does support it. http://twitter.com/account/redirect_by_id?id=9436992 Abraham On Wed, Jan 27, 2010 at 06:42, Ivan gli.w...@gmail.com wrote: Hi. I don't need an application that is able to handle this. Instead i need changes in the twitter API so i can refer to the users and their statuses using the user id, not the username. This is a problem for the aggregator, and there users (so it become also a problem for the twitter users). Is there any plan in this direction? Ivan. On 21 янв, 06:03, Abraham Williams 4bra...@gmail.com wrote: I remember this topic coming up before and it seems like someone built an application that handled this but I can't find any references to it. Maybe somebody else can? Abraham On Wed, Jan 20, 2010 at 06:29, Ivan gli.w...@gmail.com wrote: Hi. I tried to find the similar question here (in google groups), in the FAQ and in the API, but couldn't find anything. The problem: Cross-posting the links to the user page and to some his statuses in the web become more and more popular. But, as i understood, you can't guarantee that this links not long after would not change the logical destination. For example I create some post about some twitter-user aaa and give the link twitter.com/aaa After that user “aaa” changed name to bbb and user ddd changed name to aaa. So my old link now points to the different person. This problem becomes more serious for the aggregators that don't know what content they might approve after a while. The simplest decision would be providing the possibility to link to the user not by name but also by id. That pages might be just redirections to the original user pages, it doesn't matter. For example if the user “aaa” have id 11, the following two links should point to the same page: twitter.com/aaa and twitter.com/id/11 This mechanism should also be applied for the statuses: twitter.com/id/11/statuses/22 Ivan. -- Abraham Williams | Moved to Seattle | May cause email delays Project | Intersect |http://intersect.labs.poseurtech.com Hacker |http://abrah.am|http://twitter.com/abraham This email is: [ ] shareable [x] ask first [ ] private. Sent from Seattle, WA, United States -- Abraham Williams | Moved to Seattle | May cause email delays Project | Out Loud | http://outloud.labs.poseurtech.com Hacker | http://abrah.am | http://twitter.com/abraham This email is: [ ] shareable [x] ask first [ ] private. Sent from Seattle, WA, United States
[twitter-dev] Re: Tell me more about OAuth
Yes, that;s right what I need! Ok, I'll wait for implementation. On Jan 31, 10:58 am, srikanth reddy srikanth.yara...@gmail.com wrote: That also requires browser. Probably you meant this (which is not supported yet)http://groups.google.co.in/group/twitter-development-talk/browse_thre... On Sun, Jan 31, 2010 at 12:48 AM, Raffi Krikorian ra...@twitter.com wrote: we currently have a PIN based workflow for this purpose - http://apiwiki.twitter.com/Authentication On Fri, Jan 29, 2010 at 11:21 PM, popoffka popof...@gmail.com wrote: Hello everybody! I want to develop twitter client for a special system, but there's a problem - this system don't have a web browser. Does that mean that I can't use OAuth for authentication in my app? -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
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. If you include the key, sooner or later it will be found. Just ask Jon Lech Johansen. It may not be worth it for apps with small user bases, but that's not much security. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- In Computer Science, we stand on each other's feet. -- Brian Reid --
Re: [twitter-dev] What tools do you use?
+1 for NetBeans! I don't remember if it does Perl, but it definitely does Ruby, Python and PHP. And it's a boatload easier to use than Eclipse. Of course, if you do Android development, you probably need Eclipse anyhow. :-( On Sun, Jan 31, 2010 at 6:29 AM, Rajinder Yadav devguy...@gmail.com wrote: Abraham Williams 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://twitter.com/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://twitter.com/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://twitter.com/oauthlib - http://github.com/abraham/twitteroauth The first PHP Library to support OAuth for Twitter's REST API. MIT licensed. GitHub - @github http://twitter.com/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 NetBeans 6.8 IDE, it's free and so far the best (free cross-platform) IDE I've found for Linux. They are finally starting to add some good support for RoR -- Kind Regards, Rajinder Yadav | http://DevMentor.org | Do Good! - Share Freely -- 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
That's not all that secure, eventually it will be loaded into memory and can be found by any hacker with some patience. As soon as you distribute any sort of data it is no longer private. You're average Joe might not be able to find it, but any skilled hacker will. And after all the average Joe does not care anyways about OAuth tokens (what's oauth?), but hackers do. So you're kind of blocking the wrong person, it's the hacker you want to stop. Josh On Sun, Jan 31, 2010 at 2:28 AM, scott.a.herb...@googlemail.com wrote: 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] I attach my new app to the wrong twitter account: how to change that
You can try emailing a...@twitter.com but I don't know if they move applications. Abraham On Sun, Jan 31, 2010 at 06:35, rebtweeter rebtwee...@yahoo.com wrote: It's the first time I register an app, I was connected to a wrong twitter account, my app is not validated yet, would like to know how I can change the account. Thanks. -- 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
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
Interesting.This is more or less similar to each user registering their own app. But twitter may have better control with this hierarchy. Just wondering if twitter could actually replace 'PIN' part with those key/secret pair i.e when the user clicks 'Download app' link in apps webpage it will do all the initial oauth stuff i.e generating req tokens etc and redirect the user to twitter (https) and (authenticate if required) twitter will generate the new key/secret pair and it will either 1) redirect these values back to the apps download page so that app can embed these values in the download pkg and push this pkg to user or 2) just display those key/secret in twitter page and ask user to manually enter those details after they download the pkg The advantage with the second approach is that the apps providers don't have to implement anything significant other than using the regular oauth stuff (just change the url). Even with the first approach there is no need for any sort of client communication from desktop app to app provider after a pkg is downloaded. Again this whole scenario is for 'PIN' based desktop flows only(not for browser less systems). Basically the reasoning is that if the users have no issues in entering the PIN then they shouldn't have any issues with entering these key/secret pair either. If UX is an issue then the first approach may be used. Any comments on this? On Sun, Jan 31, 2010 at 9:34 PM, Josh Roesslein jroessl...@gmail.comwrote: I wonder if Twitter could provide developers with an URL for dynamically generating additional consumer tokens for their applications. When the user installs a new application it will contact the developer's server to download its own consumer key/secret. The developer's server will use its master consumer key/secret to post to the Twitter URL to fetch a new consumer key/secret. The consumer pair will then be sent to the application via a secure channel (HTTPS?) to prevent man in the middle attacks. The application will then use this new consumer pair to perform all signing of requests. Another option is to package the dynamically generated consumer pair in the application download package. Each new download will have its own unique consumer pair ready for use once the user has downloaded the application. This still requires the developer maintain a server to perform the consumer pair generation, but it does keep the master pair secure and each application gets its own pair. But applications that are willing to make this trade off can keep the UX good, control what application instances can authorize on the application's behalf, and the master pair is never shared. You can always still distribute the master pair with each application if these security gains are not that important to you. Or you can require your users to generate their own consumer pair if UX is not much of an issue (example: distributed server applications) where an advance users is at the wheel and won't have issues figuring this out. Josh
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
On Sun, Jan 31, 2010 at 08:04, Josh Roesslein jroessl...@gmail.com wrote: I wonder if Twitter could provide developers with an URL for dynamically generating additional consumer tokens for their applications. When the user installs a new application it will contact the developer's server to download its own consumer key/secret. The developer's server will use its master consumer key/secret to post to the Twitter URL to fetch a new consumer key/secret. The consumer pair will then be sent to the application via a secure channel (HTTPS?) to prevent man in the middle attacks. The application will then use this new consumer pair to perform all signing of requests. Another option is to package the dynamically generated consumer pair in the application download package. Each new download will have its own unique consumer pair ready for use once the user has downloaded the application. How is it better or more secure to have crackers misappropriated your sub key to mimic your application instead of your primary key? They are still pretending to be your application and users won't know any different. If each sub key had its own listing on https://twitter.com/account/connectionsthen there would be some differentiation but then if users install an application five times it would be listed five times. Abraham -- 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
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
Just to add more . There will always be only one level of sub keys in the hierarchy. Everytime the user downloads the same app the same key pair will be given (like access token/secrets) (a user authentication may be made mandatory in this case) On Mon, Feb 1, 2010 at 12:39 AM, srikanth reddy srikanth.yara...@gmail.comwrote: Interesting.This is more or less similar to each user registering their own app. But twitter may have better control with this hierarchy. Just wondering if twitter could actually replace 'PIN' part with those key/secret pair i.e when the user clicks 'Download app' link in apps webpage it will do all the initial oauth stuff i.e generating req tokens etc and redirect the user to twitter (https) and (authenticate if required) twitter will generate the new key/secret pair and it will either 1) redirect these values back to the apps download page so that app can embed these values in the download pkg and push this pkg to user or 2) just display those key/secret in twitter page and ask user to manually enter those details after they download the pkg The advantage with the second approach is that the apps providers don't have to implement anything significant other than using the regular oauth stuff (just change the url). Even with the first approach there is no need for any sort of client communication from desktop app to app provider after a pkg is downloaded. Again this whole scenario is for 'PIN' based desktop flows only(not for browser less systems). Basically the reasoning is that if the users have no issues in entering the PIN then they shouldn't have any issues with entering these key/secret pair either. If UX is an issue then the first approach may be used. Any comments on this? On Sun, Jan 31, 2010 at 9:34 PM, Josh Roesslein jroessl...@gmail.comwrote: I wonder if Twitter could provide developers with an URL for dynamically generating additional consumer tokens for their applications. When the user installs a new application it will contact the developer's server to download its own consumer key/secret. The developer's server will use its master consumer key/secret to post to the Twitter URL to fetch a new consumer key/secret. The consumer pair will then be sent to the application via a secure channel (HTTPS?) to prevent man in the middle attacks. The application will then use this new consumer pair to perform all signing of requests. Another option is to package the dynamically generated consumer pair in the application download package. Each new download will have its own unique consumer pair ready for use once the user has downloaded the application. This still requires the developer maintain a server to perform the consumer pair generation, but it does keep the master pair secure and each application gets its own pair. But applications that are willing to make this trade off can keep the UX good, control what application instances can authorize on the application's behalf, and the master pair is never shared. You can always still distribute the master pair with each application if these security gains are not that important to you. Or you can require your users to generate their own consumer pair if UX is not much of an issue (example: distributed server applications) where an advance users is at the wheel and won't have issues figuring this out. Josh
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
I would like to point out the official Flickr Uploadr application that is OAuth and open source. If you download it as a user [1] it includes their official API keys but if you download it as a developer [2] you implement your own API keys. Ironically all of these massive threads talking about impersonating applications is probably just making more crackers aware that they can do this. :-/ Abraham [1] http://www.flickr.com/tools/uploadr/ [2] http://code.flickr.com/trac/browser/trunk/uploadr/README.osx#L76 On Sun, Jan 31, 2010 at 10:06, Josh Roesslein jroessl...@gmail.com wrote: That's not all that secure, eventually it will be loaded into memory and can be found by any hacker with some patience. As soon as you distribute any sort of data it is no longer private. You're average Joe might not be able to find it, but any skilled hacker will. And after all the average Joe does not care anyways about OAuth tokens (what's oauth?), but hackers do. So you're kind of blocking the wrong person, it's the hacker you want to stop. Josh On Sun, Jan 31, 2010 at 2:28 AM, scott.a.herb...@googlemail.com wrote: 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. -- 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
[twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
Abraham,
Twitter will have to do something to combat application impersonation.
Let's say your app is MyAppName and your URL is http://www.myappname.com.
Currently, anyone can register an app MyApppName or MyAppnName and
give http://www.myappname.com as the URL for the app, with zero
verification. They can do all kinds of naughty things, and your app is
going to take the blame for it in most users' minds.
On Jan 31, 3:19 pm, Abraham Williams 4bra...@gmail.com wrote:
I would like to point out the official Flickr Uploadr application that is
OAuth and open source. If you download it as a user [1] it includes their
official API keys but if you download it as a developer [2] you implement
your own API keys.
Ironically all of these massive threads talking about impersonating
applications is probably just making more crackers aware that they can do
this. :-/
Abraham
[1]http://www.flickr.com/tools/uploadr/
[2]http://code.flickr.com/trac/browser/trunk/uploadr/README.osx#L76
On Sun, Jan 31, 2010 at 10:06, Josh Roesslein jroessl...@gmail.com wrote:
That's not all that secure, eventually it will be loaded into memory
and can be found by any hacker with some patience. As soon as you
distribute any sort of data it is no longer private. You're average
Joe might not be able to find it, but any skilled hacker will. And
after all the average Joe does not care anyways about OAuth tokens
(what's oauth?), but hackers do. So you're kind of blocking the
wrong person, it's the hacker you want to stop.
Josh
On Sun, Jan 31, 2010 at 2:28 AM, scott.a.herb...@googlemail.com wrote:
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.
--
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
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
Hmmm. Flickr is a service provider but if a consumer(developer) like Tweetdeck were to implement oauth and if they distribute keys there is always this problem of misusing those and the very first thing twitter would do is ban that application. Flickr can share it, but developers? i do not know . On Mon, Feb 1, 2010 at 12:49 AM, Abraham Williams 4bra...@gmail.com wrote: I would like to point out the official Flickr Uploadr application that is OAuth and open source. If you download it as a user [1] it includes their official API keys but if you download it as a developer [2] you implement your own API keys. Ironically all of these massive threads talking about impersonating applications is probably just making more crackers aware that they can do this. :-/ Abraham [1] http://www.flickr.com/tools/uploadr/ [2] http://code.flickr.com/trac/browser/trunk/uploadr/README.osx#L76 On Sun, Jan 31, 2010 at 10:06, Josh Roesslein jroessl...@gmail.comwrote: That's not all that secure, eventually it will be loaded into memory and can be found by any hacker with some patience. As soon as you distribute any sort of data it is no longer private. You're average Joe might not be able to find it, but any skilled hacker will. And after all the average Joe does not care anyways about OAuth tokens (what's oauth?), but hackers do. So you're kind of blocking the wrong person, it's the hacker you want to stop. Josh On Sun, Jan 31, 2010 at 2:28 AM, scott.a.herb...@googlemail.com wrote: 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. -- 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
Re: [twitter-dev] mobile.twitter.com from iphone app
I would imagine Twitter will at least redirect either m to mobile or mobile to m. Abaham On Tue, Jan 12, 2010 at 16:23, rakf1 kris...@gmail.com wrote: I'm planning to link to mobile.twitter.com from my iphone application, so was wondering if the mobile.twitter.com site is just a preview or will it work forever. Just want to make sure that mobile.twitter.com will still work after the design is transitioned to m.twitter.com at some point. -- 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
Re: [twitter-dev] I attach my new app to the wrong twitter account: how to change that
You should be able to log in as the account, delete the app ( via http://twitter.com/wrongaccount/oauth where wrongaccount is the one you incorrectly set your app up under)...then log out, log into the account you really want it associated with and set it up as a new app... That is assuming you have access to the account you incorrectly set the app up from in the first place (but if you don't how did you set it up in the first place?!)... - Kevin http://friendstat.us On Sun, Jan 31, 2010 at 1:42 PM, Abraham Williams 4bra...@gmail.com wrote: You can try emailing a...@twitter.com but I don't know if they move applications. Abraham On Sun, Jan 31, 2010 at 06:35, rebtweeter rebtwee...@yahoo.com wrote: It's the first time I register an app, I was connected to a wrong twitter account, my app is not validated yet, would like to know how I can change the account. Thanks. -- 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
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
How is it better or more secure to have crackers misappropriated your sub key to mimic your application instead of your primary key? They are still pretending to be your application and users won't know any different. If each sub key had its own listing on https://twitter.com/account/connections then there would be some differentiation but then if users install an application five times it would be listed five times. Abraham I am not entirely sure what security benefits there is for having unique consumer pairs per an application instance. One I can think of is during the get access token step w/o HTTPS. A man in the middle could in theory steal the access token and generate valid signatures if the consumer secret is publicly known. If each instance had its own consumer pair then the attacker could do nothing with this access token. There may be other benefits of having a strong consumer secret for the signing process. A person more familiar with crypto would have to weigh in on that issue. For the connections listing it would probably only be listed once per an application. All access tokens generated from the sub-keys of the master consumer key would be invalidated. This may cause issues if the comprimised account was caused by using a stolen consumer sub-key. Both good and bad access tokens would get killed. Best thing is to make your application resilient and just have the user repeat the OAuth dance if the access tokens you have ever gets invalidated. Having multiple consumer keys also allows providing both a server and desktop service using the same application name. You don't want to be running the same consumer key you have publicly shared. Here your server and desktop applications would each get their own consumer pair. There is nothing you can really do to block impersonation of applications. If you grant code that is running on a machine you don't have control over access to a consumer pair linked to your application, it can do what ever it wants. You can play hide and seek the best you can with the hackers, but its a never ending battle of changing consumer pairs after they get leaked over and over again. I think the big question is how big of a deal is impersonating the from attribute? People are going to associate the content of the tweet with the account it was posted with, not the application that delivered it. If its a spam message from freecomputers3332 account posted by Tweetapp, people are not going to say hey that Tweetapp is spamming me. Instead they are going to report freecomputer3332 as spam and forget it.
[twitter-dev] Re: Possibility to link to the user page not by the name but by the id.
I starred 1412 and commented on 1242 that they're basically the same. On Jan 30, 11:46 pm, Ivan Glushkov gli.w...@gmail.com wrote: Oh, no! I haven't found it! I added comment in my issue that it's duplicate, but i don't know how to close it. On Sun, Jan 31, 2010 at 3:44 AM, Andy Freeman ana...@earthlink.net wrote: Argh! I opened such a feature request late last November AND you commented on it late last December. Seehttp://code.google.com/p/twitter-api/issues/detail?id=1242. On Jan 30, 11:17 am, Abraham Williams 4bra...@gmail.com wrote: There does not appear to be. You could open an feature request and maybe Twitter will augment ithttp://code.google.com/p/twitter-api/issues/entry. Abraham On Sat, Jan 30, 2010 at 02:06, Ivan Glushkov gli.w...@gmail.com wrote: Oh, thanks, Abraham! That's great! But why isn't it documented anywhere? And is there any way to redirect to some status of this user? I mean smth like http://twitter.com/account/redirect_by_id?id=9436992status=3 ??? Thanks once more, Ivan. On Fri, Jan 29, 2010 at 11:37 PM, Abraham Williams 4bra...@gmail.com wrote: Actually Twitter does support it. http://twitter.com/account/redirect_by_id?id=9436992 Abraham On Wed, Jan 27, 2010 at 06:42, Ivan gli.w...@gmail.com wrote: Hi. I don't need an application that is able to handle this. Instead i need changes in the twitter API so i can refer to the users and their statuses using the user id, not the username. This is a problem for the aggregator, and there users (so it become also a problem for the twitter users). Is there any plan in this direction? Ivan. On 21 янв, 06:03, Abraham Williams 4bra...@gmail.com wrote: I remember this topic coming up before and it seems like someone built an application that handled this but I can't find any references to it. Maybe somebody else can? Abraham On Wed, Jan 20, 2010 at 06:29, Ivan gli.w...@gmail.com wrote: Hi. I tried to find the similar question here (in google groups), in the FAQ and in the API, but couldn't find anything. The problem: Cross-posting the links to the user page and to some his statuses in the web become more and more popular. But, as i understood, you can't guarantee that this links not long after would not change the logical destination. For example I create some post about some twitter-user aaa and give the link twitter.com/aaa After that user “aaa” changed name to bbb and user ddd changed name to aaa. So my old link now points to the different person. This problem becomes more serious for the aggregators that don't know what content they might approve after a while. The simplest decision would be providing the possibility to link to the user not by name but also by id. That pages might be just redirections to the original user pages, it doesn't matter. For example if the user “aaa” have id 11, the following two links should point to the same page: twitter.com/aaa and twitter.com/id/11 This mechanism should also be applied for the statuses: twitter.com/id/11/statuses/22 Ivan. -- Abraham Williams | Moved to Seattle | May cause email delays Project | Intersect |http://intersect.labs.poseurtech.com Hacker |http://abrah.am|http://twitter.com/abraham This email is: [ ] shareable [x] ask first [ ] private. Sent from Seattle, WA, United States -- Abraham Williams | Moved to Seattle | May cause email delays Project | Out Loud |http://outloud.labs.poseurtech.com Hacker |http://abrah.am|http://twitter.com/abraham This email is: [ ] shareable [x] ask first [ ] private. Sent from Seattle, WA, United States -- 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- Hide quoted text - - Show quoted text -- Hide quoted text - - Show quoted text -
Re: [twitter-dev] mobile.twitter.com from iphone app
I would imagine Twitter will at least redirect either m to mobile or mobile to m. They already do, it looks like. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Two wrongs don't make a right, but they do make a great TV movie. --
Re: [twitter-dev] What tools do you use?
Erlang http://www.erlang.org/ Very satisfied with it, using it in a proxy server for j2me clients. Twerl, my own erlang twitter client. http://github.com/ak1394/twerl/ Anton On Sat, Jan 30, 2010 at 10:18 PM, scott.a.herb...@googlemail.com wrote: 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
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
[twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
This isn't a zero-day vuln that hasn't been reported to the vendor, so
I think any suggestion that keeping it on the DL is not helpful. This
is a known issue with application of the OAuth spec. Educating the
developers who read this list, and maybe helping Twitter's engineering
team understand the problems better, should be top priority.
Pointing out what Flickr does is fine, but they're also in more of a
position to address possible abuses of their own API key as both the
consumer and the provider. App devs will have to hope that the API
support team responds quickly to these issues – and without and SLA or
support agreement in most cases, Twitter is under no obligation to
care. I hope it's *not* like that, but I think we've all seen cases
where feedback and response time wasn't what we'd like.
I agree that much of this seems like beating a dead horse, but I'd
also like to see more official response about it, even if it's just
hey, we know, and this is just the tradeoff we need to make.
Otherwise, I think we're providing feedback as requested on the API in
general, and authentication in particular.
--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funkat...@gmail.com
On Jan 31, 2:19 pm, Abraham Williams 4bra...@gmail.com wrote:
I would like to point out the official Flickr Uploadr application that is
OAuth and open source. If you download it as a user [1] it includes their
official API keys but if you download it as a developer [2] you implement
your own API keys.
Ironically all of these massive threads talking about impersonating
applications is probably just making more crackers aware that they can do
this. :-/
Abraham
[1]http://www.flickr.com/tools/uploadr/
[2]http://code.flickr.com/trac/browser/trunk/uploadr/README.osx#L76
On Sun, Jan 31, 2010 at 10:06, Josh Roesslein jroessl...@gmail.com wrote:
That's not all that secure, eventually it will be loaded into memory
and can be found by any hacker with some patience. As soon as you
distribute any sort of data it is no longer private. You're average
Joe might not be able to find it, but any skilled hacker will. And
after all the average Joe does not care anyways about OAuth tokens
(what's oauth?), but hackers do. So you're kind of blocking the
wrong person, it's the hacker you want to stop.
Josh
On Sun, Jan 31, 2010 at 2:28 AM, scott.a.herb...@googlemail.com wrote:
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.
--
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
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
On Sun, Jan 31, 2010 at 1:36 PM, Isaiah Carew isa...@me.com wrote: 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. I'm not convinced that distributing *any* oAuth capability to end users, even in binary form - even in a form where said binary interfaces in secure ways with the underlying desktop / mobile ways to persist the consumer key and secret - is the way to go. I personally think the way to go is to deploy applications as servers with the thinnest possible client imaginable. If ChromeOS netbooks actually existed today, that's what I'd be building - servers that interacted with Twitter on behalf of users with ChromeOS netbooks. Given what I know now about oAuth, I'm not planning on releasing any oAuth desktop applications. I never *was* planning mobile ones - the kind of processing I have in mind flat out can't be done on a mobile, so I'd have to have a server anyway to deploy to mobile users. 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 Well ... the motivation is there now, with or without oAuth. And oAuth doesn't make it *easier* to compromise a desktop application. As far as desktop user frustration is concerned, though, there are so many other sources of desktop user frustration already - botnets, weekly virus scans that take hours, browser vulnerabilities, 15-30 minute waits before the machine is open for business, and, of course, the hundreds of dollars one pays per year for just a license to use the desktop software - that I think a compromised Twitter desktop platform isn't going to get much attention unless it does something really nasty, like a DDOS against Twitter. -- 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
On Sun, Jan 31, 2010 at 5:30 PM, funkatron funkat...@gmail.com wrote: ... maybe helping Twitter's engineering team understand the problems better, should be top priority. I think Twitter's engineering team does understand the issues. But I think the primary responsibility lies with us developers, and I for one don't see the point in investing effort building desktop Twitter applications, given a. They're tough to scale down to mobile platforms, and mobile usage seems to be where the growth and action are in social media, and b. oAuth or not, desktop applications are difficult to secure. c. The Streaming API isn't designed to play well with desktops / laptops / mobiles. I agree that much of this seems like beating a dead horse, but I'd also like to see more official response about it, even if it's just hey, we know, and this is just the tradeoff we need to make. Otherwise, I think we're providing feedback as requested on the API in general, and authentication in particular. The environment in which Twitter and the Twitter development community operate is changing rapidly. The *desktop* oAuth tradeoffs may have made sense a year ago. before the huge growth spurt in awareness and usage of Twitter in 2009. As I've noted, I think the *server* oAuth tradeoffs still make sense. I think we need to take the advice of Wayne Gretzky and skate to where the puck is going to be. I should also note that I have never used a desktop Twitter client. I installed one once on my Linux workstation, and got frustrated by the Adobe AIR platform issues. The client wasn't giving me any functionality I couldn't get from a free server like HootSuite or even from Firefox, and there wasn't anything else I wanted that used AIR. So I'm not losing anything if desktop oAuth doesn't get enhanced. -- M. Edward (Ed) Borasky http://borasky-research.net I've always regarded nature as the clothing of God. ~Alan Hovhaness
Re: [twitter-dev] What tools do you use?
Yeah, I've always wanted to learn Erlang - maybe this year. ;-) Anybody here doing Twitter in Haskell? On Sun, Jan 31, 2010 at 5:11 PM, Anton Krasovsky anton.krasov...@gmail.com wrote: Erlang http://www.erlang.org/ Very satisfied with it, using it in a proxy server for j2me clients. Twerl, my own erlang twitter client. http://github.com/ak1394/twerl/ Anton On Sat, Jan 30, 2010 at 10:18 PM, scott.a.herb...@googlemail.com wrote: 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 -- 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
On Sun, Jan 31, 2010 at 8:26 PM, Cameron Kaiser spec...@floodgap.com wrote: I think Twitter's engineering team does understand the issues. But I think the primary responsibility lies with us developers, and I for one don't see the point in investing effort building desktop Twitter applications, given a. They're tough to scale down to mobile platforms, and mobile usage seems to be where the growth and action are in social media, and b. oAuth or not, desktop applications are difficult to secure. c. The Streaming API isn't designed to play well with desktops / laptops / mobiles. So don't develop one. But, speaking as a dev who eats his own dog food, I prefer to have a console open running TTYtter than mashing refresh all the time in Camino. Desktop apps are a useful part of the ecosystem, and I wouldn't be participating in Twitter anywhere near as much as a user if I had a much higher barrier to do so or had to trust a third-party service and add another layer on to do so on my behalf. I assume @funkatron's users have the same opinion. Yes, I write my own desktop apps too, but I don't distribute them. I never saw the need to use a desktop client when the browser worked just fine. Then again, I don't own a Mac and don't use Windows very often. Maybe a desktop client on a Windows or Mac makes more sense than it does on Linux. Assuming, of course, that a Linux desktop itself makes any sense - there aren't a lot of folks who agree with me on my choice of desktop. ;-) -- M. Edward (Ed) Borasky http://borasky-research.net I've always regarded nature as the clothing of God. ~Alan Hovhaness
[twitter-dev] iPhone Developers: Objective-C Library for TweetPhoto
We just released the Objective-C library for the entire TweetPhoto API. It is a set of drop in classes designed to allow you to get up and running quickly with the TweetPhoto Photo Sharing API. http://code.google.com/p/tweetphoto-api-objective-c/ This library includes every feature you'll need to manage the entire photo sharing experience within your application - from uploading photos, commenting, favoritng, and voting to social feeds, user feeds, and everything in between. Please let me know if you have any questions whatsoever. Sean
