Continue from the last installment of the series, Lets understand the reason why we need a separate Django setting with its secret key.
A Django project, must require a SECRET_KEY. Even when starting a Django project, Django will provide a SECRET_KEY such as below:
SECRET_KEY = 'django-insecure-yl7phg4*vdh@c22)%o%c99-4el7i+ku17gl458p$3q3@i-%)1r'
Django in its effort to remind us the developer, append the SECRET_KEY with "django-insecure-".
Why did they append this? A simple reason is that Django use the SECRET_KEY to sign info shared with the browser.
Django also warn us with this
Now that we know that we need to keep Django SECRET_KEY well.. secret, Don't you think that if we commit the project into an online repo means we expose our SECRET_KEY?
This is our main reason we need to decouple the SECRET_KEY from the main codebase.
There are more ways then one to skin a cat, such setting an environment variable on the OS, however I felt that this might be hard to implement when you have multiple web app running on the same server. One way that I am sharing here is to use python-decouple.
Lets first install the library into our django project.
pipenv install python-decouple pipenv lock -r >requirements.txt
for a beginner project as what we have right, we only have 3 thing we should add to our .env file as such
DEBUG = True SECRET_KEY = 'My_Secret_Key' ALLOWED_HOSTS = "*"
now lets make changes to our settings.py
first import the python-decouple library at the top
from decouple import config, Csv
change your setting for the following
SECRET_KEY = config('SECRET_KEY') # SECURITY WARNING: don't run with debug turned on in production! DEBUG = config('DEBUG', cast=bool, default=False) ALLOWED_HOSTS = config('ALLOWED_HOSTS', cast=Csv())
we now have a way to separate file to keep our secret keys.
All the work that we have done mean nothing if we still committing the .env file into our public repo right.
now in your .gitignore file add the following
and now we will not commit .env to our public repo.
I would propose to add a .env_sample just cause one day someone somewhere would fork this project and will unable to understand why Django wont run. By editing the name and also some parameter, Django can run properly.
Its hard to make a secure SECRET_KEY. However, I made this post previously
This way you can safely generate a new SECRET_KEY that have a very low chance would be expose.
So now we are able to decouple our secret from our settings. This doesn't just apply to SECRET_KEY, it could also be for our API authentication credential to a 3rd party vendor and also maybe other servers IPs.