If you want to use a free source control service, there are still a few options.
I’m working on a website that will allow users to log in using OAuth credentials from the likes of Twitter, Google, etc. To do this, I have to register with these various providers and get a super-secret API key that I have to protect with pledges against various body parts. If my key gets ganked, the part gets yanked.
The API key has to travel with my source, as it is used at runtime to perform authentication requests. In my case, the key must exist within the application in a configuration file or within the code itself. That isn’t a problem when I build and publish from a single machine. However, when we throw source control into the mix, things get more complicated.
As I’m a cheap bastard, I’d much prefer to use free source control services such as TFS in the cloud or GitHub. This leaves me with a slight conundrum:
How can I keep my body intact when my API keys are in my code, and my code is available in a public repository?
I can think of a number of ways to handle this, but none of them are that satisfying.
- I could remove all private info from code, and edit it back in after deployment. This would be a severe pain to implement (I won’t detail the many ways), and isn’t an option.
- I could encrypt it. But as I have to decrypt it, anyone with the source could figure out how to do so. Pointless.
- I could pay for private source control. LOL j/k spend money? Please.
- I could use language features to segregate sensitive info from the rest of my source and therefore keep it from source control. This is what I’m doing now, but it could easily be screwed up by mistakenly checking in the secret file.
I’m really looking for a guaranteed way to ensure I don’t share my privates with the world (except on snapchat) that will work smoothly through development, debugging, and deployment and be foolproof as well. This is completely unrealistic. So what realistically can I do?
See the original question here.
Config file to the rescue
Philipp answers (41 votes):
Don’t put your secret information in your code. Put it into a configuration file which is read by your code at startup. Configuration files shouldn’t be put on version control, unless they are the “factory defaults,” and then they shouldn’t have any private information.
See also the question “Version control and personal configuration file” for how to do this well.
Let us count the ways
Lazy Badger answers (13 votes):
The pure git way
.gitignoreincluded file with private data
- Use a local branch, in which you replace
- Use smudge/clean filters, in which (local) filter’s script perform bidirectional replacement
The mercurial way
- MQ-patch(es) on top of dummy code, which replace
DATA(changesets are public, patch is private)
- Keyword extension with specially designed keywords (expanded only in your working directory)
- Have replacement of keywords as part of build/deploy process
Ioannis Tzikas answers (9 votes):
You could put all the private/protected keys as system environment variables. Your configuration file will look like this:
This is how we handle those cases and nothing goes into code. It works very well combined with different property files and profiles. We use different property files for different environments. In our local development environment we put the development keys in the property files to simplify the local setup:
Find more answers or leave your own at the original post. See more Q&A like this at Programmers, a question and answer site for professional programmers interested in conceptual questions about software development. If you’ve got your own programming problem that requires a solution, login to Programmers and ask a question (it’s free).