Open sourcing your Django site

Andy McKay

5 responses

This is the first in series of posts, focusing on issues around open sourcing your Django site and data privacy in Django.

A lot of people focus on open sourcing their Django libraries, but at Mozilla we open source the entire site. Releasing your entire source code can lead to a few problems, firstly let’s look at your Django settings file.

Separating your settings

All Django sites come with a settings.py file. This file contains some key settings that you should not be releasing to the general public, such as database configuration and the secret key. The simple way to do this is have another file that contains the secret settings and then import it from settings.py. For example include this at the bottom of your settings.py:

All your sensitive settings can now kept in that local file on your server and should not be published as part of your site code. This file will override the base settings file.

There are plenty of other examples on different ways to do this. You can do it in manage.py, or turn your settings.py into a folder that Python can import. Make sure that you ignore your settings_local.py file in your source control.

If you add in new settings, make sure you add them into the main settings.py file. Even if they are just empty strings, lists or whatever, it will mean that when you call settings.SOME_KEY in your code, you won’t have to cope with the setting not being present. There’s nothing more tedious than writing lots of getattr code to cope with that.

Viewing settings on the server

One downside of doing this is that you might not be sure what your settings are on the server. At Mozilla only the system administrators who manage and deploy our servers can see the contents of that file. But it’s still helpful to check the settings on the server. For that we wrote a settings page that lists them out.

Django helps by providing a method that lists the settings, but obscures those really sensitive values:

On addons.mozilla.org we require an account to have certain privileges before showing the page. But even if that did get broken into, you wouldn’t know our SECRET_KEY or anything very useful. Here’s how that page looks:

Now that you’ve got your settings files ready, you can confidently open source your Django project safe that you won’t be leaking any key data.

In the next blog post we’ll look at scrubbing personal data from your database.

5 responses

  1. Paul Booker wrote on :

    Hi Andy,

    This is a very nice tutorial, hopefully the first of many 🙂

    I did find one typo ..
    “.. but even if that *didn’t* get broken into, you wouldn’t know our .. ”

    Best, Paul

  2. Markus Gattol wrote on :

    you need to either user local_settings.py in the text or correct the snippet to use from settings_local import *

  3. Andy McKay wrote on :

    Thanks Paul and Markus, both fixed.

  4. Aamir Maniar wrote on :

    Hi Andy

    This is indeed a nice tutorial and in my opinion would be required by many… How long will it take to complete the series? All the best for your effort.

    Best Regards

  5. Simon Hayward wrote on :

    Hi Andy,

    I’ve used environment variables for those *sensitive* values described, exported from the users .bashrc file, and so a `os.getenv(‘SENSITIVE_KEY’, ‘SAFE_DEFAULT_VALUE’)` is used in the settings file. Still doesn’t overcome the manual process involved though.

    regards
    Simon