Hello,
On Fri, 26 Jun 2020 00:46:02 -0700 (PDT)
Florian Apolloner <f.apollo...@gmail.com> wrote:
> On Thursday, June 25, 2020 at 7:52:31 PM UTC+2 kit....@gmail.com
> wrote:
>
> > Personally, I think that *at minimum* providing Django-builtin "get
> > from env" helpers would be great; beyond that, I'd love to have
> > them be included around `DEBUG` and `SECRET_KEY` with the current
> > values as defaults, so they're optional. Once we see how this gets
> > used, we can see about passing it a file instead of `os.environ`,
> > or borrowing other ideas from any of the various supporting
> > projects that have been suggested.
>
> I am all for minimal variants, but I do not think this would could
> it. [...]
> And there are plenty more things to consider; for instance I do not
> agree that it makes sense to have "SECRET_KEY" default to a value
> when missing in the env. It is way to easy to type "SECRT_KEY" and
> never realize that. So if "SECRET_KEY" is taken from the environment
> it should fail loudly if it is not present.
>
> [...] please note that the bar to add
> this to Django is very high since it can (at least for things like
> django-environ) easily live outside of Django with no realy downside.
>
Before this, when explaining the motivation for this, Kit said:
> My hope is to make the smallest possible change to just start us
> moving towards more clearly flagging, especially for newer devs,
> "these are things that will need additional configuration in order to
> move from 'works on my machine' to 'deployed'."
We already have a tool designed for this: the "check --deploy"
management command[1]. We can improve it a little by helping it detect
that the SECRET_KEY is carelessly kept hard-coded from the initial
project creation, e.g. by including somewhere a marker class:
class HardCoded(str): pass
and then in the default template
SECRET_KEY = HardCoded('generated_value_like_today')
Then the check could easily detect it and tell the user they need to
change it.
I think that a settings-only solution cannot be appropriate here, for
the reasons Florian noted -- Kit is basically asking the default
template to educate the user about deployment, but there is a tension
between this and having things Just Work, which is important for
beginners, and Just Work Securely (which is why the default SECRET_KEY
needs to be a generated, random secret). To resolve this tension, we
need a tool which is aware of context -- a tool which differentiates
between the beginner on their laptop, and the novice doing their first
deployment. The settings, in general, cannot make this distinction; a
management command can.
We have a whole bunch of documents about deployment[2] - maybe a little
too much, and this probably encourages shorter "just do this" type
deployment tutorials. Maybe we should make the checklist[3] more
prominent, maybe we should make "check --deploy" even more prominent.
But I don't think a single settings file can be all things for all
users.
My 2 cents,
Shai.
[1]
https://docs.djangoproject.com/en/3.0/ref/django-admin/#cmdoption-check-deploy
[2] https://docs.djangoproject.com/en/3.0/howto/deployment/
[3] https://docs.djangoproject.com/en/3.0/howto/deployment/checklist/
--
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/20200626131942.553c2b54.shai%40platonix.com.
