[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: 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
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
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
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
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
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
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
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
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: 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
[twitter-dev] Re: source not working
I'm afraid that you'll need an OAuth library to be able to do what you want. If you don't use OAuth, your posts will always show up as "from web". On Jun 30, 3:02 pm, Max wrote: > Twitter4j is definitely not simple enough. All I want to know is how > can I send a status with my source using a simple method. I can do > all the other stuff... the only thing that isn't working is the > source. So... do I really need a whole source library for java in > order to do this?
[twitter-dev] Re: How-To: Load the Twitter XML into a VB.Net XML Document...
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
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
[twitter-dev] Re: How-To: Load the Twitter XML into a VB.Net XML Document...
I'm curious; why are you screen-scraping an HTML page in a Twitter
app?
On Jun 30, 4:09 pm, Obrzut wrote:
> Dim w As New System.IO.StreamWriter(fs)
> Page = Page.Replace("&", " ")
> Page = Page.Replace("- <", "<")
>
> Page = Page.TrimStart(" ")
> w.Write(Page)
>
> This is a better example of code that does what the above code sample
> should be doing rather than changing UTF8 to ASCII - I replace a '- <'
> with a '<' remove any '&'s and trim the white space. This makes it
> sorted for VB.Net whilst preserving most the document text.
[twitter-dev] Re: Subscribe to user and download tweets?
Ah, I see. This is certainly doable. Your application would need to sign into your account (Basic Auth is probably fine if it's just for your own use), and retrieve your friends' updates. This is already in the API. What the API doesn't have is any "Save" functionality, so you would need to write your own code that goes through the list of updates and saves them to disk. It would not be hard to code at all. The more I think about this, the more I think I might add this feature to the Twitter client I'm writing. :) --Duane On Jun 30, 4:24 pm, Richie wrote: > I want to download their tweets - as I said. I don't want to just see > them in my list on Twitter. I want to download their tweets and store > them in an archive on my local machine. > > On Jun 30, 4:19 pm, DWRoelands wrote: > > > > > Could you be a little more specific? > > > If you follow another user, their tweets will show up in your list of > > friends' updates. Does that not do what you need it to do? > > > On Jun 30, 2:13 pm, Richie wrote: > > > > Is there a way using the Twitter API to subscribe to a user and > > > download their tweets using a web server whenever they update?
[twitter-dev] Re: Subscribe to user and download tweets?
Could you be a little more specific? If you follow another user, their tweets will show up in your list of friends' updates. Does that not do what you need it to do? On Jun 30, 2:13 pm, Richie wrote: > Is there a way using the Twitter API to subscribe to a user and > download their tweets using a web server whenever they update?
[twitter-dev] Re: PIN Authentication Examples?
Obrzut, You don't need a webbrowser object in your VB application to accomplish this. You can have your application open a web browser in a new window. That's how I'm doing it in my Twitter client. Here's an example: Dim webAddress As String = "http://www.google.com"; Process.Start(webAddress) This will open Google in a web browser, using whatever browser is configured as the default. Get an authorization link from Twitter (AuthorizationLinkGet() in Shannon Whitley's OAuthTwitter class), and pass that link to Process.Start(). The user will be prompted to log in to Twitter and will receive the six-digit PIN. Your application should prompt the user to enter the PIN and pass it back to Twitter to complete the authentication process. Regards, Duane On Jun 30, 8:16 am, Obrzut wrote: > Hi, > > Well, my experience of using a web browser in VB.Net is that you have > to keep to the same browser and cannot mix a HTTPWebRequest with a > WebBrowser1 object! > > What I tried was getting the pin number via a web browser object, then > sending that back via a HTTPWebRequest class. It failed miserably. > Perhaps it was my code? > > I too am writing a VB.NET program for Twitter! It is very exciting > work. I would have finished it last week but I had a whole week off > coding because of the flu. > > What I have left to do is parse all the XML into my program correctly. > Also, just a quick note - the XML.document.load in VB.NET does NOT > accept UTF-8 as an encoding method - so I suggest reformatting the XML > document as ASCII before trying to load it. ALSO - remove any white > space (there are about three spaces at the beginning of the document!) > otherwise VB.NET throws its toys out the pram. > > There are a few other issues too with XML documents and Twitter - such > as the '&' character being illegal. You have to replace every & with a > non-space if you want your document to load! Other than that - I > finally got my document into a VB.NET XML Document and now parsing the > XML is easy-peasy. This is because all you have to do is specify which > node name you want to retrieve - and VB.NEt does all the work! Haha. > > I am really tired today - but I might work on the VB.NET program some > more later on after I finish my nap :)
[twitter-dev] Re: Security Best Practices
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?
[twitter-dev] Re: PIN Authentication Examples?
I've looked at Bojan's implementation of OAuth, and his code does not strip the query parameters in the way I described. I'm not using his library (I'm trying to code a complete VB.NET client), but I can say that it looks pretty solid and Bojan was very helpful to me when I had questions about OAuth. > Might I recommend my OAuth implementation for Twitter? It's based on > Shannon's code and is up to date for the new PIN authentication. > > You can fetch the code fromhttp://twarp.googlecode.com'sSVN > repository, and there are also fairly recent binaries on the download > page. There are also C# examples in SVN, showing both synchronous and > asynchronous login workflow. > > Regards, > > - -- > Bojan Rajkovic
[twitter-dev] Re: PIN Authentication Examples?
I've identified the issue and my PIN authentication is now working
correctly. I'll do my best to explain the issue here to save others
the headaches I've had. :)
The OAuth class that Eran Sandler so graciously provided to the
community (http://oauth.googlecode.com/svn/code/csharp/OAuthBase.cs)
contains a method called "GetQueryParameters()". GetQueryParameters
is used to build the query string of any OAuth web request. If you
look at the code of that method, you'll see a foreach() loop that
contains the following IF statement:
if (!string.IsNullOrEmpty(s) && !s.StartsWith(OAuthParameterPrefix)) {
The effect of this code is that querystring parameters are only added
to the web request if they DO NOT start with "oauth_". So, when I was
trying to create a web request with "oauth_verifier" on the
querystring, Eran's code was stripping it out. Without that item on
the query string, Twitter was (quite rightly) telling me to get lost.
My immediate solution was to remove the "&& !s.StartsWith
(OAuthParameterPrefix)" from the above line. This allowed the rest of
the OAuth class (and Shannon Whitley's extension class) to process my
PIN request correctly.
I understand that this may not be the BEST solution, and I would
greatly appreciate hearing better ones.
On Jun 29, 10:18 am, Matt Sanford wrote:
> Hi Duane,
>
> When you get the 401 what does the body say?
>
> Thanks;
> – Matt Sanford / @mzsanford
> Twitter Dev
>
> On Jun 29, 2009, at 4:29 AM, DWRoelands wrote:
>
>
>
> > I'm having a devil of a time getting my application to connect to
> > Twitter via OAuth and the six-digit pin method.
>
> > I've been working with the excellent OAuth library from
> > ShannonWhitley:
> >http://www.voiceoftech.com/swhitley/?p=681
>
> > I'm able to get an authorization link, open a browser, and get the
> > six-
> > digit PIN. However, I can't seem to submit that PIN back to Twitter
> > without getting a 401 Unauthorized error.
>
> > I added this method to Shannon's TWitter OAuth code:
>
> > public bool ValidatePin(string PIN)
> > {
> > string response = WebRequest(Method.GET, string.Format
> > ("{0}?oauth_verifier={1}", ACCESS_TOKEN, PIN), string.Empty);
> > if (response.Length > 0)
> > {
> > //Store the Token and Token Secret
> > var qs = HttpUtility.ParseQueryString(response);
> > if (!string.IsNullOrEmpty(qs["oauth_token"]))
> > this.Token = qs["oauth_token"];
> > if (!string.IsNullOrEmpty(qs["oauth_token_secret"]))
> > this.TokenSecret = qs["oauth_token_secret"];
> > return true;
> > }
> > else
> > {
> > return false;
> > }
> > }
>
> > Inevitably, I get 401 Unauthorized when submitting the
> > "oauth_verifier" web request.
> > I have a consumer key and a consumer key secret which work (as is
> > evidenced by the fact that I can get an authorization link).
>
> > Has anyone else encountered similar issues, or does anyone else have
> > any guidance on this particular issue?
>
> > Thanks in advance.
> > --Duane
[twitter-dev] Re: source not working
I symnpathize. OAuth is not intuitive, nor is it easy to implement. I've been struggling with PIN-based authorization for days and I can't seem to make any headway on how to get Twitter to take the PIN and give me back valid tokens. But, it's all we have if you want to use the "Source" parameter. On Jun 29, 10:14 pm, Max wrote: > so you cant use oauth with curl... awesome, i'm glad i installed it > last night. =[ > > On Jun 29, 3:52 pm, Max wrote: > > > Okay, I'm going to try and figure out OAuth later tonight. Thank you > > very much. > > > On Jun 29, 9:11 am, DWRoelands wrote: > > > > Max, > > > > Some time ago, Twitter stopped accepting the "Source" argument from > > > applications using Basic Auth. Any apps that had been using Basic > > > Auth before that point were "grandfathered" in. Any apps created > > > after that point need to use OAuth for the "Source" to be accepted. > > > > Which is why I'm wrestling with OAuth now. :) > > > > On Jun 29, 8:10 am, Max K wrote: > > > > > So umm... how do I get something to work using basic auth? > > > > > On Mon, Jun 29, 2009 at 7:42 AM, Abraham Williams <4bra...@gmail.com> > > > > wrote: > > > > > > Sources from OAuth applications don't work when used through basic > > > > > auth. > > > > > > Abraham > > > > > > On Mon, Jun 29, 2009 at 05:49, Max K wrote: > > > > > > well I'm using the command > > > > > >>curl -v -d "source=roflcopterlolmachine&status=test" -u > > > > > >>username:password > > > > > >>http://twitter.com/statuses/update.xml > > > > > > > and i have the name roflcopterlolmachine registered with twitter on > > > > > >http://twitter.com/oauth_clients. i'm new to the twitter api and > > > > > >just > > > > > don't > > > > > > understand whats going on > > > > > > > On Sun, Jun 28, 2009 at 11:36 PM, JDG wrote: > > > > > > >> Source only works with oauth, unless you had registered it before > > > > > >> OAuth > > > > > >> was implemented. Are you using Basic auth? > > > > > > >> On Sun, Jun 28, 2009 at 21:01, Max wrote: > > > > > > >>> why is it that my source name doesn't work? how long does it > > > > > >>> take for > > > > > >>> twitter to recognize an application... because if i use a name of > > > > > >>> an > > > > > >>> app that already exists [ex: max] it works, but if I do something > > > > > >>> like > > > > > >>> status=rdfglkdfjgklfdg > > > > > > >>> it doesnt... > > > > > > >>> why? > > > > > > >> -- > > > > > >> Internets. Serious business. > > > > > > -- > > > > > 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: source not working
Max, Some time ago, Twitter stopped accepting the "Source" argument from applications using Basic Auth. Any apps that had been using Basic Auth before that point were "grandfathered" in. Any apps created after that point need to use OAuth for the "Source" to be accepted. Which is why I'm wrestling with OAuth now. :) On Jun 29, 8:10 am, Max K wrote: > So umm... how do I get something to work using basic auth? > > On Mon, Jun 29, 2009 at 7:42 AM, Abraham Williams <4bra...@gmail.com> wrote: > > > Sources from OAuth applications don't work when used through basic auth. > > > Abraham > > > On Mon, Jun 29, 2009 at 05:49, Max K wrote: > > > well I'm using the command > > >>curl -v -d "source=roflcopterlolmachine&status=test" -u username:password > > >>http://twitter.com/statuses/update.xml > > > > and i have the name roflcopterlolmachine registered with twitter on > > >http://twitter.com/oauth_clients. i'm new to the twitter api and just > > don't > > > understand whats going on > > > > On Sun, Jun 28, 2009 at 11:36 PM, JDG wrote: > > > >> Source only works with oauth, unless you had registered it before OAuth > > >> was implemented. Are you using Basic auth? > > > >> On Sun, Jun 28, 2009 at 21:01, Max wrote: > > > >>> why is it that my source name doesn't work? how long does it take for > > >>> twitter to recognize an application... because if i use a name of an > > >>> app that already exists [ex: max] it works, but if I do something like > > >>> status=rdfglkdfjgklfdg > > > >>> it doesnt... > > > >>> why? > > > >> -- > > >> Internets. Serious business. > > > -- > > 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] PIN Authentication Examples?
I'm having a devil of a time getting my application to connect to
Twitter via OAuth and the six-digit pin method.
I've been working with the excellent OAuth library from
ShannonWhitley:
http://www.voiceoftech.com/swhitley/?p=681
I'm able to get an authorization link, open a browser, and get the six-
digit PIN. However, I can't seem to submit that PIN back to Twitter
without getting a 401 Unauthorized error.
I added this method to Shannon's TWitter OAuth code:
public bool ValidatePin(string PIN)
{
string response = WebRequest(Method.GET, string.Format
("{0}?oauth_verifier={1}", ACCESS_TOKEN, PIN), string.Empty);
if (response.Length > 0)
{
//Store the Token and Token Secret
var qs = HttpUtility.ParseQueryString(response);
if (!string.IsNullOrEmpty(qs["oauth_token"]))
this.Token = qs["oauth_token"];
if (!string.IsNullOrEmpty(qs["oauth_token_secret"]))
this.TokenSecret = qs["oauth_token_secret"];
return true;
}
else
{
return false;
}
}
Inevitably, I get 401 Unauthorized when submitting the
"oauth_verifier" web request.
I have a consumer key and a consumer key secret which work (as is
evidenced by the fact that I can get an authorization link).
Has anyone else encountered similar issues, or does anyone else have
any guidance on this particular issue?
Thanks in advance.
--Duane
