Re: [twitter-dev] oauth verify credentials error
On Sat, 04 Sep 2010 19:02:11 +0200 Tom van der Woerdt i...@tvdw.eu wrote: On 9/4/10 6:08 PM, rrd wrote: I have a website which gets friends timeline by twitter api. I use oauth 1.0 My website worked without any problem in the last 1,5 year, but from 1st September something changed. When I try to add a new user my app redirects me to the twitter oauth authentication page, where I could log in with my twitter credentials. After this twitter redirects me to my application. After this when I try to verify credentials I got Could not authenticate you error message. Could it be a timestamp problem? I found a few articles about having authentication problems because of fautty timestamp. If so what should I do if I am not able to change the server time? It seems I have 55 minutes difference from twitter time. Is it 55 minutes, or 5 minutes and the wrong time zone? In the case of 55 minutes, of course Tom is right: 55 minutes is a lot. You should contact the server owner and tell him/her to synchronize the clock. If that's not an option, then you should simply generate an offset by asking the Twitter server the time and comparing this to the Unix Time of the server (don't do that too often, daily is fine). Later you can use this offset and add it to the Unix Time of the server to generate a time that is closer to the Twitter.com one. Tom -- Bernd Stramm bernd.str...@gmail.com -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] oauth verify credentials error
On Sat, 04 Sep 2010 20:34:50 +0200 Tom van der Woerdt i...@tvdw.eu wrote: On 9/4/10 8:13 PM, Bernd Stramm wrote: On Sat, 04 Sep 2010 19:02:11 +0200 Tom van der Woerdt i...@tvdw.eu wrote: On 9/4/10 6:08 PM, rrd wrote: I have a website which gets friends timeline by twitter api. I use oauth 1.0 My website worked without any problem in the last 1,5 year, but from 1st September something changed. When I try to add a new user my app redirects me to the twitter oauth authentication page, where I could log in with my twitter credentials. After this twitter redirects me to my application. After this when I try to verify credentials I got Could not authenticate you error message. Could it be a timestamp problem? I found a few articles about having authentication problems because of fautty timestamp. If so what should I do if I am not able to change the server time? It seems I have 55 minutes difference from twitter time. Is it 55 minutes, or 5 minutes and the wrong time zone? In the case of 55 minutes, of course Tom is right: I'd be right in both cases. ;-) Although compensating for the timezone is also an option. (But really, the Unix Timestamp is always UTC, right?) The sever of the website may be configured to a timezone that is different from the server's timezone. And, we don't know how the website code determines the time stamp. 5 minutes off indicates something wrong with the server, but it's not unheard of. 55 minutes is a lot. You should contact the server owner and tell him/her to synchronize the clock. If that's not an option, then you should simply generate an offset by asking the Twitter server the time and comparing this to the Unix Time of the server (don't do that too often, daily is fine). Later you can use this offset and add it to the Unix Time of the server to generate a time that is closer to the Twitter.com one. Tom -- Bernd Stramm bernd.str...@gmail.com -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] oauth verify credentials error
On Sat, 04 Sep 2010 20:55:19 +0200 Tom van der Woerdt i...@tvdw.eu wrote: On 9/4/10 8:51 PM, Bernd Stramm wrote: On Sat, 04 Sep 2010 20:34:50 +0200 Tom van der Woerdt i...@tvdw.eu wrote: On 9/4/10 8:13 PM, Bernd Stramm wrote: On Sat, 04 Sep 2010 19:02:11 +0200 Tom van der Woerdt i...@tvdw.eu wrote: On 9/4/10 6:08 PM, rrd wrote: I have a website which gets friends timeline by twitter api. I use oauth 1.0 My website worked without any problem in the last 1,5 year, but from 1st September something changed. When I try to add a new user my app redirects me to the twitter oauth authentication page, where I could log in with my twitter credentials. After this twitter redirects me to my application. After this when I try to verify credentials I got Could not authenticate you error message. Could it be a timestamp problem? I found a few articles about having authentication problems because of fautty timestamp. If so what should I do if I am not able to change the server time? It seems I have 55 minutes difference from twitter time. Is it 55 minutes, or 5 minutes and the wrong time zone? In the case of 55 minutes, of course Tom is right: I'd be right in both cases. ;-) Although compensating for the timezone is also an option. (But really, the Unix Timestamp is always UTC, right?) The sever of the website may be configured to a timezone that is different from the server's timezone. And, we don't know how the website code determines the time stamp. 5 minutes off indicates something wrong with the server, but it's not unheard of. Unix time, or POSIX time, is a system for describing points in time, defined as the number of seconds elapsed since midnight proleptic Coordinated Universal Time (UTC) of January 1, 1970, not counting leap seconds. Read the UTC part ;-) Yes I am aware of that, oh wise one :) We do not know how the website code is obtaining its time stamp, and whether that time stamp is converted to some kind of local time. There are plenty of function calls that return a time stamp, not all of them give you raw POSIX time. 55 minutes is a lot. You should contact the server owner and tell him/her to synchronize the clock. If that's not an option, then you should simply generate an offset by asking the Twitter server the time and comparing this to the Unix Time of the server (don't do that too often, daily is fine). Later you can use this offset and add it to the Unix Time of the server to generate a time that is closer to the Twitter.com one. Tom -- Bernd Stramm bernd.str...@gmail.com -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] Re: Twitter logout - hate to open this can of worms again
On Fri, 3 Sep 2010 01:27:34 -0700 (PDT) Ken k...@cimas.ch wrote: I thought I had found a solution, albeit a horrendously ugly one: redirect them to http://twitter.com/logout, but even that doesn't work. If you are looking for reliable, don't log them in with OAuth - except once, the first time, when you store their token. Indeed. If you already have the token, why would you make them log in? If you get a new token every time they visit your 3rd party (consumer) site, you generate a lot of authorized tokens, ALL of which are valid for the rest of eternity, or until twitter decides that it should be possible to invalidate tokens. Bernd -- Bernd Stramm bernd.str...@gmail.com -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] t.co and fail whales
On Fri, 3 Sep 2010 09:12:32 -0700 (PDT) Dewald Pretorius dpr...@gmail.com wrote: Twitter folks, how are you going to ensure that t.co links are not affected by over-capacity situations on your infrastructure? If you're routing t.co links through your existing infrastructure, absolutely *everyone's* links are going to be broken when you start throwing fail whales, even when the link is clicked in third-party applications. Are you running t.co on its own separate and dedicated infrastructure? Ah, that brings up the next idea of how to enhance my application :) It wouldn't be all that hard to keep a cache/database of all the t.co links seen in a user's incoming timeline, and their resolution. The user would then have a private link resolution database, to protect against such service outages. Seems pretty straightforward, perhaps people should do that sort of thing. Bernd -- Bernd Stramm bernd.str...@gmail.com -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] Re: Twitter logout - hate to open this can of worms again
On Fri, 03 Sep 2010 18:55:30 +0200 Tom van der Woerdt i...@tvdw.eu wrote: You may not have noticed, but with Twitter, if you request a token while you already have one, you'll simply get back the one you already have. I don't know if that is correct. The ones I looked at were all different, but that was some weeks ago. Tom On 9/3/10 6:47 PM, Bernd Stramm wrote: On Fri, 3 Sep 2010 01:27:34 -0700 (PDT) Ken k...@cimas.ch wrote: I thought I had found a solution, albeit a horrendously ugly one: redirect them to http://twitter.com/logout, but even that doesn't work. If you are looking for reliable, don't log them in with OAuth - except once, the first time, when you store their token. Indeed. If you already have the token, why would you make them log in? If you get a new token every time they visit your 3rd party (consumer) site, you generate a lot of authorized tokens, ALL of which are valid for the rest of eternity, or until twitter decides that it should be possible to invalidate tokens. Bernd -- Bernd Stramm bernd.str...@gmail.com -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] Re: Twitter logout - hate to open this can of worms again
On Fri, 3 Sep 2010 11:29:22 -0700 (PDT) Ken k...@cimas.ch wrote: What is the risk of storing a token? It can't be used outside your app. The token being confined to use within an app is very insecure when the app runs on an end-user device. There soon will be a billion smart phones, and many of those will run twitter apps. Then suppose user Alice finds out user Bob's token (perhaps by borrowing or stealing a phone), and publishes it. User Bob now has no way to retire the token, short of disabling the app that runs on millions of phones. Or Bob can get a new twitter user name. That's not what is normally called security. OAuth as currently done with twitter only works when the app runs on a small number of secure servers. -- Bernd Stramm bernd.str...@gmail.com -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] All Linux applications for Twitter broken...
On Fri, 3 Sep 2010 14:43:58 -0700 (PDT) Herb taa.t...@gmail.com wrote: You find not one Twitter application for Linux that is working. Mine works. Means Twitter is just useless if you use Linux. Not to talk from the thousands of Websites which send status messages to Twitter (e.g. a new posting/thread is entered). Looks like OAuth really works out for Twitter. Thx a lot guys, but it's time to look for something else than Twitter. Having enough people using the service and just doing that what you guys have done is absolutely not amusing. -- Bernd Stramm bernd.str...@gmail.com -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] Re: All Linux applications for Twitter broken...
On Fri, 3 Sep 2010 15:20:15 -0700 (PDT) Herb taa.t...@gmail.com wrote: Has all to do with Twitter. Changing to OAuth was really not needed and the problems for this change really obvious in first place, but since Twitter has that much users they probably feel that they can do whatever they like. Didn't find any way to use successfully OAuth for some Linux application in two weeks, As I said, my application works, on Fedora, Ubuntu Lucid, OpenSUSE and MeeGo. Look at http://chronicon.sourceforge.net. It is also in my launchpad ppa, and in my yum/zypper repos at build.opensuse.org. There are other twitter clients that also use qoauth. As far as I know, those are working as well. Terminal updates for sure never will work again and and and. the list is endless. This raise the question why there is a Twitter API at all available if the usage is not user friendly at all. Well, point is if this situation continuous for some time it may provides a way for something else that is better usable than Twitter. There already is StatusNet. You can run your own service, or subscribe to identi.ca. Of course the value of twitter is the large number of users. Most people use twitter to publish their content, so the number of readers is what they go after. On Sep 4, 5:01 am, Scott Wilcox sc...@dor.ky wrote: Hmm, that would be down to the developers of said applications not moving them to OAuth, nothing to do with Twitter. They've had plenty of time and warnings to do so. Don't take it out on Twitter when its down to the developers of the applications to maintain them. On 3 Sep 2010, at 22:43, Herb wrote: You find not one Twitter application for Linux that is working. Means Twitter is just useless if you use Linux. Not to talk from the thousands of Websites which send status messages to Twitter (e.g. a new posting/thread is entered). Looks like OAuth really works out for Twitter. Thx a lot guys, but it's time to look for something else than Twitter. Having enough people using the service and just doing that what you guys have done is absolutely not amusing. smime.p7s 5KViewDownload -- Bernd Stramm bernd.str...@gmail.com -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] Re: Using OAuth with twitter mobile
On Sat, 3 Jul 2010 01:55:30 -0700 (PDT) Terence Eden terence.e...@gmail.com wrote: Hi, The Twitter OAuth page should automatically detect mobile phones via their User-Agent string. It will then display a mobile friendly OAuth page. Right, it does that. Set your user agent string to that of a popular smart phone, and you get a nice little login page. -- Bernd Stramm bernd.str...@gmail.com
Re: [twitter-dev] Re: Which IETF standard has the year appearing after the time?
On Mon, 21 Jun 2010 13:37:12 -0700 (PDT) themattharris thematthar...@twitter.com wrote: The time format is a little weird and as far as I know, doesn't match any RFC. Instead it matches the ruby default and is represented in tokens by: %a %b %d %H:%M:%S %Z %Y which leads to the next question: why is that the Ruby default? Did they Ruby author forget the year and then decided to tack it on the end? -- Bernd Stramm bernd.str...@gmail.com
Re: [twitter-dev] Re: Links stripped from tweets
On Tue, 15 Jun 2010 23:26:41 -0700 (PDT) Rudiger bpa...@rocketmail.com wrote: I should probably clarify that the urls aren't stripped, just the anchor tags surrounding them. Anyone else have this problem? Are you sure the anchor tags were there in the first place? Many posts simply have text that says http://this.that.com;. -- Bernd Stramm bernd.str...@gmail.com
Re: [twitter-dev] Places database - how to get listed?
On Wed, 16 Jun 2010 16:11:34 -0700 M. Edward (Ed) Borasky zn...@borasky-research.net wrote: Suppose a merchant - let's say a coffee shop - is listed in Google and Yahoo's database. Are they *automatically* in Twitter's place database? If not, how do they get listed? Does it cost anything? As an aside, I know of a restaurant in Portland that's in the Google database with the correct address, but they showed up in Google Maps a couple of weeks ago a mile or so east of where they actually are. ;-) I know of a restaurant that is listed in Google Maps, has been in the same location for more than 5 years. The satellite image, with a copyright of 2010, still doesn't show the building. -- Bernd Stramm bernd.str...@gmail.com
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
Interesting details, and see below: On Mon, 14 Jun 2010 10:51:34 -0700 Zac Bowling zbowl...@gmail.com wrote: In facebook's desktop authflow, rather then giving you an ... Basically when it comes to desktop apps, Facebook can't for sure tell the difference between my desktop app and illegitimate one. Not only that, they (or anyone) cannot tell a legitimate desktop from an illegitimate one. An illegitimate person can take a desktop with a bunch of legitimate apps and do illegitimate things with the whole collection. And then we should not forget that a mobile phone is a the same as a desktop, from the point of view of the web server. Phones are usually not protected very well, both in terms of autheticating users and in physical terms. What is it that makes an app illegitimate? Basically that is impersonates the user, and does things the user doesn't want done. Unless of course the app does business on behalf of a third party with both the user and the server (twitter, facebook, ...). Collecting data is doing business in this sense. Then the app is an agent for that third party. But for a lot of apps, this is not the case, they act entirely as an agent for the user. They are no different than browsers in this respect. -- Bernd Stramm bernd.str...@gmail.com
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
On Sat, 12 Jun 2010 09:48:15 -0700 Zac Bowling zbowl...@gmail.com wrote: Yes, that is a problem with any app that you distribute that has any embedded keys. Unfortunately, you ultimately can't really entirely secure anything you ship that a user can run on their own machine. You can however take a few steps to make that extremely difficult by encrypting and obfuscating your consumer keys/secrets in your app package before you distribute. Nothing is impossible to reverse engineer if you can get your hands on it (look at iTunes), but you can make it take so long and be so hard that it becomes to hard and almost everyone gives up (look at iTunes 9). An important question: secure against what? Against posting tweets when the user is not who they say they are? You can't secure against that. Desktop machines are left unattended. Mobile phones are borrowed and stolen. Sure you can make it harder to just grab the key/secret pair of open source application A and implement application B, pretending to be A. But what does that buy you? What does that protect against? -- Bernd Stramm bernd.str...@gmail.com
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
On Sat, 12 Jun 2010 13:25:44 -0700 Zac Bowling zbowl...@gmail.com wrote: On Jun 12, 2010, at 11:57 AM, Jef Poskanzer wrote: Application authors are being asked to devote substantial resources to the OAuth conversion, but OAuth provides no security for application authors! It does from a web app perspective which is the primary design goal of OAuth since there would be no distribution of your secret in that scenario. Precisely. OAuth is designed for a 3-party security deal: Twitter running on some host, the App running on another host, and the User running on a third. OAuth is pretty useless for a 2-party situation, as is present in a desktop/mobile app on the users device. This isn't all that surprising, since it is designed for something different. ... shipped are at risk then. Your only recourse is to rev your secret and force all your users to upgrade their apps to get new keys. Another recourse might be to design a security approach for the app-on-user-device scenario, rather than trying to shoehorn a 3-party scheme into this. .. this isn't that bad since twitter isn't hosting credit card data or anything of major risk and you basically devolve into the same issue we had with app identify we had with basic auth and passing clear text source ids (except that maybe now all your apps are crippled). Right. As long as the app doesn't do any side business with a third party. If it does, then it should not use twitter's authentication for that purpose. I've been pondering how you could solve this from my experience with solving these issues with SSL/TLS. One idea is having a sort of delegation chain where I could generate a new delegated secret for each copy of my app I distribute rather then using my same static secret directly in all my apps and then the client could pass the authentication chain up when it goes to Twitter to get an access token. The question is also - why do you care which copy of your app it is? People using your app will post silly things, engage in slander of other people, commit crimes, plot revolutions. Are you responsible for these things? Is Twitter responsible for broadcasting the content? While we're at it, let's go after the phone manucacturer, the network bandwidth provider. ... Right now though, one solution if you are ultra paranoid if you are going to distribute software, is to proxy the calls from your own software through your own web service (which would render the ease of use you get from xAuth moot but you are sacrificing usability for security). You mean something like Microsoft authorization codes. Or make them download a UUID with the code, and send that code to twitter for each individual downloaded copy. Of course once the download count goes into the millions, twitter will love to store all those IDs. And of course every application developer has a website that handles all the downloads, none of them use google code, sourceforge, github, ... oh wait. Oh well, why bother. -- Bernd Stramm bernd.str...@gmail.com
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
Right, and... On Sat, 12 Jun 2010 16:09:47 -0700 (PDT) Jef Poskanzer jef.poskan...@gmail.com wrote: You know, it's right there in the OAuth RFC. http://tools.ietf.org/html/rfc5849#section-4.6 4.6. Secrecy of the Client Credentials In many cases, the client application will be under the control of potentially untrusted parties. For example, if the client is a desktop application with freely available source code or an executable binary, an attacker may be able to download a copy for analysis. In such cases, attackers will be able to recover the client credentials. Accordingly, servers should not use the client credentials alone to verify the identity of the client. But for a desktop/mobile standalone application, there is no single client entity. What is called the consumer is not an entity. It is a program running on a device, not a company. And to re-quote them: For example, if the client is a desktop application with freely available source code or an executable binary, an attacker may be able to download a copy for analysis. This borders on being silly - why bother with analysis, when the attacker can just run the program. The oauth system comes from client/server concepts and client/server thinking. In that scenario, the authentication is between one client and two servers. That is not the case with most desktop/mobile apps. -- Bernd Stramm bernd.str...@gmail.com
Re: [twitter-dev] List of users who have authorized my application with OAuth
On Fri, 11 Jun 2010 07:20:12 -0700 (PDT) Rahul rahul.jun...@gmail.com wrote: I have a question about OAuth on twitter api. Suppose i have made an pplication in twitter and i used OAuth to authorize users. User Authorize their twitter accounts and give permissions to my app. Is there any way i can get the list of user who have authorize my application. Along the same lines: for my case, I don't particularly care about the identity of users, but it could be interesting to just know the number of users. -- Bernd Stramm bernd.str...@gmail.com
Re: [twitter-dev] t.co Is cool, and I might have an issue with it anyway.
On Thu, 10 Jun 2010 12:14:06 -0700 (PDT) @IDisposable idisposa...@gmail.com wrote: Unlike many posters here, I REALLY LIKE the t.co shortening idea ... So, who's going to yell at us? With all you data miners out there clicking and downloading everything in sight, pretty soon you will only measure the noise created by data miners, web crawlers and the like. Google, yandex and the rest are already a signigicant amount of the traffic for small sites. What this means is that because you are introducing more and more background noise into your data, you will only be able to measure the really strong signals. That narrows what you can find, and you risk that eventually you find only obvious things. -- Bernd Stramm bernd.str...@gmail.com
Re: [twitter-dev] Re: link wrapping on the API
On Wed, 09 Jun 2010 12:22:03 -0700 M. Edward (Ed) Borasky zn...@borasky-research.net wrote: Quoting Ron B rbtheron...@gmail.com: I just had one of those *rough edges* brought to my attention that I think may also have already been alluded to on this thread. Some users use long URLs as a portion or even their entire tweet. This tweet technique is being used significantly in tweets about the Gulf oil spill crisis, for example. (i.e. http://www.grist.org/aritcle/2010-06-08-does-obama-need-more-not-fewer-oilmen-in-his-administration). The author of such a tweet fully expects that this message will be conveyed in the tweet itself, by virtue of the message conveyed by the long URL - not just the URL destination's content. It doesn't sound like this interesting and useful melding of tweet text and tweet attachments will be possible any longer after the t.co wrapper initiative is implemented. That would be a real shame... That particular example looks like a blatant search engine optimization ploy and not the human-to-human communication that is, IIRC, the Spirit of Twitter. ;-) Really now, what is wrong with a person expressing themselves by making human readable links? If an application wants to provide the original intent of the user, it is forced (by ToS), to present a link that doesn't go to where it says it does. That is problematic, the application acts as spyware. -- Bernd Stramm bernd.str...@gmail.com
Re: [twitter-dev] Re: link wrapping on the API
On Wed, 09 Jun 2010 17:13:04 -0700 M. Edward (Ed) Borasky zn...@borasky-research.net wrote: Quoting Ken k...@cimas.ch: Not exactly spyware, but deceptive. Don't expect the public to appreciate this. How is this deceptive? Who is being deceived, and how? How? There is text that is marked as a link, for example http://nasa.gov;, and it does not go to nasa.gov. If a user clicks on the link saying nasa.gov, it goes to t.co, which does business with a third party, not telling the user anything about it. How is that *not* deceptive? On Jun 9, 9:45 pm, Bernd Stramm bernd.str...@gmail.com wrote: If an application wants to provide the original intent of the user, it is forced (by ToS), to present a link that doesn't go to where it says it does. That is problematic, the application acts as spyware. -- Bernd Stramm bernd.str...@gmail.com -- Bernd Stramm bernd.str...@gmail.com
Re: [twitter-dev] Re: link wrapping on the API
On Tue, 8 Jun 2010 22:19:04 -0700 (PDT) Hwee-Boon Yar hweeb...@gmail.com wrote: But if apps don't update and user sends a tweet which is just below 140 characters say, 139, and which contain a link(s) shorter than 19 (or is it 20) characters will mysteriously fail. The user will wonder why the app doesn't let them send the tweet when their app clearly says it's still within 140 characters, because Twitter is now counting the longer 19/20 character t.co link. Is this considered a rare scenario? The right way to do this for twitter would be to count the characters submitted to the API, before twitter changes the content. That way, the API acceptance of a well formed post is predictable. Otherwise it's not, since an application really doesn't know what twitter will do with the content. -- Hwee-Boon On Jun 9, 12:18 pm, John Kalucki j...@twitter.com wrote: Apps that don't update will continue to work, they will just display something different than they do now. -- Bernd Stramm bernd.str...@gmail.com
Re: [twitter-dev] Getting friends_timeline
On Wed, 2 Jun 2010 07:06:54 -0700 Taylor Singletary taylorsinglet...@twitter.com wrote: You can either go ahead and implement the flow, protect it in your application such that only you have access to it, and then persist the access token you receive until the end of time (or whenever you decide to expire it, just like any other OAuth-enabled application). How does an application expire an access token? There doesn't seem to be anything in the API about that. The application can of course decide not to use an access token any more, but that doesn't mean the token is expired. The application/user combination can get a new access token. Does that expire the old token? But suppose the application is finished doing some work, and doesn't want the access token to work any longer. It would be nice to explicitly say to twitter don't accept this token you gave me any longer. Or even don't accept ANY token for this application/user pair until re-authorized. This would protect against stealing of access tokens and consumer keys. For practical purposes, for standalone desktop applications, the consumer key and secret are impossible to protect. Cloning an application is thus very easy. If an intruder can then also capture an authorization token, they can post fake tweets and get the user in trouble. Or get the application blacklisted, or both. Being able to actively expire an authorization token would help protect against this. Be safe, Bernd -- Bernd Stramm bernd.str...@gmail.com
Re: [twitter-dev] WordPress plugin
On Wed, 2 Jun 2010 13:23:34 -0700 (PDT) Cameron Kaiser spec...@floodgap.com wrote: We just updated our Twitter plugin for WordPress to use the new OAuth API. Someone just asked if it was safe to store the consumer key and consumer secret in plain text (which it basically has to be as I understand it, since ultimately it needs to be sent to the server in a plain text form). I can't really think of a way that would work for all end users to protect the two. Ultimately I guess this means that someone could pretend to be our application if they wanted? Anyone have any thoughts on this or any possible work arounds? Speaking from personal experience, Twitter will not allow you to have your consumer secret in plain text in (visible form in) your code. How do you propose people do that for desktop/mobile apps? You have to install the code on the user device, and that device at some point has to generate the consumer secret in clear text, so it can be signed. An intruder can examine the code and intercept the secret. -- Bernd Stramm bernd.str...@gmail.com
Re: [twitter-dev] Re: xAuth Permissions
On Tue, 1 Jun 2010 13:08:12 -0700 Taylor Singletary taylorsinglet...@twitter.com wrote: Hey Everyone! We know there are some issues with tickets right now -- they aren't being lost, but the conversion to our new version of the help center has not been without some hiccups. We have a very large backlog of xAuth requests right now and only very few resources available to process the queue. They'll be handled as quickly as we can. Can any of you see your pending tickets on this page? http://support.twitter.com/tickets yes I can see mine. It contains the email I sent. -- Bernd Stramm bernd.str...@gmail.com
Re: [twitter-dev] Re: How long does it take to get approved with xAuth?
On Sun, 30 May 2010 03:50:21 -0700 (PDT)
Rich rhyl...@gmail.com wrote:
You don't have to go from app to browser, embed a UIWebView and then
in
- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:
(NSURLRequest *)request navigationType:
(UIWebViewNavigationType)navigationType {
I do the equivalent in Qt. It looks decent, and the user has the
impression that they are typing their password into the app. In fact
they are.
So the user experience is pretty close to basic auth. I doubt that the
users who have been happily giving away their password left and right
really care who stores their password. Perhaps that situation will
improve with better user education.
An approach with a webview integrated into the app is more secure than
using an external browser - my app doesn't know what browser the user
has configured. Why would I assume that some unknown browser is secure
and doesn't grab their password? Many browsers have nice features for
exactly that.
There are other glaring holes in the entire setup. Users get an email
PIN from places like twitpic, and once a black hat has that, they can
impersonate the user with embarassing pictures and tweets all day.
So I would advise users to not use any of the twitter environment and
surroundings for banking transactions. And if embarrassing pics
surface, at least users have plausible deniability.
Be safe,
Bernd
--
Bernd Stramm
bernd.str...@gmail.com
Re: [twitter-dev] Re: How long does it take to get approved with xAuth?
On Sun, 30 May 2010 11:14:54 -0700 Abraham Williams 4bra...@gmail.com wrote: On Sun, May 30, 2010 at 11:01, Bernd Stramm bernd.str...@gmail.com wrote: The user does trust the app, otherwise they would not be using it. The problem with the scheme of using the app *and* a browser is that the user has to trust *both* of them. And if they don't trust the app, why are they using it to post their tweets? Trust is not a boolean value. There are levels of it. I trust my mobile browser to not take over my Twitter account but I only trust random new Twitter client to not post spam. If the Twitter client breaks my trust it is easy to revoke access to it. Is it easy for most users? The authentication token doesn't expire, so an application (any application, not just desktop/mobile client) can do what it wants for quite a while. You should be careful with trusting browsers, mobile or otherwise. They are very leaky. And my point remains, when using a browser *and* a standalone client, the user trusts both of them. From the point of view of the honest application developer, I do not want to assume that another application (the browser) which is completely unknown to me, is trustworthy. Hence I prefer the solution with the small integrated webview in my application. But also, what do people to with their twitter account that needs protecting, other than posting messages and media content? And of course giving away great data to the data miners. A lot of this authentication business misses the easiest intrusion vector anyway. People will steal your phone, and have access to everything you store on it. Including any authentication for serious business. Nevermind trusting the standalone app or the browser, the entire system is easily compromised if its stolen. -- Bernd Stramm bernd.str...@gmail.com
Re: [twitter-dev] Force mobile OAUTH ui?
On Fri, 28 May 2010 11:38:57 -0700 (PDT) GG gerber.g...@gmail.com wrote: Anyone know a way to get the mobile OAUTH ui from the desktop browser? Looks like they detect the browser and then swap the style sheets as oppose to redirecting to mobile.twitter.com/oauth/authorize (which dosnt exist) Tell your browser to send a User Agent string that says its a mobile. Maybe there is an undocumented parameter we can use? Something like: http://twitter.com/oauth/authorize?mobile=1oauth_token=123abc -- Bernd Stramm bernd.str...@gmail.com
[twitter-dev] twipic OAuth Echo status
Hi everyone, I have been working on getting twitpic upload to work with my client, and some of it is now functioning with oauth echo. There are some things that look broken / not implemented on the twitpic side, perhaps someone knows more and can verify: - it seems to make a difference whether I use http://api.twitpic.com/2/upload.xml or http://api.twitpic.com/2/upload.json The difference being that for json it works, and for xml twitpic complains that twitter rejected my signature. I am making sure that the format (xml/json) is the same on the twitpic request, and on the fake twitter request that is being signed. Next, I noticed that the message paramenter being present doesn't seem to cause twitpic to post a message on twitter. When I use .../uploadAndPost.json instead of .../upload.json, the behaviour is the same - pic goes to twitpic, nothing to twitter. Perhaps the missing twitter post is because of this: Twitter Message from raffi a.k.a raffi sent on Tue May 25 01:09:27 2010 Curious how to do uploadAndPost in OAuth Echo? http://post.ly/hEdl Where raffi explains who uploadAndPost *will* work. Any comments ? Advice ? -- Bernd Stramm bernd.str...@gmail.com
[twitter-dev] oauth expire
Hi, currently it appears that there is no facility for an application (consumer) to expire authorization. The twitter server can't do it automatically, since it doesn't really know when the consumer is finished with the authorized session, if ever. The user doesn't even know that authorization tokens and secrets exist, for the most part. However it could be good in some cases to enable the consumer application to explicitly say that it doesn't want the authorization any more. This would protect against the case of token/secret pair and consumer key/secret pairs being re-used by others. Is there any consideration for this? Basically all that would be needed is an API entry point where the consumer says thanks but no more, signed and verified as normal. -- Bernd Stramm bernd.str...@gmail.com
Re: [twitter-dev] Twitter OAuth Timestamps
On Tue, 25 May 2010 19:49:28 -0500 Brian Smith br...@briansmith.org wrote: This is known and expected behavior. There have been other threads about it in the last couple of weeks. If you get a 401 response, you should compare the Date header of Twitter's response to the current system time. If it is significantly off then you should warn the user so they can fix it and/or calculate the difference and add that offset to all your timestamps. More details are available in the mailing list archive. Regards, Brian I am seeing headers coming back from twitter with Expires : Tue, 31 Mar 1981 05:00:00 GMT on replies with good status. Nothing going wrong, auth works fine. Just a funny looking date in there. Is that sombody's epoch? It looks vaguely familiar. -- Bernd Stramm bernd.str...@gmail.com
Re: [twitter-dev] Date and Time from created_at fromTwitter API in PHP
On Sat, 22 May 2010 16:27:31 -0700 (PDT) giustin tgiu...@gmail.com wrote: Hi, In PHP, I can get the formated date. Example: $created_at = new DateTime($result-created_at); $created_at = $created_at-format(Y-m-d); echo $created_at.' - '; Questions: 1) how to get the time like hh:mm:ss from the result-created_at? 2) how to get the time in a specified time-zone, like UTC-03 (Brazil)? Have you considered the PHP manual, for example here http://www.php.net/manual/en/function.date.php Thank you. -- Bernd Stramm bernd.str...@gmail.com
