[twitter-dev] Re: callback if user deny
If a user denys an OAuth application Twitter currently does not return the user to the application or callback. There is no way to change this. Abraham On Thu, Jul 2, 2009 at 01:30, rag twitter wrote: > > Hi All, > > Call back URL working fine if user allow to connect the > application, but callback url not working if user deny the > application. > How do I achieve this ? > > -rag > -- Abraham Williams | Community Evangelist | http://web608.org Hacker | http://abrah.am | http://twitter.com/abraham Project | http://fireeagle.labs.poseurtech.com This email is: [ ] blogable [x] ask first [ ] private.
[twitter-dev] Re: daily follow/unfollow/update limit
The limits have not changed. We enforce the limits within hour intervals. Could the behavior you witnessed be explained by this enforcement policy? Thanks, Doug On Wed, Jul 1, 2009 at 8:10 PM, Developer In London wrote: > I saw on the API documentation the daily limit is 1000 per day. But it > seems its lower then that. Is it a %age based limit? > > Thanks > > Nayeem >
[twitter-dev] callback if user deny
Hi All, Call back URL working fine if user allow to connect the application, but callback url not working if user deny the application. How do I achieve this ? -rag
[twitter-dev] Re: Tweet threading
Whitelisting helps a lot: http://apiwiki.twitter.com/FAQ#IkeephittingtheratelimitHowdoIgetmorerequestsperhour On Thu, Jul 2, 2009 at 01:11, Coderanger wrote: > > I was wondering how you get over the API limit doing this, I would > imagine you would hit it almost straight away (10 statuses with 10 > replies would do it) as every reply will require a recursive status > request for every parent status? > -- Abraham Williams | Community Evangelist | http://web608.org Hacker | http://abrah.am | http://twitter.com/abraham Project | http://fireeagle.labs.poseurtech.com This email is: [ ] blogable [x] ask first [ ] private.
[twitter-dev] Re: Tweet threading
I was wondering how you get over the API limit doing this, I would imagine you would hit it almost straight away (10 statuses with 10 replies would do it) as every reply will require a recursive status request for every parent status?
[twitter-dev] Re: Tweet threading
Take a look on the app I'm workig on, Twitoaster: http://twitoaster.com The threading part is not that hard. Recursive function jumping from parents to parents. You should use the getMentions method, instead of hiting the search API. You'll get the full object that way, so you won't have to use the show/statuses method. All the best, Arnaud. On Jul 1, 12:53 am, Scott Haneda wrote: > I am finding near all apps I use with twitter in some way or another > fail at threading a conversation. Anyone have pointers for how to do > this, based on the current twitter API, and whatever bugs have been > uncovered, perhaps with workarounds? > > Each tweet has a 'in_reply_to_status_id', if I understand, the > existence of in_reply_to_status_id, means that the current tweet is a > child of some parent. > > tweet: > id = 1234 > in_reply_to_status_id = 5678 > > In the above example, tweet #5678 would be the start of the > conversation, and tweet #1234 would be the reply? > > What has me stumped:http://twitter.com/criticalmassey/status/2383870573 > > Clearly a reply to something @ahem said, which started > here:http://twitter.com/Ahem/status/2382725245 > > However, if I search.twitter.com for @ahem, I can get this > conversation:http://dl.getdropbox.com/u/340087/Drops/06.30.09/twitter-b06e01bd-154... > But it is missing the parent, the start of the thread. > > I can see the master parent > here:http://search.twitter.com/search?max_id=2410761989&page=2&q=+from%3Aa... > But threading is not an option. > > Having a hard time wrapping my head around what the limitations of > threading are. Any suggestions on how to better understand this would > be most appreciated. > > Ideally, what I am looking for, is to take any tweet, determine what > other replies there are to it, and get back to the parent, displaying > all children. I would like to avoid any ambiguous tweet searches that > are not based on a message-id, and could pollute the results with > inaccurate threading. > -- > Scott * If you contact me off list replace talklists@ with scott@ *
[twitter-dev] Re: Use Twitter for login & oauth/authenticate method
Ok, great. I'll let it check, so. By the way, OAuth is working like a charm here. Great job you did there! I'm happy to have finally switched to it. All the best, Arnaud. On Jul 1, 4:50 pm, Matt Sanford wrote: > Hi Arnaud, > > That option during application creation is really more trouble > that it is worth. Right now applications that have that option checked > include an extra sentence to tell users the application will be using > twitter for login, that's all. In the future we may restrict the / > oauth/authenticate call to applications that have specifically chosen > the option, so I recommend that any application using 'Sing in with > Twitter' check the check box. We're also working on redesigning the > authorization page and might do more with that value then. > We will announce before hand if we make any changes, like > requiring that value to use the authenticate method. It's not > something we'll definitely do but it is something that may come up in > the medium term you should be aware of. > > Thanks; > – Matt Sanford / @mzsanford > Twitter Dev > > On Jul 1, 2009, at 4:26 AM, Arnaud wrote: > > > > > > > Hello, > > > I’m using the oauth/authenticate method (one click login) and I was > > wondering if I had to check the "Use Twitter for login" option in my > > application options. The application is Browser based (using a > > callback URL) . > > > I’m quite confused with this option as I don’t really understand what > > it is standing for? > > > All the best, > > Arnaud.
[twitter-dev] daily follow/unfollow/update limit
I saw on the API documentation the daily limit is 1000 per day. But it seems its lower then that. Is it a %age based limit? Thanks Nayeem
[twitter-dev] Re: Twitter search XML Dataset
If you look at: http://apiwiki.twitter.com/Twitter-Search-API-Method%3A-search You will find that rpp only supports up to 100. Abraham On Wed, Jul 1, 2009 at 20:17, Raza wrote: > > Hello everyone > in my application i am trying to pull xml dataset using following link > > http://search.twitter.com/search.atom?lang=en&rpp=150&q=+google > > Problem is i cant get more than 100 results in the tables even though > i have given 150 rpp. can someone please explain why is that? > > > thanks > -- > Raza -- Abraham Williams | Community Evangelist | http://web608.org Hacker | http://abrah.am | http://twitter.com/abraham Project | http://fireeagle.labs.poseurtech.com This email is: [ ] blogable [x] ask first [ ] private.
[twitter-dev] Re: Search twitter for within certain timestamp
Hello, The maximum allowed value is 100. Check out the documentation at http://apiwiki.twitter.com/Twitter-Search-API-Method%3A-search Thanks; — Matt Sanford / @mzsanford On Jul 1, 2009, at 6:19 PM, Mehroz Raza wrote: Thanks for your replay guys i menage to it using Published feild in XML results. i have another problem if you guys can help me there. in my application i am trying to pull xml dataset using following link http://search.twitter.com/search.atom?lang=en&rpp=150&q=+google Problem is i cant get more than 100 results in the tables even though i have given 150 rpp. can you please explain why is that? On Tue, Jun 30, 2009 at 6:14 PM, Doug Williams wrote: Raza, Twitter search only gives since: and until: operators granularity at the day level. Any parsing on more specific (hour, day, second) timeframes is left to the client. Thanks, Doug On Tue, Jun 30, 2009 at 2:41 PM, Raza wrote: Hi, I am trying to search the twitter like http://search.twitter.com/search.atom?lang=en&q=+google+since%3A2009-06-30+until%3A2009-06-30+ what i want to do is to search giving date in the format -MM-DD HH:MI:SS... how can i do that? thanks Raza -- Best Regards, Muhammad Mahroze Raza, Software Engineer, The Resource Group (Private) Limited, Lahore, Pakistan. mailto:mahroze.r...@trgcustomersolutions.com Mob +92-322-4426410 P (Pak) +92-42-111-874-874 Ext 2617 P (US) +1-202-289-9898 Ext 2617
[twitter-dev] Re: Search twitter for within certain timestamp
Thanks for your replay guys i menage to it using Published feild in XML results. i have another problem if you guys can help me there. in my application i am trying to pull xml dataset using following link http://search.twitter.com/search.atom?lang=en&rpp=150&q=+google Problem is i cant get more than 100 results in the tables even though i have given 150 rpp. can you please explain why is that? On Tue, Jun 30, 2009 at 6:14 PM, Doug Williams wrote: > Raza, > Twitter search only gives since: and until: operators granularity at the > day level. Any parsing on more specific (hour, day, second) timeframes is > left to the client. > > Thanks, > Doug > > > > > > On Tue, Jun 30, 2009 at 2:41 PM, Raza wrote: > >> >> Hi, >> >> I am trying to search the twitter like >> >> >> http://search.twitter.com/search.atom?lang=en&q=+google+since%3A2009-06-30+until%3A2009-06-30+ >> >> what i want to do is to search giving date in the format -MM-DD >> HH:MI:SS... >> >> how can i do that? >> >> thanks >> Raza >> > > -- Best Regards, Muhammad Mahroze Raza, Software Engineer, The Resource Group (Private) Limited, Lahore, Pakistan. mailto:mahroze.r...@trgcustomersolutions.com Mob +92-322-4426410 P (Pak) +92-42-111-874-874 Ext 2617 P (US) +1-202-289-9898 Ext 2617
[twitter-dev] Twitter search XML Dataset
Hello everyone in my application i am trying to pull xml dataset using following link http://search.twitter.com/search.atom?lang=en&rpp=150&q=+google Problem is i cant get more than 100 results in the tables even though i have given 150 rpp. can someone please explain why is that? thanks -- Raza
[twitter-dev] Re: Profile image urls - how to update
Has there been any update or advance on how to keep Profile Images up to date? They're driving my nuts, especially with the Iran green- overlay nonsense. -fs On May 22, 12:36 pm, Ollie Parsley wrote: > Haven't figured out caching yet. Thats on the agenda after a weekend > break :) > > Ollie > > On May 22, 11:56 am, Neil Ellis wrote: > > > Good call Ollie, caching? > > > On 22 May 2009, at 11:11, Ollie Parsley wrote: > > > > I put a very quick app together called "Twavatars" that creates a > > > static URL to aprofileimage. The request does an API call and > > > streams the image from the S3 url. This does make theimagesload > > > slower but it is only a temporary solution untill there is an official > > > solution. So it is fine when displaying a couple of avatars, if you > > > displaying lots of avatars it will be tediously slow. > > > > My avatar (@ollieparsley) > > > ->http://twavatars.ollieparsley.com/user/10721822?s=thumb > > > orhttp://twavatars.ollieparsley.com/user/ollieparsley?s=normal > > > >http://twavatars.ollieparsley.comformore info if anyone is > > > interested. > > > > Ollie > > > > On May 22, 2:24 am, Abraham Williams <4bra...@gmail.com> wrote: > > >> Speaking of static avatar URLs... how about Gravatar[1] support? > > > >> [1]http://en.gravatar.com/ > > > >> On Thu, May 21, 2009 at 18:14, Doug Williams > > >> wrote: > > >>> Thanks for your patience guys -- we realize the benefits of > > >>> predictable > > >>> static URLs. It's unfortunately kind of back-burner work but we're > > >>> getting > > >>> to it. As most of you can tell, the image uploading logic needs a > > >>> lot of > > >>> love. > > >>> Cheers, > > >>> Doug > > > >>> -- > > > >>> Doug Williams > > >>> Twitter Platform Support > > >>>http://twitter.com/dougw > > > >>> On Thu, May 21, 2009 at 4:38 PM, Tim Haines > > >>> wrote: > > > Hi Clint, > > > Thanks for that. I've added myself to the watchlist. I saw a > > similar > > note from 2007, so was hoping it was already done - but 'a month or > > so' sounds good to me. > > > Tim. > > > On May 21, 10:24 pm, Clint Shryock wrote: > > > the API team is in the process of re-engineering this > > > functionality: in > > the > > > future the currentprofileimage will have a static URL.see: > > http://code.google.com/p/twitter-api/issues/detail?id=497#c8 > > > > +Clint > > > > On Thu, May 21, 2009 at 6:11 AM, Tim Haines > > > wrote: > > > >> Hey there, > > > >> I'm cachingprofileimage urls. I'm finding quite a bit of > > >> churn, and > > >> have started wondering how I'm going to keep them up to date. > > > >> Is there anyway to predict or determine aprofileimage url > > >> from a > > >> screen name or something? The url's provided all seem to > > >> contain part > > >> of the original file name - which of course is impossible to > > >> guess. > > > >> If there's not a way to determine them from the screen name, is > > >> there > > >> an easy way to get a bulk update of the image urls? > > > >> Cheers, > > > >> Tim. > > > >> -- > > >> Abraham Williams |http://the.hackerconundrum.com > > >> Hacker |http://abrah.am|http://twitter.com/abraham > > >> Project |http://fireeagle.labs.poseurtech.com > > >> This email is: [ ] blogable [x] ask first [ ] private. > > >> Sent from San Francisco, California, United States
[twitter-dev] Re: User Clone Profiles
Thanks On Jun 29, 3:10 am, Abraham Williams <4bra...@gmail.com> wrote: > Pretty much. > Usehttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-users%C2%A0show > to get all their profile info. > > > > On Sat, Jun 27, 2009 at 09:11, Slicey wrote: > > > I'm building a site which allows a user to add an audio clip to their > > twitter page. > > eg. A user types in their username and uploads an audio clip and the > > title. This then gets stored into a database, along with a unique > > generated number/letter code. > > I want it so a user can see their audio clip on their twitter page. So > > my question is, Is it possible to automatically clone the users > > twitter page just from their username? > > eg. The users profile will be accessible like this: > >http://mysite.co.uk/twitter.php?pwd=n41MO > > It will then generate their profile from the code in the database > > matching to the related username. > > > Is this possible? If so how? > > > Thanks. > > -- > Abraham Williams | Community Evangelist |http://web608.org > Hacker |http://abrah.am|http://twitter.com/abraham > Project |http://fireeagle.labs.poseurtech.com > This email is: [ ] blogable [x] ask first [ ] private.
[twitter-dev] Re: Tweet threading
Hope this is not out of line, but this list has been pretty busy lately in traffic, and I am looking for a little hand holding on tweet threading... so bump :) On Jun 30, 2009, at 3:53 PM, Scott Haneda wrote: I am finding near all apps I use with twitter in some way or another fail at threading a conversation. Anyone have pointers for how to do this, based on the current twitter API, and whatever bugs have been uncovered, perhaps with workarounds? Each tweet has a 'in_reply_to_status_id', if I understand, the existence of in_reply_to_status_id, means that the current tweet is a child of some parent. tweet: id = 1234 in_reply_to_status_id = 5678 In the above example, tweet #5678 would be the start of the conversation, and tweet #1234 would be the reply? What has me stumped: http://twitter.com/criticalmassey/status/2383870573 Clearly a reply to something @ahem said, which started here: http://twitter.com/Ahem/status/2382725245 However, if I search.twitter.com for @ahem, I can get this conversation: http://dl.getdropbox.com/u/340087/Drops/06.30.09/twitter-b06e01bd-154810.png But it is missing the parent, the start of the thread. I can see the master parent here: http://search.twitter.com/search?max_id=2410761989&page=2&q=+from%3Aahem&rpp=10 But threading is not an option. Having a hard time wrapping my head around what the limitations of threading are. Any suggestions on how to better understand this would be most appreciated. Ideally, what I am looking for, is to take any tweet, determine what other replies there are to it, and get back to the parent, displaying all children. I would like to avoid any ambiguous tweet searches that are not based on a message-id, and could pollute the results with inaccurate threading. -- Scott * If you contact me off list replace talklists@ with scott@ *
[twitter-dev] Re: off topic
Yep my mistake, will contact you off line. On 1 Jul 2009, at 20:38, Isaiah Carew wrote: yep, just me, thanks, isaiah p.s. subject changed to protect the on-topic folks. @isaiah for more. ;-) On Jul 1, 2009, at 12:27 PM, Neil Ellis wrote: On a completely separate note, your website is stunning, did you design it yourself? If not may I ask who were your designers. All the best Neil http://www.peepwl.com On 1 Jul 2009, at 20:22, Support wrote: Matt, Thanks for weighing in and hopefully taming this snarl. As the person who might have posed the question originally, I figured I at least owed a bit of constructive critique. What can we change about OAuth that would make this better? 1) User experience - it's been echoed a number of times in this board, so i won't beat the dead horse... much...but basic auth *is* much simpler for the user. The reason is obvious: oauth requires a browser. In many platforms (especially mobile) that's a painful burden. The PIN code seems to be ignoring the elephant in the room. It solves some problems, but at a further cost to the user experience, giving an even larger advantage to existing basic-auth apps. You've made the pill even more effective, but so bitter that your patients can't swallow it. Providing a scheme that does not require a browser is an obvious way to cut this gordian knot. 2) Application authentication - if your goal is to *identify* each open source application in a *trusted* way, then I think you could be in for an uphill battle. There are obvious technical challenges, however the larger problem is that in OSS there is no way to define "each application." There will be many binaries for different platforms and people will fork it on github just because they can. You cannot identify each of these variants as the same when they could be different. And that places a burden on the user experience. When a user grants access to "application x" -- what does that mean exactly? Just that binary? Just this release? Only from a specific trusted company? How do you explain to the user where this subtle line is drawn in a box he'll click through in less than a second? I personally don't see an obvious solution to this problem. It seems to be a UI challenge and a technical challenge. In cases like that it seems prudent to question your goals and check feasibility. Isaiah YourHead Software supp...@yourhead.com http://www.yourhead.com On Jul 1, 2009, at 9:46 AM, Matt Sanford wrote: Hello again, I do not recommend having individual end users register for consumer keys/secrets [1] under any circumstances. So, with that out of the way, let us focus the discussion a bit more. What can we change about OAuth that would make this better? A complete technical [2][3] discussion on what we could add that would make this better is welcomed. More than welcome, it's pretty much required before we can help. The PIN flow was the first addition to address the inherent insecurity of the consumer key/secret all desktop applications [3]. This stopped applications from being able to collect tokens by using the consumer key/secret and a confidence scam (phishing like "GoodApp needs you to re-approve us"). It sounds like there is a fervent need for something more … what do people suggest? We're working hard on the problem but many of you are working from the consumer standpoint and probably have great feedback. Please, take your time and write a well thought out reply. One- line snarky comments, while fun to write and sometimes to read, steal time from everyone reading the list, including all of the Twitter API engineers. They also make the list look less inviting to new comers. Thanks; – Matt Sanford / @mzsanford Twitter Dev [1] - People installing an instance of your server-side app are not 'end users', but other developers [2] - Not open-source hand waving. [3] - Closed source desktop apps have the same problem. Reverse engineering is not stopped when you don't include the source. On Jul 1, 2009, at 9:33 AM, DWRoelands wrote: Actually, since Twitter has said that Basic Auth will eventually go away, OAuth is going to be the only choice for authentication. Twitter has forced the choice by implementing OAuth in the way that they did. Why should a user who chooses to support open source by using an open- source Twitter client be punished by having to go through extra hoops that users of closed-source clients don't have to endure? Forcing users of open source Twitter clients to register their individual installations as Twitter applications is not a viable solution. Matt Sanford has even said so. No one is asking for "easy". I just want open source Twitter desktop clients to be able to compete with closed-source versions when it comes to security. Right now, that's not possible because of Twitter's implementat
[twitter-dev] Re: searching for stocktwits (searching for "$$")
Hi Ryan, The search.twitter.com system does not support $$ or a wild-card for all stock symbols. Thanks; – Matt Sanford / @mzsanford Twitter Dev On Jul 1, 2009, at 1:49 PM, Ryan wrote: I'm using the API and am trying to search for stocktwits (those tweets which contain the string "$$" or "$" followed by a ticker symbol). I can easily search for "$aapl" for example, and it works fine. But if I search for "$$" the API never returns any results, so I must be searching for it incorrectly. (Searching for "%24%24" doesn't work any better.) What is the correct string to search to get the desired result? Also is there a generic search term? as in "$***" where the asterisk is any character? Thanks for the help.
[twitter-dev] searching for stocktwits (searching for "$$")
I'm using the API and am trying to search for stocktwits (those tweets which contain the string "$$" or "$" followed by a ticker symbol). I can easily search for "$aapl" for example, and it works fine. But if I search for "$$" the API never returns any results, so I must be searching for it incorrectly. (Searching for "%24%24" doesn't work any better.) What is the correct string to search to get the desired result? Also is there a generic search term? as in "$***" where the asterisk is any character? Thanks for the help.
[twitter-dev] Re: off topic
yep, just me, thanks, isaiah p.s. subject changed to protect the on-topic folks. @isaiah for more. ;-) On Jul 1, 2009, at 12:27 PM, Neil Ellis wrote: On a completely separate note, your website is stunning, did you design it yourself? If not may I ask who were your designers. All the best Neil http://www.peepwl.com On 1 Jul 2009, at 20:22, Support wrote: Matt, Thanks for weighing in and hopefully taming this snarl. As the person who might have posed the question originally, I figured I at least owed a bit of constructive critique. What can we change about OAuth that would make this better? 1) User experience - it's been echoed a number of times in this board, so i won't beat the dead horse... much...but basic auth *is* much simpler for the user. The reason is obvious: oauth requires a browser. In many platforms (especially mobile) that's a painful burden. The PIN code seems to be ignoring the elephant in the room. It solves some problems, but at a further cost to the user experience, giving an even larger advantage to existing basic-auth apps. You've made the pill even more effective, but so bitter that your patients can't swallow it. Providing a scheme that does not require a browser is an obvious way to cut this gordian knot. 2) Application authentication - if your goal is to *identify* each open source application in a *trusted* way, then I think you could be in for an uphill battle. There are obvious technical challenges, however the larger problem is that in OSS there is no way to define "each application." There will be many binaries for different platforms and people will fork it on github just because they can. You cannot identify each of these variants as the same when they could be different. And that places a burden on the user experience. When a user grants access to "application x" -- what does that mean exactly? Just that binary? Just this release? Only from a specific trusted company? How do you explain to the user where this subtle line is drawn in a box he'll click through in less than a second? I personally don't see an obvious solution to this problem. It seems to be a UI challenge and a technical challenge. In cases like that it seems prudent to question your goals and check feasibility. Isaiah YourHead Software supp...@yourhead.com http://www.yourhead.com On Jul 1, 2009, at 9:46 AM, Matt Sanford wrote: Hello again, I do not recommend having individual end users register for consumer keys/secrets [1] under any circumstances. So, with that out of the way, let us focus the discussion a bit more. What can we change about OAuth that would make this better? A complete technical [2][3] discussion on what we could add that would make this better is welcomed. More than welcome, it's pretty much required before we can help. The PIN flow was the first addition to address the inherent insecurity of the consumer key/secret all desktop applications [3]. This stopped applications from being able to collect tokens by using the consumer key/secret and a confidence scam (phishing like "GoodApp needs you to re-approve us"). It sounds like there is a fervent need for something more … what do people suggest? We're working hard on the problem but many of you are working from the consumer standpoint and probably have great feedback. Please, take your time and write a well thought out reply. One- line snarky comments, while fun to write and sometimes to read, steal time from everyone reading the list, including all of the Twitter API engineers. They also make the list look less inviting to new comers. Thanks; – Matt Sanford / @mzsanford Twitter Dev [1] - People installing an instance of your server-side app are not 'end users', but other developers [2] - Not open-source hand waving. [3] - Closed source desktop apps have the same problem. Reverse engineering is not stopped when you don't include the source. On Jul 1, 2009, at 9:33 AM, DWRoelands wrote: Actually, since Twitter has said that Basic Auth will eventually go away, OAuth is going to be the only choice for authentication. Twitter has forced the choice by implementing OAuth in the way that they did. Why should a user who chooses to support open source by using an open- source Twitter client be punished by having to go through extra hoops that users of closed-source clients don't have to endure? Forcing users of open source Twitter clients to register their individual installations as Twitter applications is not a viable solution. Matt Sanford has even said so. No one is asking for "easy". I just want open source Twitter desktop clients to be able to compete with closed-source versions when it comes to security. Right now, that's not possible because of Twitter's implementation of OAuth. Regards, Duane On Jul 1, 11:23 am, Andrew Badera wrote: But that's the choice you'
[twitter-dev] Re: Security Best Practices
On Jul 1, 2009, at 10:17 AM, DWRoelands wrote: Mark, Thanks for weighing in. Much appreciated. Here are my thoughts. I see two separate issues here: User Authentication vs. Application Authentication. User Authentication: Ensuring that the Twitter user is who they say they are. Application Authentication: Ensuring that the Application is who it says it is (i.e. the tweet is really coming from "TweetDeck" and not some other application pretending to be TweetDeck). User Authentication: I understand that Basic Auth, as is, is not a secure solution. Transmitting unencrypted credentials in the clear is never a great idea. What about combining Basic Auth with a form of public/private key encryption? Using PGP as an example, Twitter could publish it's public PGP key. Applications using Basic Auth would have to encrypt the username and password with that key and submit the encrypted username and password as the Basic Auth credentials. Twitter decrypts them server side and processes authentication normally. Developers wouldn't have to include any sensitive information in their source code, and the credentials would always be transmitted in an encrypted fashion. PGP is a fairly robust standard, with lots of free resources available to the development community across many languages. Rather than breaking with the HTTP specification for Basic authentication we offer HTTP over SSL for encrypted access. That adds the benefits you enumerate above plus: * Requires very little coding from developers (most libraries support it) * Built on an open standard * Prevents re-using an Authentication header (even one encrypted) to essentially act like a user. * Bonus: Encrypts the contents so nobody else is reading your DMs on the wire Application Authentication: This is a thornier issue that I'm not sure how to solve without having to bundle some sort of sensitive information in the source code of an application. However, I think the issue becomes more manageable if User Authentication is separated from Application Authentication. This seems to be the crux of the issue from what I can tell. Isaiah from youhead enumerated some of the difficulties with that, especially for open source. I have no doubt that many of the folks on this list have good ideas on how to solve the second problem. Thoughts Regards, Duane On Jul 1, 12:46 pm, Matt Sanford wrote: Please, take your time and write a well thought out reply. One- line snarky comments, while fun to write and sometimes to read, steal time from everyone reading the list, including all of the Twitter API engineers. They also make the list look less inviting to new comers.
[twitter-dev] Re: Security Best Practices
On a completely separate note, your website is stunning, did you design it yourself? If not may I ask who were your designers. All the best Neil http://www.peepwl.com On 1 Jul 2009, at 20:22, Support wrote: > > Matt, > > Thanks for weighing in and hopefully taming this snarl. As the > person who might have posed the question originally, I figured I at > least owed a bit of constructive critique. > >> What can we change about OAuth that would make this better? > > 1) User experience - it's been echoed a number of times in this > board, so i won't beat the dead horse... much...but basic auth > *is* much simpler for the user. > The reason is obvious: oauth requires a browser. In many platforms > (especially mobile) that's a painful burden. > > The PIN code seems to be ignoring the elephant in the room. It > solves some problems, but at a further cost to the user experience, > giving an even larger advantage to existing basic-auth apps. > You've made the pill even more effective, but so bitter that your > patients can't swallow it. > > Providing a scheme that does not require a browser is an obvious way > to cut this gordian knot. > > > 2) Application authentication - if your goal is to *identify* each > open source application in a *trusted* way, then I think you could > be in for an uphill battle. There are obvious technical challenges, > however the larger problem is that in OSS there is no way to define > "each application." There will be many binaries for different > platforms and people will fork it on github just because they can. > You cannot identify each of these variants as the same when they > could be different. > > And that places a burden on the user experience. When a user grants > access to "application x" -- what does that mean exactly? Just that > binary? Just this release? Only from a specific trusted company? > How do you explain to the user where this subtle line is drawn in a > box he'll click through in less than a second? > > I personally don't see an obvious solution to this problem. It > seems to be a UI challenge and a technical challenge. In cases like > that it seems prudent to question your goals and check feasibility. > > > Isaiah > > YourHead Software > supp...@yourhead.com > http://www.yourhead.com > > > > On Jul 1, 2009, at 9:46 AM, Matt Sanford wrote: > >> >> Hello again, >> >>I do not recommend having individual end users register for >> consumer keys/secrets [1] under any circumstances. So, with that >> out of the way, let us focus the discussion a bit more. What can we >> change about OAuth that would make this better? A complete >> technical [2][3] discussion on what we could add that would make >> this better is welcomed. More than welcome, it's pretty much >> required before we can help. >>The PIN flow was the first addition to address the inherent >> insecurity of the consumer key/secret all desktop applications [3]. >> This stopped applications from being able to collect tokens by >> using the consumer key/secret and a confidence scam (phishing like >> "GoodApp needs you to re-approve us"). It sounds like there is a >> fervent need for something more … what do people suggest? We're >> working hard on the problem but many of you are working from the >> consumer standpoint and probably have great feedback. >>Please, take your time and write a well thought out reply. One- >> line snarky comments, while fun to write and sometimes to read, >> steal time from everyone reading the list, including all of the >> Twitter API engineers. They also make the list look less inviting >> to new comers. >> >> Thanks; >> – Matt Sanford / @mzsanford >> Twitter Dev >> >> [1] - People installing an instance of your server-side app are not >> 'end users', but other developers >> [2] - Not open-source hand waving. >> [3] - Closed source desktop apps have the same problem. Reverse >> engineering is not stopped when you don't include the source. >> >> On Jul 1, 2009, at 9:33 AM, DWRoelands wrote: >> >>> >>> Actually, since Twitter has said that Basic Auth will eventually go >>> away, OAuth is going to be the only choice for authentication. >>> Twitter has forced the choice by implementing OAuth in the way that >>> they did. >>> >>> Why should a user who chooses to support open source by using an >>> open- >>> source Twitter client be punished by having to go through extra >>> hoops >>> that users of closed-source clients don't have to endure? >>> >>> Forcing users of open source Twitter clients to register their >>> individual installations as Twitter applications is not a viable >>> solution. Matt Sanford has even said so. >>> >>> No one is asking for "easy". I just want open source Twitter >>> desktop >>> clients to be able to compete with closed-source versions when it >>> comes to security. Right now, that's not possible because of >>> Twitter's implementation
[twitter-dev] Re: Use Twitter for login & oauth/authenticate method
Super! Thanks, Isaiah YourHead Software supp...@yourhead.com http://www.yourhead.com On Jul 1, 2009, at 10:23 AM, Matt Sanford wrote: Hi there, A mobile version does not exist but it's on the roadmap. — Matt On Jul 1, 2009, at 10:21 AM, Isaiah Carew wrote: I'm still not sure I understand the option. Is there any reason why someone would choose NOT to check this box currently? Also, if you are in the process of redesigning the auth page, could I make a request: Could there be a super-lightweight version for mobile? No images, no scripts, inline css, fluid width, etc. Maybe it already exists and I'm doing something wrong. Feel free to point me in the right direction too. ;-) Isaiah On Jul 1, 2009, at 7:50 AM, Matt Sanford wrote: Hi Arnaud, That option during application creation is really more trouble that it is worth. Right now applications that have that option checked include an extra sentence to tell users the application will be using twitter for login, that's all. In the future we may restrict the /oauth/authenticate call to applications that have specifically chosen the option, so I recommend that any application using 'Sing in with Twitter' check the check box. We're also working on redesigning the authorization page and might do more with that value then. We will announce before hand if we make any changes, like requiring that value to use the authenticate method. It's not something we'll definitely do but it is something that may come up in the medium term you should be aware of. Thanks; – Matt Sanford / @mzsanford Twitter Dev On Jul 1, 2009, at 4:26 AM, Arnaud wrote: Hello, I’m using the oauth/authenticate method (one click login) and I was wondering if I had to check the "Use Twitter for login" option in my application options. The application is Browser based (using a callback URL) . I’m quite confused with this option as I don’t really understand what it is standing for? All the best, Arnaud.
[twitter-dev] Re: Security Best Practices
Matt, Thanks for weighing in and hopefully taming this snarl. As the person who might have posed the question originally, I figured I at least owed a bit of constructive critique. What can we change about OAuth that would make this better? 1) User experience - it's been echoed a number of times in this board, so i won't beat the dead horse... much...but basic auth *is* much simpler for the user. The reason is obvious: oauth requires a browser. In many platforms (especially mobile) that's a painful burden. The PIN code seems to be ignoring the elephant in the room. It solves some problems, but at a further cost to the user experience, giving an even larger advantage to existing basic-auth apps. You've made the pill even more effective, but so bitter that your patients can't swallow it. Providing a scheme that does not require a browser is an obvious way to cut this gordian knot. 2) Application authentication - if your goal is to *identify* each open source application in a *trusted* way, then I think you could be in for an uphill battle. There are obvious technical challenges, however the larger problem is that in OSS there is no way to define "each application." There will be many binaries for different platforms and people will fork it on github just because they can. You cannot identify each of these variants as the same when they could be different. And that places a burden on the user experience. When a user grants access to "application x" -- what does that mean exactly? Just that binary? Just this release? Only from a specific trusted company? How do you explain to the user where this subtle line is drawn in a box he'll click through in less than a second? I personally don't see an obvious solution to this problem. It seems to be a UI challenge and a technical challenge. In cases like that it seems prudent to question your goals and check feasibility. Isaiah YourHead Software supp...@yourhead.com http://www.yourhead.com On Jul 1, 2009, at 9:46 AM, Matt Sanford wrote: Hello again, I do not recommend having individual end users register for consumer keys/secrets [1] under any circumstances. So, with that out of the way, let us focus the discussion a bit more. What can we change about OAuth that would make this better? A complete technical [2][3] discussion on what we could add that would make this better is welcomed. More than welcome, it's pretty much required before we can help. The PIN flow was the first addition to address the inherent insecurity of the consumer key/secret all desktop applications [3]. This stopped applications from being able to collect tokens by using the consumer key/secret and a confidence scam (phishing like "GoodApp needs you to re-approve us"). It sounds like there is a fervent need for something more … what do people suggest? We're working hard on the problem but many of you are working from the consumer standpoint and probably have great feedback. Please, take your time and write a well thought out reply. One- line snarky comments, while fun to write and sometimes to read, steal time from everyone reading the list, including all of the Twitter API engineers. They also make the list look less inviting to new comers. Thanks; – Matt Sanford / @mzsanford Twitter Dev [1] - People installing an instance of your server-side app are not 'end users', but other developers [2] - Not open-source hand waving. [3] - Closed source desktop apps have the same problem. Reverse engineering is not stopped when you don't include the source. On Jul 1, 2009, at 9:33 AM, DWRoelands wrote: Actually, since Twitter has said that Basic Auth will eventually go away, OAuth is going to be the only choice for authentication. Twitter has forced the choice by implementing OAuth in the way that they did. Why should a user who chooses to support open source by using an open- source Twitter client be punished by having to go through extra hoops that users of closed-source clients don't have to endure? Forcing users of open source Twitter clients to register their individual installations as Twitter applications is not a viable solution. Matt Sanford has even said so. No one is asking for "easy". I just want open source Twitter desktop clients to be able to compete with closed-source versions when it comes to security. Right now, that's not possible because of Twitter's implementation of OAuth. Regards, Duane On Jul 1, 11:23 am, Andrew Badera wrote: But that's the choice you're forced to make by OAuth, not Twitter. And it is YOUR choice. Personally, I would probably use the conventional mechanisms of open source: mailing lists, special interest and user groups. Pound the pavement and promote yourself. Who said it was going to be "easy"?
[twitter-dev] Re: Use Twitter for login & oauth/authenticate method
Hi there, A mobile version does not exist but it's on the roadmap. — Matt On Jul 1, 2009, at 10:21 AM, Isaiah Carew wrote: I'm still not sure I understand the option. Is there any reason why someone would choose NOT to check this box currently? Also, if you are in the process of redesigning the auth page, could I make a request: Could there be a super-lightweight version for mobile? No images, no scripts, inline css, fluid width, etc. Maybe it already exists and I'm doing something wrong. Feel free to point me in the right direction too. ;-) Isaiah On Jul 1, 2009, at 7:50 AM, Matt Sanford wrote: Hi Arnaud, That option during application creation is really more trouble that it is worth. Right now applications that have that option checked include an extra sentence to tell users the application will be using twitter for login, that's all. In the future we may restrict the /oauth/authenticate call to applications that have specifically chosen the option, so I recommend that any application using 'Sing in with Twitter' check the check box. We're also working on redesigning the authorization page and might do more with that value then. We will announce before hand if we make any changes, like requiring that value to use the authenticate method. It's not something we'll definitely do but it is something that may come up in the medium term you should be aware of. Thanks; – Matt Sanford / @mzsanford Twitter Dev On Jul 1, 2009, at 4:26 AM, Arnaud wrote: Hello, I’m using the oauth/authenticate method (one click login) and I was wondering if I had to check the "Use Twitter for login" option in my application options. The application is Browser based (using a callback URL) . I’m quite confused with this option as I don’t really understand what it is standing for? All the best, Arnaud.
[twitter-dev] Re: Use Twitter for login & oauth/authenticate method
I'm still not sure I understand the option. Is there any reason why someone would choose NOT to check this box currently? Also, if you are in the process of redesigning the auth page, could I make a request: Could there be a super-lightweight version for mobile? No images, no scripts, inline css, fluid width, etc. Maybe it already exists and I'm doing something wrong. Feel free to point me in the right direction too. ;-) Isaiah On Jul 1, 2009, at 7:50 AM, Matt Sanford wrote: Hi Arnaud, That option during application creation is really more trouble that it is worth. Right now applications that have that option checked include an extra sentence to tell users the application will be using twitter for login, that's all. In the future we may restrict the /oauth/authenticate call to applications that have specifically chosen the option, so I recommend that any application using 'Sing in with Twitter' check the check box. We're also working on redesigning the authorization page and might do more with that value then. We will announce before hand if we make any changes, like requiring that value to use the authenticate method. It's not something we'll definitely do but it is something that may come up in the medium term you should be aware of. Thanks; – Matt Sanford / @mzsanford Twitter Dev On Jul 1, 2009, at 4:26 AM, Arnaud wrote: Hello, I’m using the oauth/authenticate method (one click login) and I was wondering if I had to check the "Use Twitter for login" option in my application options. The application is Browser based (using a callback URL) . I’m quite confused with this option as I don’t really understand what it is standing for? All the best, Arnaud.
[twitter-dev] Re: Security Best Practices
Mark, Thanks for weighing in. Much appreciated. Here are my thoughts. I see two separate issues here: User Authentication vs. Application Authentication. User Authentication: Ensuring that the Twitter user is who they say they are. Application Authentication: Ensuring that the Application is who it says it is (i.e. the tweet is really coming from "TweetDeck" and not some other application pretending to be TweetDeck). User Authentication: I understand that Basic Auth, as is, is not a secure solution. Transmitting unencrypted credentials in the clear is never a great idea. What about combining Basic Auth with a form of public/private key encryption? Using PGP as an example, Twitter could publish it's public PGP key. Applications using Basic Auth would have to encrypt the username and password with that key and submit the encrypted username and password as the Basic Auth credentials. Twitter decrypts them server side and processes authentication normally. Developers wouldn't have to include any sensitive information in their source code, and the credentials would always be transmitted in an encrypted fashion. PGP is a fairly robust standard, with lots of free resources available to the development community across many languages. Application Authentication: This is a thornier issue that I'm not sure how to solve without having to bundle some sort of sensitive information in the source code of an application. However, I think the issue becomes more manageable if User Authentication is separated from Application Authentication. I have no doubt that many of the folks on this list have good ideas on how to solve the second problem. Thoughts Regards, Duane On Jul 1, 12:46 pm, Matt Sanford wrote: > Please, take your time and write a well thought out reply. One- > line snarky comments, while fun to write and sometimes to read, steal > time from everyone reading the list, including all of the Twitter API > engineers. They also make the list look less inviting to new comers.
[twitter-dev] Re: How-To: Load the Twitter XML into a VB.Net XML Document...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 DWRoelands wrote: > Obrzut: > My application does exactly what you say is impossible. The user > authenticates via the web browser, then my desktop application > completes the process using the six-digit PIN. > > There's no need to "fix" any XML that comes from Twitter, and there's > no need to process any HTML from a web page. > > I'd be happy to help you work through the issues you're having with > your application, but please stop insisting that you're smarter than > everyone else here. > > Bojan: > Obrzut's right about the GetAccessToken() call in the Twarp code. > GetAccessToken accepts the PIN as an Int; that should be a string so > that leading zeroes don't get stripped. I haven't seen any PINs with > a leading zero, but that doesn't mean they don't occur. :) > > --Duane > > On Jul 1, 8:00 am, Obrzut wrote: >> If you state otherwise - that you CAN use a TCP Client after already >> authenticating your VB.Net web browser - you are wrong. Duane, That's right, I did not think about that. Alternatively, I could provide an overload that takes a string, and force the padding to 6 digits for the integer overloads. Operator overloading is a wonderful thing when it comes to providing choice. Regards, Bojan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJKS5eYAAoJEO4IwQyHg9AWuH0QAJesvMcj8aEwBKkVjhivSzsp Uq3y31Ad/IAlxQmbEH5b8uNGJSiYKFvXOHb4Dn9Lqlw69vj8A2CDASlzneX+k59G tfYEsTjTcsE5TFZXaWM0R0VNY6Y8OP6UkIKqRxYQhGpGuTXK2lO+SaiVizQ6rcWJ ZqDyOSAkJ/dKneqX7dBwlkC2dJ5YZeMKPKUByHa971not8KDEtTAq+mH9ONeO+SH tTl7evlErcPPsxvgI2emz0JWkBRRyRVcr1knPoYXm0wBmksErCLr64kofmIYaY8e obK2HRNv/EgeDVdN+HgfXVWGf1SPBf0lMpjKmJkW5TMUhVxl1SycxLgY8YXRGXtg Dmg7Qm+dVh0xfoDXTLGtshC154Cx4Xtnwr0DmwKG1s2U137+qaO4PJO+Vkiqbruc JBCDbtqUN+xsUhpDSWmiHXSFbq294D5qm+/7oZ0TytBgCQ8XYVA3evt8g4XZHQAr UlzJ6Uu1Foi2eoCRfnOMiup4iMBU6ZjJhFvir/pKGwbQLAKUeJjChAIx2UVMl0Z0 H/g2x1eIvCdKFsTfI/kio5qBmSQQr0EHMmPFThnkx0VnICkzTrTk+Q0Y+Fu0Ubm8 2jCr4hxGw6BIXONm9RnMhRWMHxpp3OndejX0E47qechJU4k5se2T7AlT1fLXUVjM J/YpImorghKzFV4AW8Ez =9XAP -END PGP SIGNATURE-
[twitter-dev] Re: Security Best Practices
I think this got lost under all the mess: On Wed, Jul 1, 2009 at 10:15, Abraham Williams<4bra...@gmail.com> wrote: > A technical solution I see working is a modified PIN flow where > instead of a 6 digit PIN the user gets a 20 character token that acts > as consumer token. No harder then using PIN flow but each desktop > install would have a unique consumer sub token that could still be > tied into the global consumer token. > > Abraham -- Abraham Williams | Community Evangelist | http://web608.org Hacker | http://abrah.am | http://twitter.com/abraham Project | http://fireeagle.labs.poseurtech.com This email is: [ ] blogable [x] ask first [ ] private.
[twitter-dev] Re: Security Best Practices
I'm not sure that Twitter exposes any API or web service that allows you to programatically register a new application (which you need to do to receive the Consumer Key and Consumer Key Secret). Even if you could, that still requires the end user to compile the source with a modified build process. Requiring Windows users to compile source code in order to use the app is not a great solution. Any solution to the problem should be as transparent to the user as possible. They shouldn't be burdened with extra steps or procedures because they chose an open source client. On Jul 1, 12:39 pm, Bruce Brown wrote: > How difficult is it to, as part of the build, check for a key file, if > it doesn't exist, go to Twitter and do the stuff to get the tokens, > parse the tokens and save in the key file, and then continue on with > the build. Seems easy enuff.
[twitter-dev] Re: Security Best Practices
Hello again, I do not recommend having individual end users register for consumer keys/secrets [1] under any circumstances. So, with that out of the way, let us focus the discussion a bit more. What can we change about OAuth that would make this better? A complete technical [2][3] discussion on what we could add that would make this better is welcomed. More than welcome, it's pretty much required before we can help. The PIN flow was the first addition to address the inherent insecurity of the consumer key/secret all desktop applications [3]. This stopped applications from being able to collect tokens by using the consumer key/secret and a confidence scam (phishing like "GoodApp needs you to re-approve us"). It sounds like there is a fervent need for something more … what do people suggest? We're working hard on the problem but many of you are working from the consumer standpoint and probably have great feedback. Please, take your time and write a well thought out reply. One- line snarky comments, while fun to write and sometimes to read, steal time from everyone reading the list, including all of the Twitter API engineers. They also make the list look less inviting to new comers. Thanks; – Matt Sanford / @mzsanford Twitter Dev [1] - People installing an instance of your server-side app are not 'end users', but other developers [2] - Not open-source hand waving. [3] - Closed source desktop apps have the same problem. Reverse engineering is not stopped when you don't include the source. On Jul 1, 2009, at 9:33 AM, DWRoelands wrote: Actually, since Twitter has said that Basic Auth will eventually go away, OAuth is going to be the only choice for authentication. Twitter has forced the choice by implementing OAuth in the way that they did. Why should a user who chooses to support open source by using an open- source Twitter client be punished by having to go through extra hoops that users of closed-source clients don't have to endure? Forcing users of open source Twitter clients to register their individual installations as Twitter applications is not a viable solution. Matt Sanford has even said so. No one is asking for "easy". I just want open source Twitter desktop clients to be able to compete with closed-source versions when it comes to security. Right now, that's not possible because of Twitter's implementation of OAuth. Regards, Duane On Jul 1, 11:23 am, Andrew Badera wrote: But that's the choice you're forced to make by OAuth, not Twitter. And it is YOUR choice. Personally, I would probably use the conventional mechanisms of open source: mailing lists, special interest and user groups. Pound the pavement and promote yourself. Who said it was going to be "easy"?
[twitter-dev] Re: Security Best Practices
How difficult is it to, as part of the build, check for a key file, if it doesn't exist, go to Twitter and do the stuff to get the tokens, parse the tokens and save in the key file, and then continue on with the build. Seems easy enuff. -- Bruce Sent from my iPhone On Jul 1, 2009, at 8:23 AM, Andrew Badera wrote: > > But that's the choice you're forced to make by OAuth, not Twitter. And > it is YOUR choice. Personally, I would probably use the conventional > mechanisms of open source: mailing lists, special interest and user > groups. Pound the pavement and promote yourself. Who said it was going > to be "easy"? > > > On Wed, Jul 1, 2009 at 11:22 AM, JDG wrote: >> The problem is that by everyone getting their own consumer keys, >> the source >> parameter will be different for every person. Now, I'm not >> interested in >> getting my name in lights in the Twitter world -- I could honestly >> care >> less. That said, if I'm going to spend a significant portion of my >> time >> creating an open source app for people to enjoy, I'd like for >> people to >> actually know that they can use it, and the source parameter is by >> far the >> easiest way to accomplish that. >> >> On Wed, Jul 1, 2009 at 09:10, Andrew Badera wrote: >>> >>> No one's snarking, but again, interesting you would interpret it >>> that way. >>> >>> Open source all you want, each person deploying an instance will >>> have >>> to get their own keys. What's so tough about that? >>> >>> >>> >>> On Wed, Jul 1, 2009 at 11:07 AM, >>> DWRoelands >>> wrote: Andrew, This isn't about credit in the source parameter. It's about application security. Twitter has stated that Basic Auth will eventually be deprecated. OAuth will eventually be the only method of authentication available. When that happens, developers of open source clients will be forced to reveal their Consumer Key Secret. This is a very real problem; open-source developers of desktop clients will have to reveal their Consumer Key Secret. Can we keep this discussion focused on the technical issues at hand, rather than snarking about one another's motives? It's not productive. Regards, Duane On Jul 1, 10:57 am, Andrew Badera wrote: > Not what I said in the least, but it's interesting that you should > interpret it that way. > > Re-read what I said. > > If someone is open sourcing something, in the true spirit of open > source, they shouldn't care about getting credit in the source > parameter. > > Thanks you and good night, I'm here all week, try the veal, don't > forget to tip your waitresses and angry developers. > > > > On Wed, Jul 1, 2009 at 10:50 AM, Cameron > Kaiser > wrote: > >>> Yes, but don't distribute it. Obviously config files are human >>> readable, but you blank out secrets before publishing them. > >>> People using open source libraries will have to get their own >>> keys. >>> So, either you really are contributing in the spirit of open >>> source, >>> and you don't care about getting credit, or you're doing it >>> for self >>> promotional purposes, and the conversation is moot anyhow. > >> That's an asinine statement. So everybody who doesn't make >> their open >> source software anonymous is a publicity whore? > >> -- >> >> personal:http://www.cameronkaiser.com/-- >> Cameron Kaiser * Floodgap Systems *www.floodgap.com* >> ckai...@floodgap.com >> -- In memory of John Banner >> --- >> >> >> >> -- >> Internets. Serious business. >>
[twitter-dev] Re: Security Best Practices
Actually, since Twitter has said that Basic Auth will eventually go away, OAuth is going to be the only choice for authentication. Twitter has forced the choice by implementing OAuth in the way that they did. Why should a user who chooses to support open source by using an open- source Twitter client be punished by having to go through extra hoops that users of closed-source clients don't have to endure? Forcing users of open source Twitter clients to register their individual installations as Twitter applications is not a viable solution. Matt Sanford has even said so. No one is asking for "easy". I just want open source Twitter desktop clients to be able to compete with closed-source versions when it comes to security. Right now, that's not possible because of Twitter's implementation of OAuth. Regards, Duane On Jul 1, 11:23 am, Andrew Badera wrote: > But that's the choice you're forced to make by OAuth, not Twitter. And > it is YOUR choice. Personally, I would probably use the conventional > mechanisms of open source: mailing lists, special interest and user > groups. Pound the pavement and promote yourself. Who said it was going > to be "easy"?
[twitter-dev] Re: Security Best Practices
But that's the choice you're forced to make by OAuth, not Twitter. And it is YOUR choice. Personally, I would probably use the conventional mechanisms of open source: mailing lists, special interest and user groups. Pound the pavement and promote yourself. Who said it was going to be "easy"? On Wed, Jul 1, 2009 at 11:22 AM, JDG wrote: > The problem is that by everyone getting their own consumer keys, the source > parameter will be different for every person. Now, I'm not interested in > getting my name in lights in the Twitter world -- I could honestly care > less. That said, if I'm going to spend a significant portion of my time > creating an open source app for people to enjoy, I'd like for people to > actually know that they can use it, and the source parameter is by far the > easiest way to accomplish that. > > On Wed, Jul 1, 2009 at 09:10, Andrew Badera wrote: >> >> No one's snarking, but again, interesting you would interpret it that way. >> >> Open source all you want, each person deploying an instance will have >> to get their own keys. What's so tough about that? >> >> >> >> On Wed, Jul 1, 2009 at 11:07 AM, DWRoelands >> wrote: >> > >> > Andrew, >> > >> > This isn't about credit in the source parameter. It's about >> > application security. >> > >> > Twitter has stated that Basic Auth will eventually be deprecated. >> > OAuth will eventually be the only method of authentication available. >> > When that happens, developers of open source clients will be forced to >> > reveal their Consumer Key Secret. >> > >> > This is a very real problem; open-source developers of desktop clients >> > will have to reveal their Consumer Key Secret. >> > >> > Can we keep this discussion focused on the technical issues at hand, >> > rather than snarking about one another's motives? It's not >> > productive. >> > >> > Regards, >> > Duane >> > >> > >> > On Jul 1, 10:57 am, Andrew Badera wrote: >> >> Not what I said in the least, but it's interesting that you should >> >> interpret it that way. >> >> >> >> Re-read what I said. >> >> >> >> If someone is open sourcing something, in the true spirit of open >> >> source, they shouldn't care about getting credit in the source >> >> parameter. >> >> >> >> Thanks you and good night, I'm here all week, try the veal, don't >> >> forget to tip your waitresses and angry developers. >> >> >> >> >> >> >> >> On Wed, Jul 1, 2009 at 10:50 AM, Cameron Kaiser >> >> wrote: >> >> >> >> >> Yes, but don't distribute it. Obviously config files are human >> >> >> readable, but you blank out secrets before publishing them. >> >> >> >> >> People using open source libraries will have to get their own keys. >> >> >> So, either you really are contributing in the spirit of open source, >> >> >> and you don't care about getting credit, or you're doing it for self >> >> >> promotional purposes, and the conversation is moot anyhow. >> >> >> >> > That's an asinine statement. So everybody who doesn't make their open >> >> > source software anonymous is a publicity whore? >> >> >> >> > -- >> >> > >> >> > personal:http://www.cameronkaiser.com/-- >> >> > Cameron Kaiser * Floodgap Systems *www.floodgap.com* >> >> > ckai...@floodgap.com >> >> > -- In memory of John Banner >> >> > --- >> > > > > > -- > Internets. Serious business. >
[twitter-dev] Re: Security Best Practices
The problem is that by everyone getting their own consumer keys, the source parameter will be different for every person. Now, I'm not interested in getting my name in lights in the Twitter world -- I could honestly care less. That said, if I'm going to spend a significant portion of my time creating an open source app for people to enjoy, I'd like for people to actually know that they can use it, and the source parameter is by far the easiest way to accomplish that. On Wed, Jul 1, 2009 at 09:10, Andrew Badera wrote: > > No one's snarking, but again, interesting you would interpret it that way. > > Open source all you want, each person deploying an instance will have > to get their own keys. What's so tough about that? > > > > On Wed, Jul 1, 2009 at 11:07 AM, DWRoelands > wrote: > > > > Andrew, > > > > This isn't about credit in the source parameter. It's about > > application security. > > > > Twitter has stated that Basic Auth will eventually be deprecated. > > OAuth will eventually be the only method of authentication available. > > When that happens, developers of open source clients will be forced to > > reveal their Consumer Key Secret. > > > > This is a very real problem; open-source developers of desktop clients > > will have to reveal their Consumer Key Secret. > > > > Can we keep this discussion focused on the technical issues at hand, > > rather than snarking about one another's motives? It's not > > productive. > > > > Regards, > > Duane > > > > > > On Jul 1, 10:57 am, Andrew Badera wrote: > >> Not what I said in the least, but it's interesting that you should > >> interpret it that way. > >> > >> Re-read what I said. > >> > >> If someone is open sourcing something, in the true spirit of open > >> source, they shouldn't care about getting credit in the source > >> parameter. > >> > >> Thanks you and good night, I'm here all week, try the veal, don't > >> forget to tip your waitresses and angry developers. > >> > >> > >> > >> On Wed, Jul 1, 2009 at 10:50 AM, Cameron Kaiser > wrote: > >> > >> >> Yes, but don't distribute it. Obviously config files are human > >> >> readable, but you blank out secrets before publishing them. > >> > >> >> People using open source libraries will have to get their own keys. > >> >> So, either you really are contributing in the spirit of open source, > >> >> and you don't care about getting credit, or you're doing it for self > >> >> promotional purposes, and the conversation is moot anyhow. > >> > >> > That's an asinine statement. So everybody who doesn't make their open > >> > source software anonymous is a publicity whore? > >> > >> > -- > >> > personal: > http://www.cameronkaiser.com/-- > >> > Cameron Kaiser * Floodgap Systems *www.floodgap.com* > ckai...@floodgap.com > >> > -- In memory of John Banner > --- > > > -- Internets. Serious business.
[twitter-dev] Re: Security Best Practices
Nancy, You're right - it is a bad idea. However, it appears to be the only option that Twitter has left to open-source developers who wish to implement OAuth. There doesn't seem to be any way around distributing my application's Consumer Key Secret. Regards, Duane On Jul 1, 11:17 am, Nancy Miracle wrote: > Sounds like the assumption is that part of the keypair is in the > source. That is clearly a bad idea ... The software should obly > provide for processes and not ever content > > Sent from my iPhone > > On Jul 1, 2009, at 11:10 AM, Andrew Badera wrote: > > > > > > > No one's snarking, but again, interesting you would interpret it > > that way. > > > Open source all you want, each person deploying an instance will have > > to get their own keys. What's so tough about that? > > > On Wed, Jul 1, 2009 at 11:07 AM, > > DWRoelands wrote: > > >> Andrew, > > >> This isn't about credit in the source parameter. It's about > >> application security. > > >> Twitter has stated that Basic Auth will eventually be deprecated. > >> OAuth will eventually be the only method of authentication available. > >> When that happens, developers of open source clients will be forced > >> to > >> reveal their Consumer Key Secret. > > >> This is a very real problem; open-source developers of desktop > >> clients > >> will have to reveal their Consumer Key Secret. > > >> Can we keep this discussion focused on the technical issues at hand, > >> rather than snarking about one another's motives? It's not > >> productive. > > >> Regards, > >> Duane > > >> On Jul 1, 10:57 am, Andrew Badera wrote: > >>> Not what I said in the least, but it's interesting that you should > >>> interpret it that way. > > >>> Re-read what I said. > > >>> If someone is open sourcing something, in the true spirit of open > >>> source, they shouldn't care about getting credit in the source > >>> parameter. > > >>> Thanks you and good night, I'm here all week, try the veal, don't > >>> forget to tip your waitresses and angry developers. > > >>> On Wed, Jul 1, 2009 at 10:50 AM, Cameron > >>> Kaiser wrote: > > > Yes, but don't distribute it. Obviously config files are human > > readable, but you blank out secrets before publishing them. > > > People using open source libraries will have to get their own > > keys. > > So, either you really are contributing in the spirit of open > > source, > > and you don't care about getting credit, or you're doing it for > > self > > promotional purposes, and the conversation is moot anyhow. > > That's an asinine statement. So everybody who doesn't make their > open > source software anonymous is a publicity whore? > > -- > > personal:http://www.cameronkaiser.com/-- > Cameron Kaiser * Floodgap Systems *www.floodgap.com* > ckai...@floodgap.com > -- In memory of John Banner > ---
[twitter-dev] Re: Security Best Practices
Sounds like the assumption is that part of the keypair is in the source. That is clearly a bad idea ... The software should obly provide for processes and not ever content Sent from my iPhone On Jul 1, 2009, at 11:10 AM, Andrew Badera wrote: No one's snarking, but again, interesting you would interpret it that way. Open source all you want, each person deploying an instance will have to get their own keys. What's so tough about that? On Wed, Jul 1, 2009 at 11:07 AM, DWRoelands wrote: Andrew, This isn't about credit in the source parameter. It's about application security. Twitter has stated that Basic Auth will eventually be deprecated. OAuth will eventually be the only method of authentication available. When that happens, developers of open source clients will be forced to reveal their Consumer Key Secret. This is a very real problem; open-source developers of desktop clients will have to reveal their Consumer Key Secret. Can we keep this discussion focused on the technical issues at hand, rather than snarking about one another's motives? It's not productive. Regards, Duane On Jul 1, 10:57 am, Andrew Badera wrote: Not what I said in the least, but it's interesting that you should interpret it that way. Re-read what I said. If someone is open sourcing something, in the true spirit of open source, they shouldn't care about getting credit in the source parameter. Thanks you and good night, I'm here all week, try the veal, don't forget to tip your waitresses and angry developers. On Wed, Jul 1, 2009 at 10:50 AM, Cameron Kaiser wrote: Yes, but don't distribute it. Obviously config files are human readable, but you blank out secrets before publishing them. People using open source libraries will have to get their own keys. So, either you really are contributing in the spirit of open source, and you don't care about getting credit, or you're doing it for self promotional purposes, and the conversation is moot anyhow. That's an asinine statement. So everybody who doesn't make their open source software anonymous is a publicity whore? -- personal:http://www.cameronkaiser.com/-- Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com -- In memory of John Banner ---
[twitter-dev] Re: Security Best Practices
A technical solution I see working is a modified PIN flow where instead of a 6 digit PIN the user gets a 20 character token that acts as consumer token. No harder then using PIN flow but each desktop install would have a unique consumer sub token that could still be tied into the global consumer token. Abraham On Wed, Jul 1, 2009 at 10:11, Andrew Badera wrote: > > Amen and thank you Matt. > > > On Wed, Jul 1, 2009 at 11:09 AM, Matt Sanford wrote: >> >> >> On Jul 1, 2009, at 5:10 AM, Philip Plante wrote: >> >>> >>> I do not feel you've made a mountain out of a mole hill here. This >>> topic has been on my mind since I first encountered oAuth. I haven't >>> seen any open source apps use oAuth yet. >>> >>> We have an open source application called Application X. The >>> potential risk is that Application X becomes widely adopted, thus >>> having a higher risk of being impersonated. For instance, malware >>> could then use the tokens from Application X to obtain authorization >>> from Twitter. This would require the user to authorize the >>> impersonator via Twitter since it is likely a new session token would >>> be generated. Potentially the user would likely trust this >>> impersonator and not think twice about authorizing it because they >>> will see "Application X" on Twitter.com. Once they click allow the >>> impersonator has control of their account. Even if the malware >>> doesn't spread quickly it would possibly be harder to track since it >>> would appear to be communications from Application X. >> >> One thing the above description leaves out is that not only would the >> user have to approve the application, but that since it is a desktop >> application they would have to type the PIN number back into the >> MalewareApp. Perhaps the PIN-flow for desktop applications was not taken >> into account, or maybe the wording on the PIN pages should be stronger, but >> that's pretty much why we added the PIN flow. >> In my mind server-side applications should not publish a consumer >> key/secret. There is an assumption here that anyone savvy enough to install >> your wildly successful open source server-side application can register a >> key/secret … and that they probably want callbacks going to the correct >> site. This is not unlike the current Twitter/OAuth libraries, which all >> require you to get your own key. >> >> >>> >>> I am not one to cry fowl over an issue like this, just merely throwing >>> this out here as an idea. Anyone else have any ideas how to secure >>> open source oAuth apps? >>> >>> On Jul 1, 6:24 am, DWRoelands wrote: It seems as though revealing the Consumer Key and Consumer Key Secret of my application would be a pretty serious security risk. Anyone could write an application that impersonates mine, but they still would need an authorized user's Token and Token Secret in order to commit mischief. What sort of nastiness could one do in the Twitter environment with someone else's Consumer Key and Consumer Key Secret? Am I making a mountain out of a molehill here? If this is not a big deal, I'd like to hear so so I can continue working on my project as an open source endeavor. If this is a serious security issue, then I have to close the source for my project (and obfuscate the source). --Duane On Jun 30, 9:29 pm, Alex Payne wrote: > That's a solution that better fits open source Twitter web services. For > an > open source desktop client like Spaz it certainly doesn't work. > On Tue, Jun 30, 2009 at 16:37, DWRoelands > wrote: >> Wait, the solution is that every -user- of an open-source Twitter >> client would have to register for their own set of -consumer- keys? >> That's not what you meant, is it? >> On Jun 30, 4:39 pm, Alex Payne wrote: >>> >>> The simplest solution is that every deployment of the tool will have >>> to >>> register for their own OAuth credentials. This isn't ideal. I'd >>> inquire >> >> over >>> >>> athttp://groups.google.com/group/oauth >>> On Tue, Jun 30, 2009 at 06:04, DWRoelands >> >> wrote: This is really an excellent question. If we're developing an open-source Twitter client, how are we supposed to handle the consumer_key and consumer_key_secret? On Jun 29, 7:58 pm, Support wrote: > > 2. Obfuscation of the application's registered "key" and "secret." > Are there any best practices? What about an open source project? >>> -- >>> Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x > -- > Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x >> >> > -- Abraham Williams | Community Evangelist | http://web608.org Hacker | http://abrah.am | http://twitter.com/abraham Project | http://fireea
[twitter-dev] Re: How-To: Load the Twitter XML into a VB.Net XML Document...
If you force datatyping to alpha, six chars, this will be a nonproblem Sent from my iPhone On Jul 1, 2009, at 8:00 AM, Obrzut wrote: > > Did I state otherwise? > > You are not reading my words - you are being blinded by the noise from > your own head. > > What I stated is this; > > I authenticate my VB.NET web browser via PIN etc > > THIS means my browser is authenticated. > > If I try to access a page via the program with a TCP Client - I have > to re-authenticate via PIN. > > This WAS a problem - my solution is to continue to use the web browser > for authentication and extract the XML pages into an XML Document. > > Hence the above code. > > If you state otherwise - that you CAN use a TCP Client after already > authenticating your VB.Net web browser - you are wrong. > > I imagine you think I am wrong - and that I am an idiot. Believe me - > I am very skilled at programming. And this is my experience. > > The library is faulty. It does not process leading zero pins. > > The OAuth implementation is stupid - because it does not authenticate > an program but a TCP method. > > Hence, you guys are s off the mark here it hurts me to talk to > you. > > Really, srsly, it's pathetic that you DO NOT LISTEN. > > On Jul 1, 4:58 am, DWRoelands wrote: >> You can absolutely authenticate in a web page, even if your >> application is not a web application. Mine works that way. >> >> Here's how it should go. Bojan, please correct me if I'm wrong. >> >> 1. Your application calls GetAuthorizationLink() to get the URL of >> the >> authorization page (you've got this already). >> 2. Your application opens a web browser to that link. In .NET, you >> can do this with Process.Start(The URL that you get from >> GetAuthorizationLink). >> 3. The user sees the six-digit PIN on the screen. >> 4. Your application prompts the user to enter the six-digit PIN that >> they see. >> 5. Your application calls GetAccessToken(), passing the six-digit PIN >> as the input parameter. >> 6. The OAuth object has two properties that should now be populated: >> Token and TokenSecret. These are the items you will use for all >> subsequent OAuth requests to Twitter. >> >> Your application should now be authorized via OAuth. >> >> On Jun 30, 8:58 pm, Obrzut wrote: >> >> >> >>> This is because of OAuth. It uses HTML pages to validate. Perhaps >>> I am >>> wrong - but once I use a web browser to validate - I cannot use a >>> TCP >>> Client to get the XML because I authenticated via a web browser. >>> When >>> I tried to (for example) send the pin back via a HTTP Web Request it >>> failed. I am not sure if I am using the OAuth library Interface >>> Class >>> I have for VB.NET correctly!?
[twitter-dev] Re: Security Best Practices
Amen and thank you Matt. On Wed, Jul 1, 2009 at 11:09 AM, Matt Sanford wrote: > > > On Jul 1, 2009, at 5:10 AM, Philip Plante wrote: > >> >> I do not feel you've made a mountain out of a mole hill here. This >> topic has been on my mind since I first encountered oAuth. I haven't >> seen any open source apps use oAuth yet. >> >> We have an open source application called Application X. The >> potential risk is that Application X becomes widely adopted, thus >> having a higher risk of being impersonated. For instance, malware >> could then use the tokens from Application X to obtain authorization >> from Twitter. This would require the user to authorize the >> impersonator via Twitter since it is likely a new session token would >> be generated. Potentially the user would likely trust this >> impersonator and not think twice about authorizing it because they >> will see "Application X" on Twitter.com. Once they click allow the >> impersonator has control of their account. Even if the malware >> doesn't spread quickly it would possibly be harder to track since it >> would appear to be communications from Application X. > > One thing the above description leaves out is that not only would the > user have to approve the application, but that since it is a desktop > application they would have to type the PIN number back into the > MalewareApp. Perhaps the PIN-flow for desktop applications was not taken > into account, or maybe the wording on the PIN pages should be stronger, but > that's pretty much why we added the PIN flow. > In my mind server-side applications should not publish a consumer > key/secret. There is an assumption here that anyone savvy enough to install > your wildly successful open source server-side application can register a > key/secret … and that they probably want callbacks going to the correct > site. This is not unlike the current Twitter/OAuth libraries, which all > require you to get your own key. > > >> >> I am not one to cry fowl over an issue like this, just merely throwing >> this out here as an idea. Anyone else have any ideas how to secure >> open source oAuth apps? >> >> On Jul 1, 6:24 am, DWRoelands wrote: >>> >>> It seems as though revealing the Consumer Key and Consumer Key Secret >>> of my application would be a pretty serious security risk. Anyone >>> could write an application that impersonates mine, but they still >>> would need an authorized user's Token and Token Secret in order to >>> commit mischief. >>> >>> What sort of nastiness could one do in the Twitter environment with >>> someone else's Consumer Key and Consumer Key Secret? >>> >>> Am I making a mountain out of a molehill here? If this is not a big >>> deal, I'd like to hear so so I can continue working on my project as >>> an open source endeavor. If this is a serious security issue, then I >>> have to close the source for my project (and obfuscate the source). >>> >>> --Duane >>> >>> On Jun 30, 9:29 pm, Alex Payne wrote: >>> >>> >>> That's a solution that better fits open source Twitter web services. For an open source desktop client like Spaz it certainly doesn't work. >>> On Tue, Jun 30, 2009 at 16:37, DWRoelands wrote: >>> > Wait, the solution is that every -user- of an open-source Twitter > client would have to register for their own set of -consumer- keys? >>> > That's not what you meant, is it? >>> > On Jun 30, 4:39 pm, Alex Payne wrote: >> >> The simplest solution is that every deployment of the tool will have >> to >> register for their own OAuth credentials. This isn't ideal. I'd >> inquire > > over >> >> athttp://groups.google.com/group/oauth >>> >> On Tue, Jun 30, 2009 at 06:04, DWRoelands > > wrote: >>> >>> This is really an excellent question. >>> >>> If we're developing an open-source Twitter client, how are we >>> supposed >>> to handle the consumer_key and consumer_key_secret? >>> >>> On Jun 29, 7:58 pm, Support wrote: 2. Obfuscation of the application's registered "key" and "secret." Are there any best practices? What about an open source project? >>> >> -- >> Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x >>> -- Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x > >
[twitter-dev] Re: Security Best Practices
Wow, so that's what our development list (and Stallman's name) have come to. Please don't make me close this thread. Let's keep is friendly and focused. — Matt On Jul 1, 2009, at 8:01 AM, Cameron Kaiser wrote: Not what I said in the least, but it's interesting that you should interpret it that way. Re-read what I said. If someone is open sourcing something, in the true spirit of open source, they shouldn't care about getting credit in the source parameter. Tell that to Richard Stallman. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Another visitor. Stay awhile. Stay forever! -- Professor Elvin Atombender --
[twitter-dev] Re: Security Best Practices
No one's snarking, but again, interesting you would interpret it that way. Open source all you want, each person deploying an instance will have to get their own keys. What's so tough about that? On Wed, Jul 1, 2009 at 11:07 AM, DWRoelands wrote: > > Andrew, > > This isn't about credit in the source parameter. It's about > application security. > > Twitter has stated that Basic Auth will eventually be deprecated. > OAuth will eventually be the only method of authentication available. > When that happens, developers of open source clients will be forced to > reveal their Consumer Key Secret. > > This is a very real problem; open-source developers of desktop clients > will have to reveal their Consumer Key Secret. > > Can we keep this discussion focused on the technical issues at hand, > rather than snarking about one another's motives? It's not > productive. > > Regards, > Duane > > > On Jul 1, 10:57 am, Andrew Badera wrote: >> Not what I said in the least, but it's interesting that you should >> interpret it that way. >> >> Re-read what I said. >> >> If someone is open sourcing something, in the true spirit of open >> source, they shouldn't care about getting credit in the source >> parameter. >> >> Thanks you and good night, I'm here all week, try the veal, don't >> forget to tip your waitresses and angry developers. >> >> >> >> On Wed, Jul 1, 2009 at 10:50 AM, Cameron Kaiser wrote: >> >> >> Yes, but don't distribute it. Obviously config files are human >> >> readable, but you blank out secrets before publishing them. >> >> >> People using open source libraries will have to get their own keys. >> >> So, either you really are contributing in the spirit of open source, >> >> and you don't care about getting credit, or you're doing it for self >> >> promotional purposes, and the conversation is moot anyhow. >> >> > That's an asinine statement. So everybody who doesn't make their open >> > source software anonymous is a publicity whore? >> >> > -- >> > >> > personal:http://www.cameronkaiser.com/-- >> > Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com >> > -- In memory of John Banner >> > --- >
[twitter-dev] Re: Security Best Practices
On Jul 1, 2009, at 5:10 AM, Philip Plante wrote: I do not feel you've made a mountain out of a mole hill here. This topic has been on my mind since I first encountered oAuth. I haven't seen any open source apps use oAuth yet. We have an open source application called Application X. The potential risk is that Application X becomes widely adopted, thus having a higher risk of being impersonated. For instance, malware could then use the tokens from Application X to obtain authorization from Twitter. This would require the user to authorize the impersonator via Twitter since it is likely a new session token would be generated. Potentially the user would likely trust this impersonator and not think twice about authorizing it because they will see "Application X" on Twitter.com. Once they click allow the impersonator has control of their account. Even if the malware doesn't spread quickly it would possibly be harder to track since it would appear to be communications from Application X. One thing the above description leaves out is that not only would the user have to approve the application, but that since it is a desktop application they would have to type the PIN number back into the MalewareApp. Perhaps the PIN-flow for desktop applications was not taken into account, or maybe the wording on the PIN pages should be stronger, but that's pretty much why we added the PIN flow. In my mind server-side applications should not publish a consumer key/secret. There is an assumption here that anyone savvy enough to install your wildly successful open source server-side application can register a key/secret … and that they probably want callbacks going to the correct site. This is not unlike the current Twitter/OAuth libraries, which all require you to get your own key. I am not one to cry fowl over an issue like this, just merely throwing this out here as an idea. Anyone else have any ideas how to secure open source oAuth apps? On Jul 1, 6:24 am, DWRoelands wrote: It seems as though revealing the Consumer Key and Consumer Key Secret of my application would be a pretty serious security risk. Anyone could write an application that impersonates mine, but they still would need an authorized user's Token and Token Secret in order to commit mischief. What sort of nastiness could one do in the Twitter environment with someone else's Consumer Key and Consumer Key Secret? Am I making a mountain out of a molehill here? If this is not a big deal, I'd like to hear so so I can continue working on my project as an open source endeavor. If this is a serious security issue, then I have to close the source for my project (and obfuscate the source). --Duane On Jun 30, 9:29 pm, Alex Payne wrote: That's a solution that better fits open source Twitter web services. For an open source desktop client like Spaz it certainly doesn't work. On Tue, Jun 30, 2009 at 16:37, DWRoelands wrote: Wait, the solution is that every -user- of an open-source Twitter client would have to register for their own set of -consumer- keys? That's not what you meant, is it? On Jun 30, 4:39 pm, Alex Payne wrote: The simplest solution is that every deployment of the tool will have to register for their own OAuth credentials. This isn't ideal. I'd inquire over athttp://groups.google.com/group/oauth On Tue, Jun 30, 2009 at 06:04, DWRoelands wrote: This is really an excellent question. If we're developing an open-source Twitter client, how are we supposed to handle the consumer_key and consumer_key_secret? On Jun 29, 7:58 pm, Support wrote: 2. Obfuscation of the application's registered "key" and "secret." Are there any best practices? What about an open source project? -- Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x
[twitter-dev] Re: Security Best Practices
Andrew, This isn't about credit in the source parameter. It's about application security. Twitter has stated that Basic Auth will eventually be deprecated. OAuth will eventually be the only method of authentication available. When that happens, developers of open source clients will be forced to reveal their Consumer Key Secret. This is a very real problem; open-source developers of desktop clients will have to reveal their Consumer Key Secret. Can we keep this discussion focused on the technical issues at hand, rather than snarking about one another's motives? It's not productive. Regards, Duane On Jul 1, 10:57 am, Andrew Badera wrote: > Not what I said in the least, but it's interesting that you should > interpret it that way. > > Re-read what I said. > > If someone is open sourcing something, in the true spirit of open > source, they shouldn't care about getting credit in the source > parameter. > > Thanks you and good night, I'm here all week, try the veal, don't > forget to tip your waitresses and angry developers. > > > > On Wed, Jul 1, 2009 at 10:50 AM, Cameron Kaiser wrote: > > >> Yes, but don't distribute it. Obviously config files are human > >> readable, but you blank out secrets before publishing them. > > >> People using open source libraries will have to get their own keys. > >> So, either you really are contributing in the spirit of open source, > >> and you don't care about getting credit, or you're doing it for self > >> promotional purposes, and the conversation is moot anyhow. > > > That's an asinine statement. So everybody who doesn't make their open > > source software anonymous is a publicity whore? > > > -- > > > > personal:http://www.cameronkaiser.com/-- > > Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com > > -- In memory of John Banner > > ---
[twitter-dev] Re: Security Best Practices
> Not what I said in the least, but it's interesting that you should > interpret it that way. > > Re-read what I said. > > If someone is open sourcing something, in the true spirit of open > source, they shouldn't care about getting credit in the source > parameter. Tell that to Richard Stallman. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Another visitor. Stay awhile. Stay forever! -- Professor Elvin Atombender --
[twitter-dev] Re: Security Best Practices
Not what I said in the least, but it's interesting that you should interpret it that way. Re-read what I said. If someone is open sourcing something, in the true spirit of open source, they shouldn't care about getting credit in the source parameter. Thanks you and good night, I'm here all week, try the veal, don't forget to tip your waitresses and angry developers. On Wed, Jul 1, 2009 at 10:50 AM, Cameron Kaiser wrote: > >> Yes, but don't distribute it. Obviously config files are human >> readable, but you blank out secrets before publishing them. >> >> People using open source libraries will have to get their own keys. >> So, either you really are contributing in the spirit of open source, >> and you don't care about getting credit, or you're doing it for self >> promotional purposes, and the conversation is moot anyhow. > > That's an asinine statement. So everybody who doesn't make their open > source software anonymous is a publicity whore? > > -- > personal: http://www.cameronkaiser.com/ > -- > Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com > -- In memory of John Banner > --- >
[twitter-dev] Re: Security Best Practices
> The worst that happens if you publish the consumer tokens in an > opensouce app is someone malicious uses it to abuse Twitter and the > consumer token gets banned. At which point you regenerate a new one > and push a new version of the app. The cycle may or may not start > again depending on the malicious party. > > They can not act upon user accounts without the users going through > the authorize flow. Using basic auth it is already possible to use any > source and "impersonate" another application so not much is changing > here except better security for web applications. But the situation you state above is a bigger price to pay than if an app is impersonated via basic auth. In basic auth, it's simply cosmetic. In OAuth, you can certainly cause no small amount of turmoil by forcing open source apps to push out new versions by no fault of their own. That's not exactly an even playing field. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Man who live in glass house dress in basement. -
[twitter-dev] Re: Security Best Practices
Andrew, I'm not talking about a -library-. I'm talking about a -client-. If I want to produce a Twitter client, it needs its own Consumer Key and Consumer Key Secret. If want to share the source code for that client, I will also have to share it's Consumer Key and Consumer Key Secret. You seem to know what you're talking about; perhaps you have a solution. I have written a Twitter client. This client is registered with Twitter for OAuth. How do I share the source code without exposing the Consumer Key Secret and still allow the end users to authenticate? Regards, Duane On Jul 1, 10:48 am, Andrew Badera wrote: > Yes, but don't distribute it. Obviously config files are human > readable, but you blank out secrets before publishing them. > > People using open source libraries will have to get their own keys. > So, either you really are contributing in the spirit of open source, > and you don't care about getting credit, or you're doing it for self > promotional purposes, and the conversation is moot anyhow. > > "You" being any person worried about keys and open sourcing their libraries. > > > > On Wed, Jul 1, 2009 at 10:39 AM, Cameron Kaiser wrote: > > >> The secret should not reside in code. The secret should reside in a > >> config file, or maybe even a machine datastore. Abstract it out, no > >> one ever needs to see anything secret in your code. > > > That's not workable. It has to be publicly accessible somehow. > > > -- > > > > personal:http://www.cameronkaiser.com/-- > > Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com > > -- He hadn't a single redeeming vice. -- Oscar Wilde > > --
[twitter-dev] Re: Security Best Practices
There's a difference between sending out an open source library and an open source APPLICATION, which requires a key be used for identification and source. On Wed, Jul 1, 2009 at 08:48, Andrew Badera wrote: > > Yes, but don't distribute it. Obviously config files are human > readable, but you blank out secrets before publishing them. > > People using open source libraries will have to get their own keys. > So, either you really are contributing in the spirit of open source, > and you don't care about getting credit, or you're doing it for self > promotional purposes, and the conversation is moot anyhow. > > "You" being any person worried about keys and open sourcing their > libraries. > > > On Wed, Jul 1, 2009 at 10:39 AM, Cameron Kaiser > wrote: > > > >> The secret should not reside in code. The secret should reside in a > >> config file, or maybe even a machine datastore. Abstract it out, no > >> one ever needs to see anything secret in your code. > > > > That's not workable. It has to be publicly accessible somehow. > > > > -- > > personal: > http://www.cameronkaiser.com/ -- > > Cameron Kaiser * Floodgap Systems * www.floodgap.com * > ckai...@floodgap.com > > -- He hadn't a single redeeming vice. -- Oscar Wilde > -- > > > -- Internets. Serious business.
[twitter-dev] Re: Security Best Practices
> Yes, but don't distribute it. Obviously config files are human > readable, but you blank out secrets before publishing them. > > People using open source libraries will have to get their own keys. > So, either you really are contributing in the spirit of open source, > and you don't care about getting credit, or you're doing it for self > promotional purposes, and the conversation is moot anyhow. That's an asinine statement. So everybody who doesn't make their open source software anonymous is a publicity whore? -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- In memory of John Banner ---
[twitter-dev] Re: Use Twitter for login & oauth/authenticate method
Hi Arnaud, That option during application creation is really more trouble that it is worth. Right now applications that have that option checked include an extra sentence to tell users the application will be using twitter for login, that's all. In the future we may restrict the / oauth/authenticate call to applications that have specifically chosen the option, so I recommend that any application using 'Sing in with Twitter' check the check box. We're also working on redesigning the authorization page and might do more with that value then. We will announce before hand if we make any changes, like requiring that value to use the authenticate method. It's not something we'll definitely do but it is something that may come up in the medium term you should be aware of. Thanks; – Matt Sanford / @mzsanford Twitter Dev On Jul 1, 2009, at 4:26 AM, Arnaud wrote: Hello, I’m using the oauth/authenticate method (one click login) and I was wondering if I had to check the "Use Twitter for login" option in my application options. The application is Browser based (using a callback URL) . I’m quite confused with this option as I don’t really understand what it is standing for? All the best, Arnaud.
[twitter-dev] Re: Security Best Practices
Yes, but don't distribute it. Obviously config files are human readable, but you blank out secrets before publishing them. People using open source libraries will have to get their own keys. So, either you really are contributing in the spirit of open source, and you don't care about getting credit, or you're doing it for self promotional purposes, and the conversation is moot anyhow. "You" being any person worried about keys and open sourcing their libraries. On Wed, Jul 1, 2009 at 10:39 AM, Cameron Kaiser wrote: > >> The secret should not reside in code. The secret should reside in a >> config file, or maybe even a machine datastore. Abstract it out, no >> one ever needs to see anything secret in your code. > > That's not workable. It has to be publicly accessible somehow. > > -- > personal: http://www.cameronkaiser.com/ > -- > Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com > -- He hadn't a single redeeming vice. -- Oscar Wilde > -- >
[twitter-dev] Re: Security Best Practices
> The secret should not reside in code. The secret should reside in a > config file, or maybe even a machine datastore. Abstract it out, no > one ever needs to see anything secret in your code. That's not workable. It has to be publicly accessible somehow. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- He hadn't a single redeeming vice. -- Oscar Wilde --
[twitter-dev] Re: Security Best Practices
Andrew, The Consumer Secret is the key that has to be associated with my application so that it can authenticate to Twitter. Regardless of how I distribute it, I still have to distribute it with the source code in order for the source code to work. No amount of abstraction will prevent someone from analyzing the source and being able to retrieve the Consumer Secret. In a closed-source project, this is less of an issue. For open-source projects, this is a pretty big problem. Regards, Duane On Jul 1, 9:32 am, Andrew Badera wrote: > The secret should not reside in code. The secret should reside in a > config file, or maybe even a machine datastore. Abstract it out, no > one ever needs to see anything secret in your code.
[twitter-dev] Re: Security Best Practices
Might sorta work on webapps, or maybe desktop compiled code (assuming the config is compiled in at build time), but that doesn't help for desktop apps written in interpreted langs, where all source code and configs would be easily viewable (although I could imagine some initial setup stuff where it could get obscured). Not that I'm on either side of whatever this is. On Jul 1, 9:32 am, Andrew Badera wrote: > The secret should not reside in code. The secret should reside in a > config file, or maybe even a machine datastore. Abstract it out, no > one ever needs to see anything secret in your code. > > Thanks- > - Andy Badera > - and...@badera.us > - Google me:http://www.google.com/search?q=andrew+badera > - This email is: [ ] bloggable [x] ask first [ ] private > > On Wed, Jul 1, 2009 at 9:25 AM, DWRoelands wrote: > > > If you check out the OAuth Core Abstract, Section 4 (http://oauth.net/ > > core/1.0#anchor4) states it pretty plainly: > > > "Service Providers SHOULD NOT rely on the Consumer Secret as a method > > to verify the Consumer identity, unless the Consumer Secret is known > > to be inaccessible to anyone other than the Consumer and the Service > > Provider." > > > This is exactly what Twitter has done with the Consumer Secret; they > > rely on it to verify the Consumer identity. > > > This is a thorny dilemma for open source developers. There's no way > > to share the source code without compromising your application's > > security, because you've got to include the Consumer Key Secret in the > > source. You can obfuscate and encrypt, but a malicious actor with > > access to the source code can simply "step through" the code until the > > Consumer Secret is exposed in plain text. > > > In any event, what's done is done, and Twitter certainly isn't going > > to abandon OAuth at this point. But opening the source of my Twitter > > client seems to be out of the question if I want to use OAuth. > > > On Jul 1, 8:10 am, Philip Plante wrote: > >> I do not feel you've made a mountain out of a mole hill here. This > >> topic has been on my mind since I first encountered oAuth. I haven't > >> seen any open source apps use oAuth yet. > >
[twitter-dev] Re: Security Best Practices
True, but none of that addresses the central points that I'm trying to make: 1. The OAuth Core documentation says that providers should not rely on the Consumer Secret to identify consumers. 2. Twitter's implementation of OAuth appears to do exactly what the OAuth Core documentation says not to do. 3. As a result, open-source developers have to expose the Consumer Secret for their application, opening their keys to potential abuse and eventual cancellation by Twitter. That's a problem. What's done is done and I don't expect Twitter to abandon OAuth. But it's an important issue that's worth talking about because it's a security risk for developers of desktop clients. On Jul 1, 9:50 am, Abraham Williams <4bra...@gmail.com> wrote: > True. But I'm pretty sure that there are more active grandfathered > sources then OAuth sources. And it takes nothing to create a new OAuth > application that has the same source as an existing OAuth application > but with only a slightly different name.
[twitter-dev] Re: Security Best Practices
True. But I'm pretty sure that there are more active grandfathered sources then OAuth sources. And it takes nothing to create a new OAuth application that has the same source as an existing OAuth application but with only a slightly different name. Abraham On Wed, Jul 1, 2009 at 08:39, DWRoelands wrote: > > That's not correct. Updates posted to Twitter via Basic Auth always > appear with a source of "From Web" (unless the application in question > was "grandfathered in"). Otherwise, it's not possible to impersonate > another application via Basic Auth. > > On Jul 1, 9:34 am, Abraham Williams <4bra...@gmail.com> wrote: > Using basic auth it is already possible to use any >> source and "impersonate" another application so not much is changing >> here except better security for web applications. > -- Abraham Williams | Community Evangelist | http://web608.org Hacker | http://abrah.am | http://twitter.com/abraham Project | http://fireeagle.labs.poseurtech.com This email is: [ ] blogable [x] ask first [ ] private.
[twitter-dev] Re: Security Best Practices
That's not correct. Updates posted to Twitter via Basic Auth always appear with a source of "From Web" (unless the application in question was "grandfathered in"). Otherwise, it's not possible to impersonate another application via Basic Auth. On Jul 1, 9:34 am, Abraham Williams <4bra...@gmail.com> wrote: Using basic auth it is already possible to use any > source and "impersonate" another application so not much is changing > here except better security for web applications.
[twitter-dev] Re: How-To: Load the Twitter XML into a VB.Net XML Document...
Obrzut: My application does exactly what you say is impossible. The user authenticates via the web browser, then my desktop application completes the process using the six-digit PIN. There's no need to "fix" any XML that comes from Twitter, and there's no need to process any HTML from a web page. I'd be happy to help you work through the issues you're having with your application, but please stop insisting that you're smarter than everyone else here. Bojan: Obrzut's right about the GetAccessToken() call in the Twarp code. GetAccessToken accepts the PIN as an Int; that should be a string so that leading zeroes don't get stripped. I haven't seen any PINs with a leading zero, but that doesn't mean they don't occur. :) --Duane On Jul 1, 8:00 am, Obrzut wrote: > If you state otherwise - that you CAN use a TCP Client after already > authenticating your VB.Net web browser - you are wrong.
[twitter-dev] Re: Security Best Practices
The worst that happens if you publish the consumer tokens in an opensouce app is someone malicious uses it to abuse Twitter and the consumer token gets banned. At which point you regenerate a new one and push a new version of the app. The cycle may or may not start again depending on the malicious party. They can not act upon user accounts without the users going through the authorize flow. Using basic auth it is already possible to use any source and "impersonate" another application so not much is changing here except better security for web applications. Abraham On Wed, Jul 1, 2009 at 08:25, DWRoelands wrote: > > If you check out the OAuth Core Abstract, Section 4 (http://oauth.net/ > core/1.0#anchor4) states it pretty plainly: > > "Service Providers SHOULD NOT rely on the Consumer Secret as a method > to verify the Consumer identity, unless the Consumer Secret is known > to be inaccessible to anyone other than the Consumer and the Service > Provider." > > This is exactly what Twitter has done with the Consumer Secret; they > rely on it to verify the Consumer identity. > > This is a thorny dilemma for open source developers. There's no way > to share the source code without compromising your application's > security, because you've got to include the Consumer Key Secret in the > source. You can obfuscate and encrypt, but a malicious actor with > access to the source code can simply "step through" the code until the > Consumer Secret is exposed in plain text. > > In any event, what's done is done, and Twitter certainly isn't going > to abandon OAuth at this point. But opening the source of my Twitter > client seems to be out of the question if I want to use OAuth. > > > On Jul 1, 8:10 am, Philip Plante wrote: >> I do not feel you've made a mountain out of a mole hill here. This >> topic has been on my mind since I first encountered oAuth. I haven't >> seen any open source apps use oAuth yet. > -- Abraham Williams | Community Evangelist | http://web608.org Hacker | http://abrah.am | http://twitter.com/abraham Project | http://fireeagle.labs.poseurtech.com This email is: [ ] blogable [x] ask first [ ] private.
[twitter-dev] Re: Security Best Practices
The secret should not reside in code. The secret should reside in a config file, or maybe even a machine datastore. Abstract it out, no one ever needs to see anything secret in your code. Thanks- - Andy Badera - and...@badera.us - Google me: http://www.google.com/search?q=andrew+badera - This email is: [ ] bloggable [x] ask first [ ] private On Wed, Jul 1, 2009 at 9:25 AM, DWRoelands wrote: > > If you check out the OAuth Core Abstract, Section 4 (http://oauth.net/ > core/1.0#anchor4) states it pretty plainly: > > "Service Providers SHOULD NOT rely on the Consumer Secret as a method > to verify the Consumer identity, unless the Consumer Secret is known > to be inaccessible to anyone other than the Consumer and the Service > Provider." > > This is exactly what Twitter has done with the Consumer Secret; they > rely on it to verify the Consumer identity. > > This is a thorny dilemma for open source developers. There's no way > to share the source code without compromising your application's > security, because you've got to include the Consumer Key Secret in the > source. You can obfuscate and encrypt, but a malicious actor with > access to the source code can simply "step through" the code until the > Consumer Secret is exposed in plain text. > > In any event, what's done is done, and Twitter certainly isn't going > to abandon OAuth at this point. But opening the source of my Twitter > client seems to be out of the question if I want to use OAuth. > > > On Jul 1, 8:10 am, Philip Plante wrote: >> I do not feel you've made a mountain out of a mole hill here. This >> topic has been on my mind since I first encountered oAuth. I haven't >> seen any open source apps use oAuth yet. >
[twitter-dev] Re: Security Best Practices
If you check out the OAuth Core Abstract, Section 4 (http://oauth.net/ core/1.0#anchor4) states it pretty plainly: "Service Providers SHOULD NOT rely on the Consumer Secret as a method to verify the Consumer identity, unless the Consumer Secret is known to be inaccessible to anyone other than the Consumer and the Service Provider." This is exactly what Twitter has done with the Consumer Secret; they rely on it to verify the Consumer identity. This is a thorny dilemma for open source developers. There's no way to share the source code without compromising your application's security, because you've got to include the Consumer Key Secret in the source. You can obfuscate and encrypt, but a malicious actor with access to the source code can simply "step through" the code until the Consumer Secret is exposed in plain text. In any event, what's done is done, and Twitter certainly isn't going to abandon OAuth at this point. But opening the source of my Twitter client seems to be out of the question if I want to use OAuth. On Jul 1, 8:10 am, Philip Plante wrote: > I do not feel you've made a mountain out of a mole hill here. This > topic has been on my mind since I first encountered oAuth. I haven't > seen any open source apps use oAuth yet.
[twitter-dev] Re: How-To: Load the Twitter XML into a VB.Net XML Document...
2009/7/1 Obrzut : > > Did I state otherwise? > > You are not reading my words - you are being blinded by the noise from > your own head. > > What I stated is this; > > I authenticate my VB.NET web browser via PIN etc > > THIS means my browser is authenticated. > > If I try to access a page via the program with a TCP Client - I have > to re-authenticate via PIN. > > This WAS a problem - my solution is to continue to use the web browser > for authentication and extract the XML pages into an XML Document. > > Hence the above code. > > If you state otherwise - that you CAN use a TCP Client after already > authenticating your VB.Net web browser - you are wrong. > > I imagine you think I am wrong - and that I am an idiot. Believe me - > I am very skilled at programming. And this is my experience. > > The library is faulty. It does not process leading zero pins. > > The OAuth implementation is stupid - because it does not authenticate > an program but a TCP method. > > Hence, you guys are s off the mark here it hurts me to talk to > you. > > Really, srsly, it's pathetic that you DO NOT LISTEN. And it's pathetic that you take a piece of code that someone has generously donated to the Twitter developer community and then complain because *you* can't get it to work with an attitude that would be barely acceptable if you'd paid for it. You clearly think you can do better, so go ahead and write your own Twitter library for VB.net. Nobody is forcing you to use that code. -Stuart -- http://stut.net/projects/twitter > On Jul 1, 4:58 am, DWRoelands wrote: >> You can absolutely authenticate in a web page, even if your >> application is not a web application. Mine works that way. >> >> Here's how it should go. Bojan, please correct me if I'm wrong. >> >> 1. Your application calls GetAuthorizationLink() to get the URL of the >> authorization page (you've got this already). >> 2. Your application opens a web browser to that link. In .NET, you >> can do this with Process.Start(The URL that you get from >> GetAuthorizationLink). >> 3. The user sees the six-digit PIN on the screen. >> 4. Your application prompts the user to enter the six-digit PIN that >> they see. >> 5. Your application calls GetAccessToken(), passing the six-digit PIN >> as the input parameter. >> 6. The OAuth object has two properties that should now be populated: >> Token and TokenSecret. These are the items you will use for all >> subsequent OAuth requests to Twitter. >> >> Your application should now be authorized via OAuth. >> >> On Jun 30, 8:58 pm, Obrzut wrote: >> >> >> >> > This is because of OAuth. It uses HTML pages to validate. Perhaps I am >> > wrong - but once I use a web browser to validate - I cannot use a TCP >> > Client to get the XML because I authenticated via a web browser. When >> > I tried to (for example) send the pin back via a HTTP Web Request it >> > failed. I am not sure if I am using the OAuth library Interface Class >> > I have for VB.NET correctly!?
[twitter-dev] Re: Security Best Practices
I do not feel you've made a mountain out of a mole hill here. This topic has been on my mind since I first encountered oAuth. I haven't seen any open source apps use oAuth yet. We have an open source application called Application X. The potential risk is that Application X becomes widely adopted, thus having a higher risk of being impersonated. For instance, malware could then use the tokens from Application X to obtain authorization from Twitter. This would require the user to authorize the impersonator via Twitter since it is likely a new session token would be generated. Potentially the user would likely trust this impersonator and not think twice about authorizing it because they will see "Application X" on Twitter.com. Once they click allow the impersonator has control of their account. Even if the malware doesn't spread quickly it would possibly be harder to track since it would appear to be communications from Application X. I am not one to cry fowl over an issue like this, just merely throwing this out here as an idea. Anyone else have any ideas how to secure open source oAuth apps? On Jul 1, 6:24 am, DWRoelands wrote: > It seems as though revealing the Consumer Key and Consumer Key Secret > of my application would be a pretty serious security risk. Anyone > could write an application that impersonates mine, but they still > would need an authorized user's Token and Token Secret in order to > commit mischief. > > What sort of nastiness could one do in the Twitter environment with > someone else's Consumer Key and Consumer Key Secret? > > Am I making a mountain out of a molehill here? If this is not a big > deal, I'd like to hear so so I can continue working on my project as > an open source endeavor. If this is a serious security issue, then I > have to close the source for my project (and obfuscate the source). > > --Duane > > On Jun 30, 9:29 pm, Alex Payne wrote: > > > > > That's a solution that better fits open source Twitter web services. For an > > open source desktop client like Spaz it certainly doesn't work. > > > On Tue, Jun 30, 2009 at 16:37, DWRoelands wrote: > > > > Wait, the solution is that every -user- of an open-source Twitter > > > client would have to register for their own set of -consumer- keys? > > > > That's not what you meant, is it? > > > > On Jun 30, 4:39 pm, Alex Payne wrote: > > > > The simplest solution is that every deployment of the tool will have to > > > > register for their own OAuth credentials. This isn't ideal. I'd inquire > > > over > > > > athttp://groups.google.com/group/oauth > > > > > On Tue, Jun 30, 2009 at 06:04, DWRoelands > > > wrote: > > > > > > This is really an excellent question. > > > > > > If we're developing an open-source Twitter client, how are we supposed > > > > > to handle the consumer_key and consumer_key_secret? > > > > > > On Jun 29, 7:58 pm, Support wrote: > > > > > > 2. Obfuscation of the application's registered "key" and "secret." > > > > > > Are there any best practices? What about an open source project? > > > > > -- > > > > Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x > > > -- > > Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x
[twitter-dev] Re: How-To: Load the Twitter XML into a VB.Net XML Document...
On Wed, Jul 1, 2009 at 07:00, Obrzut wrote: > The library is faulty. It does not process leading zero pins. > > The OAuth implementation is stupid - because it does not authenticate > an program but a TCP method. > > Hence, you guys are s off the mark here it hurts me to talk to > you. > > Really, srsly, it's pathetic that you DO NOT LISTEN. Well that is one way to thank people donating their time to try and help you... -- Abraham Williams | Community Evangelist | http://web608.org Hacker | http://abrah.am | http://twitter.com/abraham Project | http://fireeagle.labs.poseurtech.com This email is: [ ] blogable [x] ask first [ ] private.
[twitter-dev] Re: How-To: Load the Twitter XML into a VB.Net XML Document...
Did I state otherwise? You are not reading my words - you are being blinded by the noise from your own head. What I stated is this; I authenticate my VB.NET web browser via PIN etc THIS means my browser is authenticated. If I try to access a page via the program with a TCP Client - I have to re-authenticate via PIN. This WAS a problem - my solution is to continue to use the web browser for authentication and extract the XML pages into an XML Document. Hence the above code. If you state otherwise - that you CAN use a TCP Client after already authenticating your VB.Net web browser - you are wrong. I imagine you think I am wrong - and that I am an idiot. Believe me - I am very skilled at programming. And this is my experience. The library is faulty. It does not process leading zero pins. The OAuth implementation is stupid - because it does not authenticate an program but a TCP method. Hence, you guys are s off the mark here it hurts me to talk to you. Really, srsly, it's pathetic that you DO NOT LISTEN. On Jul 1, 4:58 am, DWRoelands wrote: > You can absolutely authenticate in a web page, even if your > application is not a web application. Mine works that way. > > Here's how it should go. Bojan, please correct me if I'm wrong. > > 1. Your application calls GetAuthorizationLink() to get the URL of the > authorization page (you've got this already). > 2. Your application opens a web browser to that link. In .NET, you > can do this with Process.Start(The URL that you get from > GetAuthorizationLink). > 3. The user sees the six-digit PIN on the screen. > 4. Your application prompts the user to enter the six-digit PIN that > they see. > 5. Your application calls GetAccessToken(), passing the six-digit PIN > as the input parameter. > 6. The OAuth object has two properties that should now be populated: > Token and TokenSecret. These are the items you will use for all > subsequent OAuth requests to Twitter. > > Your application should now be authorized via OAuth. > > On Jun 30, 8:58 pm, Obrzut wrote: > > > > > This is because of OAuth. It uses HTML pages to validate. Perhaps I am > > wrong - but once I use a web browser to validate - I cannot use a TCP > > Client to get the XML because I authenticated via a web browser. When > > I tried to (for example) send the pin back via a HTTP Web Request it > > failed. I am not sure if I am using the OAuth library Interface Class > > I have for VB.NET correctly!?
[twitter-dev] Re: User id range
You should use an unsigned 64 bit int for status and user ids to be safe. IDs will never be negative, so a signed value is wasted space. On Jul 1, 6:28 am, DWRoelands wrote: > If you're asking what data type should you use to store these value, > I'm using the .NET Int64 type in my library. The Int64 value type > represents integers with values ranging from negative > 9,223,372,036,854,775,808 through positive 9,223,372,036,854,775,807. > I was seeing occasional overflows using Int32. > > On Jul 1, 1:14 am, Arunachalam wrote: > > > > > Im little bit confused in identifying the numeric digit say '14198354' > > either as statuses id/ user id. > > As of now im accessinghttp://twitter.com/users/show/14198354.xmlto > > identify it as a user. > > > Is there any range in the user id values > > and wht will be the range for the statues id values? > > > Cheers, > > Arunachalam
[twitter-dev] Re: How-To: Load the Twitter XML into a VB.Net XML Document...
Right - I am not scraping the PIN? I am using the web browser in .NET (which is similar to Internet Explorer) to authenticate via a pin and username / password credentials. The only part of the workflow I do not follow is opening the URL in IE - I open in it VB.NET Web Browser. But - my user has to input it to send it back - I do not retreive it. What I am retreiving is the XML document that is sent to the web browser. I am not sure if any of you have actually seen the pages yet - but I have a few problems with your Library. When the pin starts with a zero - the authentication fails. Are you converting the pin string to an integer in your library? This is the only reason why a leading zero would be stripped you see. That is my first problem with the library - it has not been tested in a real world example otherwise this would have been flagged long ago. Now - I am not sure why you would think I was scraping the PIN - my user inputs it into a VB textbox for sending back to the correct URL. This way - my web browser gets authenticated. Also, did you know a Login prompt appears from the browser window - asking the user for Login credentials a SECOND time!? This is most peculiar. Have anyone else experienced this or are basically just not experienced in writing for the Twitter API and just read the information pages. I am a programmer - writing a VB.NET application that is registered with Twitter. I require real world examples because my program is real world - not from the pages of the Twitter API documentation. So, lets make this clear divide here - I want to talk to programmers - not just people who THINK they know what is happening from the API man pages. lol
[twitter-dev] Use Twitter for login & oauth/authenticate method
Hello, I’m using the oauth/authenticate method (one click login) and I was wondering if I had to check the "Use Twitter for login" option in my application options. The application is Browser based (using a callback URL) . I’m quite confused with this option as I don’t really understand what it is standing for? All the best, Arnaud.
[twitter-dev] Re: Retrieving data from the Twitter API
hmmm On Jun 30, 10:45 pm, Abraham Williams <4bra...@gmail.com> wrote: > Twitter has said in the past they are more then willing to take care > of the bandwidth for smaller applications but if you go huge they ask > you to look at local caching. > > > > On Tue, Jun 30, 2009 at 08:12, Philip Plante wrote: > > > You can cache the user's profile data so API lookups are kept to a > > minimum. Though the profile image should be hotlinked using whatever > > value is stored int he profile_image_url attribute of the user object > > returned from Twitter. By using S3 as a central source Twitter is > > able to help alleviate image sync issues that would arise when third > > party services cache the image locally. Also keep in mind that most > > of the time your user's should already have their cache primed, via > > twitter.com or another service, due the caching rules employed by > > Twitter and S3. > > > On Jun 30, 6:32 am, Christian Fazzini > > wrote: > >> Hello, > > >> We are in the process of developing a website that uses the Twitter > >> API. > > >> I understand that the Twitter API is capable of retrieving a user's > >> profile photo via: > > >>http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-users%C2%A0show > > >> Other websites that are using the Twitter API are, instead, getting > >> these profile photos from Amazon's S3 storage service > >> (http://s3.amazonaws.com/twitter_production/). > > >> At current when a Twitter user logs onto our website, it will retrieve > >> his information and store it our local db. At the same time it will > >> also grab the profile photo from and store it on > >> our server. > > >> In my opinion, this seems more appropriate instead of having the site > >> quer the Twitters API and / or hotlink to Amazon's S3 storage service > >> whenever a user loads a page. Especially, if it has to load several > >> profile photos on every page load, on our site. I could be wrong > >> here. > > >> What do you guys think the best approach for this is? > > >> Hoping to hear from you soon. > > >> Best regards, > >> Chris > > -- > Abraham Williams | Community Evangelist |http://web608.org > Hacker |http://abrah.am|http://twitter.com/abraham > Project |http://fireeagle.labs.poseurtech.com > This email is: [ ] blogable [x] ask first [ ] private.
[twitter-dev] Re: Retrieving data from the Twitter API
So is this wrong if I save the image and user details locally (on our server) ? Also, how would it be possible to get the users profile pic at http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-users%C2%A0show using ? At current it only returns _normal.jpg, which is set at 43x43. I need the bigger profile image that is set at 73x73 On Jun 30, 10:45 pm, Abraham Williams <4bra...@gmail.com> wrote: > Twitter has said in the past they are more then willing to take care > of the bandwidth for smaller applications but if you go huge they ask > you to look at local caching. > > > > On Tue, Jun 30, 2009 at 08:12, Philip Plante wrote: > > > You can cache the user's profile data so API lookups are kept to a > > minimum. Though the profile image should be hotlinked using whatever > > value is stored int he profile_image_url attribute of the user object > > returned from Twitter. By using S3 as a central source Twitter is > > able to help alleviate image sync issues that would arise when third > > party services cache the image locally. Also keep in mind that most > > of the time your user's should already have their cache primed, via > > twitter.com or another service, due the caching rules employed by > > Twitter and S3. > > > On Jun 30, 6:32 am, Christian Fazzini > > wrote: > >> Hello, > > >> We are in the process of developing a website that uses the Twitter > >> API. > > >> I understand that the Twitter API is capable of retrieving a user's > >> profile photo via: > > >>http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-users%C2%A0show > > >> Other websites that are using the Twitter API are, instead, getting > >> these profile photos from Amazon's S3 storage service > >> (http://s3.amazonaws.com/twitter_production/). > > >> At current when a Twitter user logs onto our website, it will retrieve > >> his information and store it our local db. At the same time it will > >> also grab the profile photo from and store it on > >> our server. > > >> In my opinion, this seems more appropriate instead of having the site > >> quer the Twitters API and / or hotlink to Amazon's S3 storage service > >> whenever a user loads a page. Especially, if it has to load several > >> profile photos on every page load, on our site. I could be wrong > >> here. > > >> What do you guys think the best approach for this is? > > >> Hoping to hear from you soon. > > >> Best regards, > >> Chris > > -- > Abraham Williams | Community Evangelist |http://web608.org > Hacker |http://abrah.am|http://twitter.com/abraham > Project |http://fireeagle.labs.poseurtech.com > This email is: [ ] blogable [x] ask first [ ] private.
[twitter-dev] Re: User id range
If you're asking what data type should you use to store these value, I'm using the .NET Int64 type in my library. The Int64 value type represents integers with values ranging from negative 9,223,372,036,854,775,808 through positive 9,223,372,036,854,775,807. I was seeing occasional overflows using Int32. On Jul 1, 1:14 am, Arunachalam wrote: > Im little bit confused in identifying the numeric digit say '14198354' > either as statuses id/ user id. > As of now im accessinghttp://twitter.com/users/show/14198354.xmlto > identify it as a user. > > Is there any range in the user id values > and wht will be the range for the statues id values? > > Cheers, > Arunachalam
[twitter-dev] Re: Security Best Practices
It seems as though revealing the Consumer Key and Consumer Key Secret of my application would be a pretty serious security risk. Anyone could write an application that impersonates mine, but they still would need an authorized user's Token and Token Secret in order to commit mischief. What sort of nastiness could one do in the Twitter environment with someone else's Consumer Key and Consumer Key Secret? Am I making a mountain out of a molehill here? If this is not a big deal, I'd like to hear so so I can continue working on my project as an open source endeavor. If this is a serious security issue, then I have to close the source for my project (and obfuscate the source). --Duane On Jun 30, 9:29 pm, Alex Payne wrote: > That's a solution that better fits open source Twitter web services. For an > open source desktop client like Spaz it certainly doesn't work. > > > > On Tue, Jun 30, 2009 at 16:37, DWRoelands wrote: > > > Wait, the solution is that every -user- of an open-source Twitter > > client would have to register for their own set of -consumer- keys? > > > That's not what you meant, is it? > > > On Jun 30, 4:39 pm, Alex Payne wrote: > > > The simplest solution is that every deployment of the tool will have to > > > register for their own OAuth credentials. This isn't ideal. I'd inquire > > over > > > athttp://groups.google.com/group/oauth > > > > On Tue, Jun 30, 2009 at 06:04, DWRoelands > > wrote: > > > > > This is really an excellent question. > > > > > If we're developing an open-source Twitter client, how are we supposed > > > > to handle the consumer_key and consumer_key_secret? > > > > > On Jun 29, 7:58 pm, Support wrote: > > > > > 2. Obfuscation of the application's registered "key" and "secret." > > > > > Are there any best practices? What about an open source project? > > > > -- > > > Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x > > -- > Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x
