How do you manage to keep credentials out of publically browsable source code?

Question

Let's say you want to show the source code for a settings file but don't want 3-4 lines to show up in the public source code. Do you just manually replace those variables or are there some tricks you use, like including them in yet another separate file and including that in the main conf?

Or is it more common to just not track and include that file in the repo?

Answer 1

The way I tackle this problem, and I have to deal with it in nearly every project I work on, is by utilizing a pattern I picked from someone. In this pattern--which can not only be used to keep credentials from not being under version control but also to segregate environment/platform specific settings--the main settings file, which is under version control, imports a secondary settings file that is aptly called "local_settings". This "local_settings" file is not put under version control, and for each platform that the source is deployed on, a separate, specific local_settings file is created tailored to that platform only.

I will give you an example of how I commonly do this for my Django/Python projects. There is a central, per-project settings.py file, which is under version control, and a platform (perhaps platform is not quite the right terminology to use here) specific local_settings.py file. The local_settings.py file is imported from within the settings.py file, where different setting variables are defined in the following manner:

import local_settings

DATABASE_USER = local_settings.db_user
DATABASE_PASSWORD = local_settings.db_pass

And, as an example to go along with the snippet above, the local_settings.py file is defined thus:

db_user = 'user'
db_pass = 'pass'

I have found this pattern when dealing with the issue in question to work really well.

Answer 2

It depends on the context, but a common solution is to have a application.cfg.sample that contains no sensitive information. This file is in the repository, etc. When you actually deploy the application, you copy that file to application.cfg and edit in the passwords, etc.

Another approach is to let the example values work for your development, but be meaningless, i.e.:

host: localhost
username: user
password: test

This might actually be a valid database account or whatever on your development workstation, but a user wouldn't assume that it is and the information is hardly sensitive.

Answer 3

Just replace the variables with example ones.

SETTINGS = {
     username: 'test',
     password: 'mypass'
}

etc.

Answer 4

You could either not check the file in, if its only a valid setting for a local configuration there really is no point to include it in the public source code or do the smart thing and encrypt the information ( in the case of an asp settings file ).