3

I'm really having a hard time how to hide my sensitive material in my django settings.py I tried creating a seperate settings file for local and production found here people advise and then stop midway. I also tried to create a file called secrets.py in my core file where my wsgi and settings are etc and tried to do this

DEBUG = True

if DEBUG:
    from .secrets import SECRET_KEY_LO
    this = SECRET_KEY_LO
    SECRET_KEY = this
else:
    SECRET_KEY = os.environ['SECRET_KEY']

but that didn't work. What is the professional programming way to do it? So I don't have to manually have to change DEBUG true to DEBUG false all the time it feels very novice and it can be verry annoying

nothingness
  • 971
  • 3
  • 10
  • 18

3 Answers3

1

You could use a config.json file to keep all your secrets. You can add this file to your .gitignore so it doesn't get uploaded to your repository in the cloud (e.g. GitHub). Then you can make your settings.py file read the config.json file and start assigning the values to the needed Python variables.

Carlos Peña
  • 224
  • 2
  • 10
1

Take a look at django-configurations. It has built in support for putting in default values that are not secret, and then making them required and different in Prod. Those values are supplied via environment variables so it moves the problem down the chain a bit.

Once you've got good values in there for testing you're in the deployment problem of how do you keep secret values secret. Each PAAS seems to have their own version of this as do many configuration management (Chef, Puppet, Salt, Ansible, etc.) systems. One of the best I've found has been using credstash in an AWS deployment. Your launch script on the server just needs to make a few calls to credstash get and then pass those values down as ENV variables to gunicorn / uwsgi / whatever and then django-configurations picks those up and applies them. That obviously depends on AWS, so it depends on where you're deploying but the basic idea is still the same. Get the secret value and feed it to your service via the ENV.

+1 for considering the entire question before checking in secret values. All to often it's super easy to do a bit of google dorking on github for these kinds of things.

Paul
  • 1,108
  • 9
  • 14
0

Two scoops of django, one of the most valued texts on Django best practices explains this issue in the following manner: You shall create a settings directory where you keep a hierarchy of settings files that import from each other. You then shall start django using the --settings switch as well as configure the settings file in wsgi.py.

You then build a file (say local_secret.py) containing only the secret keys (API keys, etc.) and import the rest of the settings from the remaining files. You keep local_secrets.py out of the code repository (using .gitignore for example).

This question has an answer by omouse and gene_wood that is much more detailed. That question is about local and production environments not about the secret key, keep that in mind.

Community
  • 1
  • 1
grochmal
  • 2,901
  • 2
  • 22
  • 28
  • thanks for the response. I actually tried that before this and I kept getting errors. It would not let me perform git push heroku master without throwing me an error – nothingness May 25 '16 at 02:02
  • A failing `git push heroku master` (i suppose) happened because of untracked files. That means that `.gitignore` is not ignoring your file or that `.gitignore` is not being committed, and heroku never sees it. – grochmal May 25 '16 at 02:39