Question

Closed. This question needs to be more focused. It is not currently accepting answers.

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 7 years ago.

For a pet project, I develop a desktop application which requires API keys from several different webservices.

I ve been going through and preparing this application to become open-sourced and run across the problem of what to do with those keys.

The problem is this: My understanding is that these API keys should not be visible to anyone using the application or viewing/modifying the source code. From the webservice s end, these API keys are used to identify applications accessing their API, and allow/block usage as appropriate. In most of the TOS s for receiving these keys it s actually explicitly stated that the keys must not be shared with the world.

Currently all my keys are hard-coded, but at I m at an impasse as to how to handle the situation of private keys in an open-source application:

-If the keys remain hardcoded, they ll be publicly visible as soon as my source code is.

-I can t really omit the source file with the keys from the code distribution, since then it won t compile. This technically solves the problem, but introduces a new, unacceptable one.

-If I push the keys off to a .ini or other config file, and simply not include that file in my public code repository, it would still have to be distributed with the binary of my application in order for the app to function, so my keys would be visible in the application distribution instead of the source distribution. Not an improvement. Any encryption gymnastics I attempted to utilize on this INI file would be adding the complexity for anyone attempting to modify my code.

So, with regards to my codebase (currently under Mercurial for version control), what s the best way to manage everything so that the code can be public, but my keys stay private?

Answer 1

Don t know what language you are using, but for example in C/C++ you d add a include file with the API keys, and then leave it out of source control, instead add a bogus file with explicitly fake API keys. Most languages have one or the other way to include files.

Answer 2

Your app should use a config file. This config file is loaded at runtime and shouldn t affect compiling. The allows users to download a binary and still use their own api key.

As Kornel says, you can include an example config file with a fake API Key, in your source control.

Another option, you could talk to the people running the webservices and ask for one of two things.

A temporary key, that only works for limited functionality. That would let users see basic functionality of your app, but some people would never update the key and just use the basic stuff.
Talk to the webservices to see if you they will give you a special API Key for your application. The open source version would require users to enter their own. But your binary could use a standard one.

The thought of using a config for api key s, isn t new or unheard of. Bit.ly services do it. And all the open source applications I see that provide use with Bit.ly ask for your username and api key before you can use it.

This is no different?

友情链接