I'm sorry, I was talking about distributing source code. However, I wasn't thinking of Open Source (even though I wrote that), I was thinking of things like interpreted languages (like PHP) where you would distribute an application that can't be compiled in to a binary, as, even if you don't release the project as open source, if you can download, you have the source code. For example, there is a PHP project out there called eyeOS, which does what it sounds like it does: creates an Operating System like application that runs in your browser. If I were to write a Twitter client for that using OAuth, and put that up for download for a user to install, even though I am not making it open source, I am still releasing the source code because I cannot compile the code into a binary. What would you suggest I do, then, to try to hide my consumer key and secret to prevent people from using it to spam twitter and (possibly) getting my app shut down?
- Jason On Aug 17, 2009, at 4:55 PM, Chris Babcock wrote: > > Silly me. I thought someone was talking about distributing source > code. > Building an enduser distribution is somewhat to entirely different. > > First, there really isn't any point to using OAuth for a client unless > the client code lives on the network. The whole advantage of the > scheme > is that the user does not have to disclose credentials to one or more > third parties. An application that doesn't access a third party > network > should use basic authentication over HTTPS. > > If Twitter decides to eliminate basic auth then the correct way > (from a > security stand point) to implement OAuth would be to obtain a separate > key for each client. I don't see the current OAuth spec as being set > up > to handle bulk key assignments, but you can't distribute a single > key to > multiple clients outside of your network. Whether or not the app is > Open Source is a non-issue; It's complete FUD-rucking to imply that it > is any diffent distributing a secret key in a close source app than it > would be to do so in an open source app. > > What happens if you try to use a screwdriver as a hammer? It's the > same > thing here only someone had to drag Open Source into as if that made > any kind of a difference. To top it off, the OP had a complete > misunderstanding of the consequences of key disclosure. "A Spammer > could use it and get your app banned..." as if that's of any > consequence compared to the users' accounts getting hijacked by apps > impersonating your client. > > And what's with keeping score as if Open Auth and basic were a couple > of talking tools on Disney Channel having some sort of ludicrous > rivalry? > > Chris Babcock > > >> This is interesting Chris, as I have had the same question. How >> would >> you propose to distribute a usable FLOSS twitter app that uses Oauth >> to authenticate itself but doesn't include the app's consumer key and >> consumer secret? fetch the key and secret at runtime from a secure >> server somewhere? that could be trivially intercepted. >> >> Joseph Cheek >> @cheekdotcom >> >> Chris Babcock wrote: >>> On Sun, 16 Aug 2009 18:49:49 -0400 >>> Jason Martin <[email protected]> wrote: >>> >>> >>>> On another note, how "Open Source friendly" is OAuth? I'm not sure >>>> if people who write open source software want to be giving out >>>> their Consumer Secret key in their source code >>>> >>> >>> Reasoning from a faulty premise. >>> >>> When you know your code is going to be seen you either avoid doing >>> stupid things like hard coding credentials or you learn fast that >>> configuration data is not code. >>> >>> (Now where I did leave my virtual haddock?) >>> >>> Chris Babcock
