+1 on this approach.
No problems with external storage mechanisms where the newbie then needs
to do something to provide the required data. It's all done neatly in
Python, but secrets themselves are conveniently placed in a different file.
LP,
Jure
On 26/07/2020 15:09, Roy Smith wrote:
In the past, I've worked on a couple of django projects where we
violated the:
# SECURITY WARNING: keep the secret key used in production secret!"
advice because on day one, somebody didn't know what we they were
doing and never fixed it. Looking around at a collection of django
projects (by various developers), I see that's often the case.
SECRET_KEY, oauth keys, aws keys, etc all end up in settings.py
files. And show up in github, etc.
This is not terribly surprising. I expect most people just sit down
with the tutorial
<https://docs.djangoproject.com/en/3.0/intro/tutorial01/#creating-a-project>,
follow the first example:
$ django-admin startproject mysite
and instantly have a working, but insecure, setup.
So, why not have startproject start people off on the right foot?
Build a settings.py file and a secret_settings.py file. Put the
SECRET_KEY in secrets.py. Have settings.py do "from secret_settings
import SECRET_KEY". Make secret_settings.py mode 0400 by default (or
whatever that translates to on windows). Print out a message telling
people to exclude secret_settings.py from version control.
As people add more secrets, they have a low-effort path to continuing
to do something reasonable. A more sophisticated user can tear that
out and replace it with their own secrets infrastructure. But, at
least we will have started newbies off with something reasonable.
I see this has been discussed before
<https://groups.google.com/forum/#!searchin/django-developers/startproject%7Csort:date/django-developers/TtCyuDp4Exk/kk12ic7YCQAJ>,
but I disagree with a lot of the opinions in that thread. This
wouldn't be forcing developers to do it any specific way. It just
provides a default that's better than the current default. Expecting
that newbies to follow best practices just because they're documented
somewhere is irrational, as can be seen by perusing github.
--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-developers+unsubscr...@googlegroups.com
<mailto:django-developers+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/E7AED784-145B-45A5-9C23-8700E72E5CB8%40panix.com
<https://groups.google.com/d/msgid/django-developers/E7AED784-145B-45A5-9C23-8700E72E5CB8%40panix.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/c7285d2a-2728-0ee5-2902-6538511f5971%40gmail.com.
