You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would recommend putting the secret key inside an .env file that would store all secrets (including admin and database password) and from settings.pygetting the secret key like this. Then we can gitignore the .envfile.
settings.py
importos# SECURITY WARNING: keep the secret key used in production secret!SECRET_KEY=os.environ.get(
"DJANGO_SECRET_KEY"
)
I think this method helps preventing mistakes while facilitating collaboration as there are many things we can change inside settings.pythat we would want other developpers to pull.
The current recommendation:
So recommended: Keep it safe. Ignore settings.py file in your commits. Change the secret
key on your deploy. If you lost the secret key for any reason or
the server got compromised change it as soon as possible.
The text was updated successfully, but these errors were encountered:
I would recommend putting the secret key inside an
.env
file that would store all secrets (including admin and database password) and fromsettings.py
getting the secret key like this. Then we can gitignore the.env
file.settings.py
.env
I think this method helps preventing mistakes while facilitating collaboration as there are many things we can change inside
settings.py
that we would want other developpers to pull.The current recommendation:
So recommended: Keep it safe. Ignore
settings.py
file in your commits. Change the secretkey on your deploy. If you lost the secret key for any reason or
the server got compromised change it as soon as possible.
The text was updated successfully, but these errors were encountered: